Hi Ted, On Jun 18, 2020, at 17:15, Ted Lemon <mel...@fugue.com> wrote:
> If we use these ccTLDs as squatting domains, that means that we’re going to > see a lot of traffic at the root trying to find nonexistent name servers, > right? And these ccTLDs provably do not exist, right? RFC 8198 was implemented in BIND9.12 and Unbound 1.7.0 and I think in other implementations too, although I don't have references immediately to hand. I thought I had seen the results of some experiments that tried to measure the effectiveness of aggressive negative caching but I can't seem to find anything obvious, so maybe I was mistaken. However, I would expect that as the deployment of 8198 increases in the resolver population (it defaults on in BIND9 and I think Unbound too) the extra traffic observed at the root should trend downwards. I think it's possible that if the question you pose is still a concern, it's at least a concern that is tending to decrease over time. > Contrariwise, home.arpa has an un-signed delegation. [As an aside, I have some concerns about RFC 8375 and I wish I was paying more attention at the time it was discussed. Although I can understand some of the technical arguments for the delegation, I'm not especially convinced by them in practice, and the decision to make the unsigned delegation also a *lame* unsigned delegation whilst simultaneously directing all leaked queries with potential information about private networks to be sent to nameservers that by design are intended to have anonymous operators is a poor one, I think. I note that the security considerations section doesn't even address the potential for information leakage.] > Also, what do you think the operational effect of this will be? Given that > these domains are currently provably nonexistent, this means that a resolver > looking up names in these domains will have to special-case them. I suspect it will work like every other locally-served domain or every other private namespace that exists today, i.e. just fine with no configuration changes expected or required on dependent (downstream) DNS clients. And if there are new species of resolver that need to be accommodated (e.g. validating, hybrid stub/full service resolvers embedded in applications), whatever configuration or auto-discovery mechanisms are required to support those other locally-served zones can surely be easily extended to these ISO-3166-2 codes if they are used in any particular private network. This draft describes an existing consequence of existing policy. It may be that Ed and Roy are the first ones to think about using them to anchor private namespaces, but in some sense any corner cases that need special handling today also needed special handling before this draft was written; we just didn't know it yet. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
