This is the mail archive of the
mailing list for the glibc project.
[PING] Re: DNSSEC support in stub-resolver
- From: Petr Spacek <pspacek at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 14 May 2014 16:11:05 +0200
- Subject: [PING] Re: DNSSEC support in stub-resolver
- Authentication-results: sourceware.org; auth=none
- References: <535E41F5 dot 5020109 at redhat dot com> <20140428133201 dot GB24365 at domone dot podge> <5360BBBD dot 30901 at redhat dot com>
On 30.4.2014 11:00, Petr Spacek wrote:
On 28.4.2014 15:32, OndÅej BÃlka wrote:
On Mon, Apr 28, 2014 at 01:56:37PM +0200, Petr Spacek wrote:
IETF mailing list dedicated to DNS-DANE hosted a lengthy discussion
 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.)
Basic assumption is that only administrator knows if recursive
resolver and communication channel are trusted for DNSSEC validation
(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
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
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
Yes, you are right. This example wasn't the best one... Note that nothing
prevents you from modifying "trusted" list as you move between networks.
I should be more explicit about expectations behind the proposal. The
intention is to make it flexible enough to accommodate all possible use cases.
The most important part is *adding an ability* to distrust recursive resolver.
Nowadays every resolver is trusted and there is no option to distrust it.
The expectation is that most common cases will be:
- local validating resolver + configuration "trusted:127.0.0.1"
- no local validating resolver + configuration without any "trusted" statement
My expectation is that "foreign" IP addresses will be used only in specialized
- VM configured with IP address of it's hypervisor, i.e. case with two kernels
communicating inside single physical machine
- Container (e.g. Docker) configured with IP of it's "host" (is it called
hypervisor?), i.e. communication happens inside single kernel
you need some fingerprint verification.
I would force using a trusted channel that could do authentification.
I don't think that glibc is the right place to add dependency on
SSH/SSL/IPSec/TSIG-CGA/any other particular "secure transport" technology.
Also, this doesn't allow you to handle cases where admin is sure that plain IP
transport is secure (i.e. VM/container). Consider use case with one physical
machine running hundreds of containers with Apache inside...
Reconfiguration can be handled by external tool/daemon. The daemon can detect
presence of trusted channel and reconfigure the list of trusted resolvers as
I hope this explains the intent. Have a nice day!