Paul Wouters <[email protected]> wrote: > I'm currently aware of two (non-dns utilities) applications that make > security decisions based on "blindly" trusting the AD bit: ssh with > VerifyHostKeyDNS=yes|ask and Postfix.
Note that OpenSSH can be linked with ldns to do its own validation. > 1 Applications can either do dnssec validation themselves, or trust the > AD bit. At the moment I consider in-process validation to be the safer way to do it, because apps do not have any sane way to verify that it is safe to trust the AD bit (more about that below). That is, by doing its own validation the app is better able to guarantee safety, without assuming that there is an expert and diligent sysadmin who is able to do arcane things like override the DHCP server's suggested nameserver addresses. > 2 It is undesirable that each application has its own DNSSEC validation > code, trust anchors and DNS cache. Agreed, but there are some subtleties. It's probably not too bad if the validation code is in a shared library that is centrally configured - like the traditional resolver or ldns's resolver. However if ldns's resolver were to be more widely used it will need MUCH better trust anchor management. Even so a system-wide cache should perform better. Perhaps multi-user systems should have per-user validating caches so that users don't have to trust each other too much :-) > 3 It is undesirable that applications blindly trust the AD bit when > resolv.conf points to another host as the AD bit could have been modified > on the network. Right. What makes this particularly pernicious is that the resolver API does not give an app any reasonable way to find out if it would be safe to trust the AD bit. To do so the app would have to extract the name server addresses from the __res_state and compare that with the system's list of network interface addresses. The layout of __res_state is private and the way IPv6 support has been added varies wildly between different flavours of unix. Utterly horrible. > 4 In the ideal world tomorrow, each host has its own automatically > configured, perfectly working validing DNS server and resolv.conf can > be ignored or is always hardcoded with nameserver 127.0.0.1 That would be nice :-) > Now for my question. Until we reach 4), what should we do with the AD > bit in getaddrinfo() ? > > A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new > configuration mechanism will allow white-listing nameservers and 127.0.0.1 > will always be on the whitelist. That sounds like a fair plan. Note that what ssh does is use the low-level res_query() API which returns a raw DNS packet, and examines the AD bit in the packet header. http://svnweb.freebsd.org/base/vendor-crypto/openssh/6.5p1/openbsd-compat/getrrsetbyname.c?revision=261288&view=markup#l274 Exim's preliminary DNSSEC support does the same. http://git.exim.org/exim.git/blob/HEAD:/src/src/dns.c#l430 So you should change the low-level parts of the traditional resolver to clear the AD bit in the packet header before returning to any higher level code, unless the connection to the nameserver is known to be safe. Question: along with this change are you planning to change the resolver to set the AD flag in queries when the nameserver is known to be safe? Usually the AD flag only appears in responses if the query had the AD or DO flags set. DO is a bit wasteful for clients that only care about the AD bit. However the only DNSSEC switch that libc resolvers currently have is options edns0 (which implies DO). Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Malin: West or southwest 5 to 7, backing south 6 to gale 8 for a time. Rough or very rough. Showers, rain for a time. Good, occasionally poor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
