Re: DNSSEC support in stub-resolver

[OndÅej BÃlka <neleai at seznam dot cz>]

On Mon, Apr 28, 2014 at 01:56:37PM +0200, Petr Spacek wrote:
> Hello list,
> 
> IETF mailing list dedicated to DNS-DANE hosted a lengthy discussion
> [0] about DNSSEC support in stub-resolvers.
> 
> The questions are mostly:
> - How can we enable applications to use DNSSEC easily *and securely*?
> - How can we make DNSSEC related configuration system-wide? (I.e.
> the intent is to *avoid* adding application-specific switches to all
> applications dealing with DNS.)
> 
> 
> Configuration
> =============
> Basic assumption is that only administrator knows if recursive
> resolver and communication channel are trusted for DNSSEC validation
> or not.
> (E.g. Unbound vs. old dnsmasq ; IPSec vs. plain IP considerations.)
> 
> This trust must be expressed somehow.
> 
> If we consider machines using DHCP(d), it seems that we need to have
> per-resolver configuration.
> 
> dhcpclient will mess with /etc/resolv.conf as usual, so global
> switch like "resolver-trusted=true" could be dangerous. Imagine a
> case where admin installed local resolver, turned it on and then
> moved to another network. Dhcpclient rewrote nameserver lines in
> /etc/resolv.conf. In that case the system is vulnerable!
> 
> 
> This reasoning leads to the question:
> How can we handle per-resolver options?
> 
> Examples (in no particular order; all names are random):
> 
> 1) Extend nameserver line in /etc/resolv.conf
> nameserver 127.0.0.1 trusted=true
> nameserver 192.0.2.1 # default is trusted=false
> I'm afraid that this will not work. I expect many programs parsing
> /etc/resolv.conf and expecting the "classical" format ...
> 
> 
> 2) Put per-resolver configuration to a separate (optional!) file
> E.g. /etc/resolv.ext (propose your own name)
> nameserver 127.0.0.1 trusted=true
> It seems a bit weird but maybe it is the cleanest option we have...
> 
> 
> 3) Extend option syntax in /etc/resolv.conf
> options trusted:127.0.0.1
> I have no idea how in/compatible this change can be.
> 
> 
> 4) Add a new verb to /etc/resolv.conf
> trusted-nameservers 127.0.0.1 192.0.2.1 2001:DB8::1234
> 
> 
> Which option do you like? Propose your own!
> 
That is still vulnerable with determined attacker that would on
different network supply his resolver with same address and do MITM, so
you need some fingerprint verification.

I would force using a trusted channel that could do authentification.

A off-the-shelf solution that could be overkill is to establish a ssh
tunnel to trusted resolver. A trust would be expressed by file with
privete keys of resolvers that you trust.