This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PING] Re: DNSSEC support in stub-resolver


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:
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.)

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 trusted=true
nameserver # 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 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:
I have no idea how in/compatible this change can be.

4) Add a new verb to /etc/resolv.conf
trusted-nameservers 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:"
- 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
- 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!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]