Ideas -- How to "route" DNS traffic through multiple daemons

[drmike]

Part of the ongoing "hardening" of my own environment involves cleaning up DNS.  DNS is often leaky these days and many providers are intercepting DNS requests and doing all sorts of unwanted things with the data.

In an effort to starve them, provide a bit more security and generally have a more honest environment, I continue to move to specific DNS providers and did that tutorial recently on how to run encrypted DNS lookups (although only supported at current by OpenDNS ---> http://vpsboard.com/topic/1507-securing-dns-lookups-via-encrypted-dns-dnscrypt/).

I am stuck with my latest proof of concept that builds upon the above.

Since Debian and likely all other Linux OSes do not support ports in /etc/resolv.conf -- that is setting config options for DNS server running non port 53 standard, you are stuck with basically one DNS resolver/daemon per server/IP.

Why do I need more than one daemon to process DNS?  Simple, DNSCrypt does the crypto DNS lookup on remote DNS server.  It doesn't do caching.

Caching and a central control piece is important ala DNSMasq.   Most of you are familiar with DNSMasq and the multitude of features.  It's used in all sorts of solutions including the ever popular dd-wrt.  It's lightweight and very powerful.

DNSMasq doesn't appear to support DNS lookups on non standard ports either anywhere in it's config.  Yes, you can run DNSMasq on any port, but unsure how that truly helps in any way.

Basically, trying to achieve this:

Computer ---->   DNSMasq ---> DNSCrypt

127.0.0.1 --->  127.0.0.1:53 (DNSMasq) ---> 127.0.0.1:530 (DNSCrypt)

Is anyone doing something like this / have recommendation on how to get these working seamlessly?

Yes, possible I am overlooking something obvious.  Feel free to make me go Doh!

 

[Tux]

Dirty way, works if DNSCrypt can listen on port 53 and bind to a different interface (also needed for DNSMasq): Run ifconfig lo:0 127.0.0.2 to get a new loopback interface, and then make DNSMasq listen on port 53 on 127.0.0.1 (routing requests to 127.0.0.2), and DNSCrypt listen on port 53 on 127.0.0.2.

It's not optimal, but it should work.

 

[drmike]

Dirty way, works if DNSCrypt can listen on port 53 and bind to a different interface (also needed for DNSMasq): Run ifconfig lo:0 127.0.0.2 to get a new loopback interface, and then make DNSMasq listen on port 53 on 127.0.0.1 (routing requests to 127.0.0.2), and DNSCrypt listen on port 53 on 127.0.0.2.

It's not optimal, but it should work.

That will work but get mighty complex for end users following a tutorial.  I will probably try it out locally  for my testing though.

 

[blergh]

Dnscrypt is AIDS, use dnssec.

 

[drmike]

DNSSEC... Isn't that used for domain signatures and for the domain owner/administrator?

Does DNSSEC provider for any plain, non open air, encrypted look ups?   I looked quickly and don't see anything in that way.   Please share/point me if you know more in that regard.

 

[scv]

I was under the impression DNSCrypt only worked with OpenDNS, which is untrustworthy anyway.

 

[drmike]

DNSCrypt works currently as per http://dnscrypt.org/, with OpenDNS and CloudNS (Australia).

I am unsure at this point how one could make DNSCrypt with their own resolver server.  That would be the ticket to mass adoption.

Do I trust them, ehh, no.   But better than plaintext, open air requests that can be forged/intercepted/etc.

 

[scv]

While your requests to OpenDNS or CloudNS may be encrypted, the following recursive requests will still be unencrypted and subject to possible poisoning or sniffing. DNSSEC is part of the solution but still suffers from the sniffing problem, which lacks a good solution

My initial suggestion was to transparently encrypt between you and a remote recursive caching resolver, but of course you'd still be vulnerable to the same attacks at that resolver. Only difference is it may be easier to ensure the security of the remote machine.

DNSCurve is a solution to the problem but it would require end to end support for the protocol extensions, which is unfortunately very unlikely.

 

[drmike]

While your requests to OpenDNS or CloudNS may be encrypted, the following recursive requests will still be unencrypted and subject to possible poisoning or sniffing. DNSSEC is part of the solution but still suffers from the sniffing problem, which lacks a good solution

So tunnel between you and OpenDNS resolver = encrypted = good.

Whatever OpenDNS does to do the lookups there onward, is unencrypted.  I don't see a problem with that .   OpenDNS is a huge DNS service with many millions of users.   Your request would be a drop of water in the ocean basically.

Hazard with vendor (OpenDNS) use here is what is OpenDNS recording about lookups, data retention, sharing, built in NSA/government taps, etc.  Those are all unknowns.   I'll start officially trying to dig up those details and bother them. 

 

[blergh]

DNSCrypt works currently as per http://dnscrypt.org/, with OpenDNS and CloudNS (Australia).

I am unsure at this point how one could make DNSCrypt with their own resolver server.  That would be the ticket to mass adoption.

Do I trust them, ehh, no.   But better than plaintext, open air requests that can be forged/intercepted/etc.

DNSCrypt is kinda like re-inventing the wheel, but with a twist. DNSSEC is most certainly a game-changer as it fundamentally changes the way DNS works/is handled. You have to remember that OpenDNS is a business, anyone who has ever used OpenDNS knows that they every now and then give you bogus replies to whatever shit-sprayed website they want. This is also one of the key reasons they are using their own DNSCrypt instead of the widely used and adopted DNSSEC.

Regarding plaintext and such;

http://www.internetsociety.org/deploy360/dnssec/

http://www.icann.org/en/about/learning/factsheets/dnssec-qaa-09oct08-en.htm

http://www.nlnetlabs.nl/downloads/DNSSEC-AFNOG08.pdf

While your requests to OpenDNS or CloudNS may be encrypted, the following recursive requests will still be unencrypted and subject to possible poisoning or sniffing. DNSSEC is part of the solution but still suffers from the sniffing problem, which lacks a good solution

My initial suggestion was to transparently encrypt between you and a remote recursive caching resolver, but of course you'd still be vulnerable to the same attacks at that resolver. Only difference is it may be easier to ensure the security of the remote machine.

DNSCurve is a solution to the problem but it would require end to end support for the protocol extensions, which is unfortunately very unlikely.

You could somewhat achieve this with DNSSEC and DNSCrypt, but with varied results/confidentiality. DNSCurve is indeed very interesting, but will most probably never happens seeing the different political aspects of such an implementation.