On 5/9/15, 1:10, "Suzanne Woolf" <suzworldw...@gmail.com> wrote:
>I share David’s reservations about this— how do we objectively and >reproducibly distinguish “people are using these in private networks” >from “people are generating arbitrary traffic to the roots for these”? One good characterization of the technical problem, although I'd modify the former to "people...networks and leaking the queries to the root". A recipient of a DNS query cannot know why it was asked (no context). So whether this is a leak or a gaming cannot be determined in-band. >Is there any concern for the IETF in a policy that says “If you start >using an arbitrary name that isn’t currently in the root zone, you can >just get the IETF to protect it for you”? I find this above statement a little unclear. Whose policy (as in ICANN policy/IETF policy/someone else's policy)? >Furthermore, given that ICANN has already said they won’t delegate these >names in particular, how is it helpful for the IETF to also add them to >the Special Use Names registry? I'll throw out what is in my personal mental model on this topic (as opposed to something explicitly documented elsewhere): For the non-DNS software using identifiers. If a layer in the software stack sees an identifier matching an entry in the Special Use Names registry, it should avoid trying to resolve the name using DNS. This issue is about more than the DNS. As far as the DNS, I believe it's really only about how it can be kept from harming other identifier systems[0] and not meant to be a way to "shape/prune" the DNS name space tree. [0] As in "name.onion." isn't a domain name, it's a string that happens to have dots in it. And at the end of it and otherwise appears to conform with the "BNF" in RFC 103-something - but that's just coincidental.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
