This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: DNSSEC support in stub-resolver
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Petr Spacek <pspacek at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 28 Apr 2014 15:32:01 +0200
- Subject: Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com>
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.