Ability to work as a DNS resolver

lordraiden commented 5 years ago

Right now Adguard just fwd the DNS requests to "public" DNS of our choice. It would be nice to have the ability to call directly to the root servers acting as a DNS resolver. I think it will improve privacy a lot but maybe it wont be as fast, but is a tradeoff

ameshkov commented 5 years ago

We're looking into it right now actually.

Basically, we have two options:

Use a resolver implementation written in pure Go
Use libunbound + CGO bindings

libunbound is a stable and reputable software, but the drawback is that it complicates things, and it'd be hard to cross-compile it for every OS.

lordraiden commented 5 years ago

Maybe you already know this list, but it can give you some idea of what solutions are out there. https://doh.defaultroutes.de/implementations.html

ibksturm commented 5 years ago

hi there

i had similar thinks when i start with ibksturm.synology.me.... a) being a resolver to root b) being a forwarder

i choose a combination. opennic i running with nsd a copy of root and iana forward

my reasons are:

opennic local copy: cause being a duplicate of the hole alt. dns system and it isn‘t speed „important“
iana forwards because
- speed, forwarding is much faster than resolving (i use resolving only as fallback)
- privacy reason, all forwards are over tls 853. unbound change in the actualy modified config over 6 dns server, where the fastest ist weighted to 40%. i also wrote months ago to the iana guys a mail where i could get encryted root server. the answer was that all root servers are for reason unencrypted and thats at the moment not a option in their roadmap
les data traffic. if you‘ve got over 1.5 mio request / 24h you will think about.... keynote: myisp had also think about and installed on street side a new fiberswitch station 👍 it seams that i crushed hole neighbourhood :)

back to original question

i think it would be better for future of project if you wrote it complettly newly on Go.

you „ know“ better what your code do
you could splitt it into a side project as dnsproxy
as you wrote its easyier to compile
there could be some handmade security bugs where unbound guys are well known

maybe if i thinking loud, is there any reference on unbound websides? or maybe theguys from unbound had allready done a Go project. Wrote them a mail wouldn costs a lot... just trying to help you guys

greets

ameshkov commented 5 years ago

there could be some handmade security bugs where unbound guys are well known

Well, there is a much greater chance that there will be bugs in our implementation :)

ibksturm commented 5 years ago

@ameshkov da, thats what i would say ^^

so what i mean generally, maybe the unbound people could / should / would peer review your opensourcecode

making a more secure internet belongs to every one

ameshkov commented 5 years ago

Just in case, here's everything I know about recursors and Go: https://github.com/AdguardTeam/dnsproxy/issues/46

ibksturm commented 5 years ago

thats more than i know ^^ anyway i have go back to business

ameshkov commented 5 years ago

Experiments with CGO and unbound took A LOT of our time and the only thing that we understand now -- we should avoid CGO if we want to keep AGH truly cross-platform :(

Re-assigning this issue to v0.98, we'll make a second try now with a resolver written in pure go.

lordraiden commented 4 years ago

What is the status of this feature? How far are we or how dificult it will be?

ameshkov commented 4 years ago

It is quite difficult. We tried libunbound, but it's not the ideal solution for a number of reasons.

We started developing a pure Go implementation, but the problem is that it will take quite a lot of time to do it properly, and we have tons of other features we'd like to be implemented.

The good news is that the author of CoreDNS seems to be going to implement a resolver in Go so there's a change that by the time we revisit this issue, there will be already something to work with.

lordraiden commented 3 years ago

It is quite difficult. We tried libunbound, but it's not the ideal solution for a number of reasons.

We started developing a pure Go implementation, but the problem is that it will take quite a lot of time to do it properly, and we have tons of other features we'd like to be implemented.

The good news is that the author of CoreDNS seems to be going to implement a resolver in Go so there's a change that by the time we revisit this issue, there will be already something to work with.

Any news from coredns?

ameshkov commented 3 years ago

Nope:(

hoshsadiq commented 3 years ago

@ameshkov out of curiousity, Is there a reason sdns resolver isn't considered?

ameshkov commented 3 years ago

I am keeping an eye on it. I don't like that it depends on some SDNS server internal structures that aren't really needed for a resolver.

ammnt commented 3 years ago

@ameshkov, if this is implemented, will DNS Zone Transfer-over-TLS/XFR-over-TLS be implemented as well?

ameshkov commented 3 years ago

Depends. The more I learn about DNS, the more I think we shouldn't implement a recursor ourselves, it's just too huge of a task. So if we find a recursive resolver library that fits, we'll use it and everything will depend on it.

lordraiden commented 2 years ago

Depends. The more I learn about DNS, the more I think we shouldn't implement a recursor ourselves, it's just too huge of a task. So if we find a recursive resolver library that fits, we'll use it and everything will depend on it.

Core DNS is written in golang isn't the same than Adguard?

ameshkov commented 2 years ago

Core DNS is indeed written in golang, but it is not a recursor.

lordraiden commented 2 years ago