On Wed, 26 Feb 2014, James Cloos wrote:
[ picking this answer because it brings back this thread to my question ]
"PW" == Paul Wouters <[email protected]> writes:
PW> Now for my question. Until we reach 4), what should we do with the AD
PW> bit in getaddrinfo() ?
PW> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
PW> configuration mechanism will allow white-listing nameservers and
127.0.0.1
PW> will always be on the whitelist.
PW> B) do nothing
I've always preferred a local resolver, and with dnssec a local
verifier, on every system. If there are systems unable or unwilling
to do that, then A is a reasonable compromize until they can and will.
So my fear of that doing A) are negative consequences. Admins installing
a rack of servers or VMs, and pointing resolv.conf to something trusted
nearby, but not on localhost itself, will get the AD bit stripped without
additional configuration. If those people upgrade their systems to the
new A) solution, their applications will no longer see the AD bit.
But so far, it seems I'm the only one worried about that case.
That and I prefer solutions working on obsoleting resolv.conf
over extending it and I think most cases can already be covered by
running a DNS server on localhost - with the exception of laptops
(dnssec-trigger+unbound does not cut it yet for non-techies)
If there are more people who would like to reply to this issue
specifically (as opposed to other APIs or _sending_ AD bits), that
would be useful.
So far it seems people are leaning towards A) over B) while everyone
seems to agree doing DNSSEC on the host itself (server or in-app) is
still the preferred method.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
