Paul Wouters <[email protected]> wrote: > 1 Applications can either do dnssec validation themselves, or trust the > AD bit.
> 2 It is undesirable that each application has its own DNSSEC validation
> code, trust anchors and DNS cache.
> 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.
> 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
My problem isn't that the AD is insecure, but that it isn't very useful.
Going back 10 years to the various DNSSEC workshops, one of the things that I
wanted was more information about why there was a validation failure.
For instance, if I have previously contacted example.com, and I have
it's A/AAAA or more interestingly, the DANE borne public key for the service
I want to reach cached, or leap-of-faith'ed, I don't care as much if the
DNSSEC fails to validate because a signature expired.
If it fails to validate because the data is correct, I expect the bad data to
be discarded, and for it to try again. At some point (<<5s) the application
needs to get some kind of report that name is not presently available.
(Happy eyeballs, or some other mechanism might want to try something else)
This is doubly true if I have contact with the user who
can I can:
a) advise of the specific reason for the failure
(which up to now, would be followed by facepalm and one of geeks
goes to fix the problem....)
b) find out what they want to do now.
SERVFAIL / "Host now found" is simply not acceptable information.
For this reason, I think that applications should not set or depend upon the
AD bit, even if the resolver is ::1. They either understand DNS(SEC), or
they use an API call way more sophisticated than getaddrinfo() to do their
connections. Java had the right idea, but the implementation and error
reporting was very poor.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting for hire =-
pgpIlVlmTfYiR.pgp
Description: PGP signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
