It can be solved with a trust anchor as well, but that relies on there being a central validating resolver rather than validating stub resolvers on hosts, and personally I don’t find that deployment model very compelling anymore—I think that stub resolvers should validate. If I get my way, then we’re going to see these “private” domains start to fail.
Sent from my iPad > On Jun 18, 2020, at 1:36 PM, Vladimír Čunát <vladimir.cunat+i...@nic.cz> > wrote: > > >> On 6/18/20 7:22 PM, Ted Lemon wrote: >>> 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. >> >> What I’m getting at is that the secure denial of existence will mean that a >> DNSSEC-aware resolver, when asked to look up a name under .xa, for example, >> will always return NXDOMAIN. > Yes, but squatting is usually done at root names already, so the issue isn't > new. > > Modifying DNS past the last validator is generally troublesome. Modifying it > inside the last validating resolver can be fine, as the implementation can > "prioritize" the modifications over validation and aggressive caching (but as > an implementor I still find this troublesome). > > --Vladimir
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
