Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

[Ted Lemon <[e-mail]>]

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 <[e-mail]> 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