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.