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: [email protected] Web: michael.de.roover.eu.org _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
