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]

DNSSEC support in stub-resolver

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

This is rephrased version of original summary from DANE-list [1].

The problem is how to determine that answer from DNS can be trusted.

Full recursive resolvers can do DNSSEC validation and indicate result of the validation via Authenticated Data (AD) bit in DNS header.

Stub-resolvers often communicate with recursive-resolvers via insecure channels so no data in DNS packet can be trusted.

For this reason, applications have a special switch for dis/trusting replies obtained via stub-resolver. Famous example is VerifyHostKeyDNS option in OpenSSH client.

Practically, it means that administrator has to flip a switch in all DNSSEC-enabled applications when validating recursive resolver is un/installed or channel to the resolver is dis/trusted.

This is not an optimal situation and it has potential to create administrative nightmare as number of DNSSEC-enabled applications grows.

This proposal calls for system-wide configuration for dis/trusting recursive resolver (and channel to the resolver) and API for obtaining secured answers.

The discussion on DANE list was focused on the principle of configuring trust in stub-resolver, we didn't discuss API extensions etc.

Now, I would like to start discussion about potential extensions to libresolv API & configuration.

*This is first and raw draft, any suggestions are more than welcome!*

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!

API extensions
This proposal adds few new flags. No functions will change their behavior if those flags are not present.

Applications need to have ability to find out if the flag is supported or not. E.g. simply calling getnameinfo() with the new flag is fine if it returns an error on systems with an older library.

Assumption: DNS answer is deemed secure if it arrived from trusted-resolver (configured above) and has AD bit set in the DNS header.

*This is first and raw draft, any suggestions are more than welcome!*

1) getnameinfo/getaddrinfo
Goal: Enable secure name-address-name translations chains like *FQDN* -> IP -> canonical FQDN resolution.
- Add flags AI_SECURE_ONLY and NI_SECURE_ONLY (or something like that)
- Return answer only if result is deemed to be secure
- Return EAI_INSECURE if an answer was received but is not deemed secure
- Return other EAI_* errors as usual

2) res_* interface
Goal: Get data associated with given *FQDN* and make sure that nobody tampered with it.
- Add new flag RES_SECURE_ONLY to _res.options
- All res_* functions should fail if RES_SECURE_ONLY is set but
-- any of (RES_DNSRCH & RES_DEFNAMES) is set
-- any of (RES_NOALIASES & RES_USE_DNSSEC) is not set

res_send() and derivatives
- Return answer only if result is deemed to be secure
- Return error if an answer was received but is not deemed secure

- doesn't support RES_SECURE_ONLY: RES_SECURE_ONLY exact match on FQDN

How can application detect that RES_SECURE_ONLY is supported?

Thank you for your time!

[2] man ssh_config from

Petr Spacek  @  Red Hat

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