In message <1dbb47a4-c6e2-97d2-a1d7-ce6c65a40...@eff.org>, Jacob Hoffman-Andrews writes: > On 08/01/2017 03:48 AM, Mike West wrote: > > The only open issue I know of is some discussion in the thread at > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I > > need help synthesizing into the draft. I don't know enough about the > > subtleties here to have a strong opinion, and I'm happy to accept the > > consensus of the group. > > Reading back through this thread, it seems like the concerns were about > how to represent the ".localhost" TLD in the root zone, or how to use > DNSSEC to express that the root zone will not speak for ".localhost". > However, I think we don't need either. This draft attempts to codify the > idea that queries for "localhost" or "foo.localhost" should never leave > the local system, and so it doesn't matter what the root zone says about > ".localhost". > > I would even take it a step further: It would be a mistake to add any > records for ".localhost" to the root zone, because it would mask > implementation errors. If a local resolver accidentally allows a query > for "foo.localhost" to hit the wire, it should result in an error. > > IMHO, the document is good as it stands.
The query for foo.localhost doesn't need to hit-the-wire for this to be a issue. Ask your self why RFC 6303, Security section has As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa". We didn't add the requirement for insecure delegations for the fun of it. We added it so that the tools that validate will not break when those names are being used. The only difference between the names in the above documents and .localhost is the size of the space where they are valid. It is restricted to the node rather than the site. Mark > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
