On 26.2.2014 18:24, Tony Finch wrote:
Paul Wouters <[email protected]> wrote:
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.
A proposal sent to the other thread
(http://www.ietf.org/mail-archive/web/dane/current/msg06475.html)
attempts to address this problem with explicit name server white-listing.
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 :-)
The mentioned proposal calls for per-system centralized trust anchor management.
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.
This is exactly the reason why we propose to strip the AD bit in library so
application don't need to think about it's trustworthiness.
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.
Note we are not trying to 'target' one particular library. It would be great
if we can reach consensus on some universal approach and then actively work
with DNS library maintainers to add the new behavior to DNS libraries.
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).
Could you elaborate on reasons for setting AD=1, please?
--
Petr Spacek @ Red Hat @ Brno office
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
