This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Building consensus over DNSSEC enhancements to glibc.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at libc dot org>, Simo Sorce <simo at redhat dot com>
- Cc: Paul Wouters <pwouters at redhat dot com>, Petr Spacek <pspacek at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 16 Nov 2015 23:58:33 -0500
- Subject: Re: Building consensus over DNSSEC enhancements to glibc.
- Authentication-results: sourceware.org; auth=none
- References: <563CED63 dot 1070201 at redhat dot com> <20151106182835 dot GC3818 at brightrain dot aerifal dot cx> <563D0953 dot 9020707 at redhat dot com> <56407C19 dot 2080906 at redhat dot com> <20151109180310 dot GO3818 at brightrain dot aerifal dot cx> <5649A3F3 dot 2060309 at redhat dot com> <20151116161642 dot GQ3818 at brightrain dot aerifal dot cx> <564A0FED dot 9010408 at redhat dot com> <20151116181740 dot GS3818 at brightrain dot aerifal dot cx> <564A1E3E dot 5090703 at redhat dot com> <20151116182322 dot GU3818 at brightrain dot aerifal dot cx>
On 11/16/2015 01:23 PM, Rich Felker wrote:
> On Mon, Nov 16, 2015 at 01:19:42PM -0500, Simo Sorce wrote:
>> So you are saying that Carlos's proposed `options
>> dns-strip-dnssec-ad-bit` will do absolutely nothing ?
>
> I don't even understand what it means, but presumably it's in the
> context of adding some extension where the AD bit is reported in the
> getaddrinfo results. I question whether there is any valid reason to
> have such an extension in the first place. I have not yet seen a
> proposed usage case where it's needed that doesn't involve hopelessly
> insecure configurations.
Please allow me to explain.
The option strips the AD-bit from responses returned by libresolv to
cause all applications using libresolv to see unauthenticated data.
e.g.
openssh-7.1p1/openbsd-compat/getrrsetbyname.c
274 #ifdef HAVE_HEADER_AD
275 /* check for authenticated data */
276 if (response->header.ad == 1)
277 rrset->rri_flags |= RRSET_VALIDATED;
278 #endif
openssh-7.1p1/dns.c
239 if (fingerprints->rri_flags & RRSET_VALIDATED) {
240 *flags |= DNS_VERIFY_SECURE;
241 debug("found %d secure fingerprints in DNS",
242 fingerprints->rri_nrdatas);
243 } else {
This would prevent the ssh client from thinking it had secure
fingerprints loaded via DNS.
A secure system that is migrating from being insecure to having
validation over a secure channel (local validating resolver) would
immediately set the options flag in /etc/resolv.conf before
upgrading and clear it after the upgrade when the results could
be trusted.
Optionally NetworkManager via resolvconf (coordinating /etc/resolv.conf
changes) could set the option if only one insecure public network
was connected to the system.
Note that more complex policy and DNS splitting is required if you're
going to handle multiple interfaces with different trust per interface.
Which is why something like a local validating resolver is an attractive
and flexible solution.
Does that answer your question?
Cheers,
Carlos.