Re: Building consensus over DNSSEC enhancements to glibc.

[Simo Sorce <simo at redhat dot com>]

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

The goal of many here is to "fail safe" meaning AD bits should be 
stripped unless there is positive knowledge that the DNS resolver is in 
fact trusted (and we do not agree that the resolv.conf configuration 
lists trusted name servers, Ãa va sans dire).

Simo.

--
Simo Sorce * Red Hat, Inc * New York