On Mon, 20 Mar 2017, Andrew Sullivan wrote:
On Mon, Mar 20, 2017 at 06:19:45PM -0400, Paul Wouters wrote:
I am assuming that if stubs are validating, then they must also support
excluding special queries from validation, such as mDNS, .onion and
.homenet.
What possible basis do you have for this? This is in effect a
requirement that every validating stub (or resolver? I dunno) be
upgraded to support homenet.
https://tools.ietf.org/html/rfc7686 dated October 2015 did this too:
3. Name Resolution APIs and Libraries: Resolvers MUST either respond
to requests for .onion names by resolving them according to
[tor-rendezvous] or by responding with NXDOMAIN [RFC1035].
4. Caching DNS Servers: Caching servers, where not explicitly
adapted to interoperate with Tor, SHOULD NOT attempt to look up
records for .onion names. They MUST generate NXDOMAIN for all
such queries.
5. Authoritative DNS Servers: Authoritative servers MUST respond to
queries for .onion with NXDOMAIN.
The .homenet queries should never reach real DNS servers
But they're going to.
Of course. I was just saying that when they do, there is no good answer
for them.
not think an insecure delegation in the root is required. If the DNS
resolver doesn't know how to handle .homenet, it is already as wrong
as it can be, regardless of the type of answer.
This doesn't follow. If the resolver gets it wrong in the case of a
provably-unsigned answer, it can just continue its resolution as it
ever wanted. It won't be able to validate, since it does not have a
local trust anchor. But it'll work.
But any answer it gets makes no sense anyway, as it doesn't have the
actual required data of the real local .homenet zone. So whether you
give a NXDOMAIN or SERVFAIL or return an A record with 127.0.53.53
doesn't really matter, whether you are 8.8.8.8 or 216.146.35.35.
I guess the only possible exception to this is if the device in the
.homenet got multiple DNS servers from DHCP, and only one of them
and not the first one handles .homenet properly. Of course that's
a pretty broken setup to begin with, so I'm not too worried about
breaking that more.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
