[DNSOP] Re: [Ext] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

[Michael De Roover <[e-mail]>]

Hi, I had a read through v3 of the draft and have a couple more remarks, which 
this message seems to lean closest into. Thank you for having submitted it.

On Saturday, May 3, 2025 8:18:51 PM CEST Philip Homburg wrote:
> .onion
> 
> This is not DNS. Nobody is supposed to run a .onion zone anywhere. So
> no issue. From, a DNS point of view, this domain does not exist.

This is something I was reminded of, from seeing it in the SUDN registry and 
here. It reminds me of how web browsers enter the picture here (though DNS use 
of .internal does not seem limited to that). But being part of the Tor 
network, .onion does have a significant use for specific web browsers.

While MS Edge seems to have just treated it as-is just now (hmm), I might want 
to know that this is to be treated differently if I were a browser vendor 
(which I am not, though I do have a satirical project of that sort). And for 
that, I would look in the SUDN registry so that users attempting to visit a 
.onion in my web browser do not bother the root servers with it.

> Can you explain how this is relevant to the .internal discussion
> which is specifically reserved to be used in DNS?

Within the context of .internal, I would like to remark browsers' role in this 
for internal domain names (currently e.g. .lan in my networks). So the web 
browser has an omnibar, right. And depending on what you put into it, the 
browser needs to decide whether it should execute a DNS lookup and HTTP 
request, or treat it as a search query. For domains on .lan, it always seems 
to need a trailing /, most of the time not even . apex cuts it here. Which is 
annoying.

So being in the SUDN registry, maybe browser vendors would be inclined to at 
least consider treating .internal domains as "this is not a search query, that 
is a domain". MS Edge has proven to me tonight that this is still not a given. 
But it might draw some attention from some browser vendors. That's what I 
would want to achieve.

> .alt
> 
> Again, not DNS. No need to worry about DNSSEC validation because no DNS
> is supposed to exist under .alt.

I remember remarks from Martin Schanzenbach about that, in relation to GNS. I 
wonder how the project is doing now, at the time it did pique my interest... 
How do these kinds of domains get handled for DNSSEC and such by the roots? 
Same question for other domains currently in the SUDN by the way, notably 
home.arpa. and RFC1918 private-use IPs and their PTR zones.

> > As Paul points out, this suggests a need for documentation on how
> > an end-user device that happens to include a DNSSEC validator should
> > behave in the face of names that do not exist for some purpose.
> 
> 
> I'm perfectly fine with delaying the .internal draft until such a 
> documentation has been created for general end-user devices.
> 
> I'm curious what it would look like. Do we expect end-users to know to
> add a negative trust anchor for .internal when they arrive at work and then
> remove it again when they go home?
> 
> Does this involve editing a random config file somewhere on the device?

I'll admit that DNSSEC is something I know nothing about... 5 proverbial 
experience points, I know that it exists. But I don't use it, nor do I know 
how to. ZSK and KSK makes my head spin. But what I can say is that even if 
devices with such specific validator in them are far and wide in between, 
having to do all of that would be a major pain in the rear.

The draft does mention that the role of the root server operators should be 
minimal, which I think is a good idea. But for the stewardship role they have, 
perhaps DNSSEC should be handled there. Again, no experience here, but it 
would be good practice to place such configuration changes as high as 
reasonably possible in the chain.

-- 
Met vriendelijke groet,
Michael De Roover

Mail: [e-mail]
Web: michael.de.roover.eu.org