Re: DNSSEC support in stub-resolver

[Petr Spacek <pspacek at redhat dot com>]

On 28.4.2014 15:32, OndÅej BÃlka wrote:
> 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

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"
or
- no local validating resolver + configuration without any "trusted" statement

My expectation is that "foreign" IP addresses will be used only in specialized 
cases. E.g.:
- VM configured with IP address of it's hypervisor, i.e. case with two kernels 
communicating inside single physical machine
or
- 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 
needed.

I hope this explains the intent. Have a nice day!

--
Petr^2 Spacek