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: Rich Felker <dalias at libc dot org>
- To: 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 13:23:22 -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>
On Mon, Nov 16, 2015 at 01:19:42PM -0500, Simo Sorce wrote:
> On 16/11/15 13:17, Rich Felker wrote:
> >On Mon, Nov 16, 2015 at 12:18:37PM -0500, Simo Sorce wrote:
> >>On 16/11/15 11:16, Rich Felker wrote:
> >>>On Mon, Nov 16, 2015 at 06:37:55PM +0900, Paul Wouters wrote:
> >>>>On 11/10/2015 03:03 AM, Rich Felker wrote:
> >>>>>On Mon, Nov 09, 2015 at 11:57:29AM +0100, Petr Spacek wrote:
> >>>>>>One of reasons why 'nameserver 127.0.0.1' only cannot work are systems which
> >>>>>>boot from network. Imagine that the system is booting so it does not
> >>>>>>necessarily have local resolver running (yet) but the system might need to
> >>>>>>mount NFS share with / from somewhere, probably from a NFS server which is
> >>>>>>identified by DNS name.
> >>>>>
> >>>>>That works perfectly well. You simply configure it to use the
> >>>>>nameservers from dhcp as the upstream sources for the nameserver
> >>>>>running on localhost.
> >>>>
> >>>>That does not address the problem of the network being able to set AD bits in DNS packets.
> >>>>AD bits are _not_ protected by a signature of any kind.
> >>>
> >>>You don't use or retransmit these AD bits at all. The local nameserver
> >>>has to check all signatures itself and generate its own AD bit in the
> >>>response.
> >>
> >>I guess the misunderstanding here is that, unless glibc drops AD
> >>bits by default, as opposed to only dropping them when a special
> >>option is set, then applications cannot trust if the AD bits were
> >>set by a trusted resolver or by a random "internet cafÃ" compromised
> >>DNS server that is used as the nameserver option in resolv.conf
> >
> >Glibc neither "drops" nor "preserves" AD bits because it does not
> >produce dns packets as output. It produces struct addrinfo and struct
> >hostent, neither of which has such a concept.
>
> 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.
Rich