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

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I didn't have time to write a short note, so I wrote a long one instead.

On Mon, May 05, 2025 at 11:15:40PM -0500, Michael De Roover wrote:
>
>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.

One of the things about mostly disappearing from the IETF for a while and returning is to be reminded how stuff stays the same, and I am nonplussed to see that this is one of those topics.  I contend once again that there is a reason people keep getting wound around this axle, and it is the failure to take into account different classes of things.

To begin with, there are names that are squarely outside the DNS.  For instance, any name with at least one label longer than 63 octets plus the separator is, by definition, outside the DNS.  (I include this for completeness, but it isn't an issue in this discussion.)

Second are names that are logically speaking candidates to be in the DNS, but that have a specific role to tell you that in fact a different name system is involved.  It is unfortunate that, historically, people decided they had to use in-band signalling for this, but I admit I cannot think of something else that would have worked for deployment.  Good examples of this are .local and .onion.  Each of these is supposed to tell a resolver, "Look out!  We're switching protocols!"  A conforming resolver will do the right thing.  Of course, this being the Internet, there is no way to know whether a given system will in fact be conforming, so the documents have to specify what to do in case such protocol switches don't work (and they do so). There is some inter-organizational Hokey Pokey to play here if the protocol-switch names appear to be TLDs, because it's important to ensure the organization that manages the actual DNS root doesn't collide with these special uses, particularly when the special uses are being designed.  Moreover, there is the problem of people actually attempting a proof of the slogan that protocols are politics by other means, in which they are trying to create a protocol especially to go around the policies of that other organization.

Third are names that are intended to be used in an ordinary DNS context.  The official position of the IAB, at least, has been for many years that the domain namespace (or maybe the DNS namespace, but I doubt it -- I don't think the protocol-switch understanding was as full as it might have been when RFC 2826 was written, but I think it still has to apply to all domain names) is a unified one that all but creates the uniform network of networks.  This would seem to entail that, if you want to use a domain name outside the context of the global public DNS but still want to use the DNS with it, you should just register a domain name and use that, and not publish the records in a public manner.  That has been the advice to network and system administrators, for whatever it's worth, for as long as I can remember -- certainly, since years still began with a 1.  Nevertheless, this position has the distinct problem that it doesn't match what people actually do.

And so we are at the degenerate case of giving a place within the DNS, that uses the DNS in a normal way, but that is officially reserved as being for private use.  Leaving aside the probability that anyone who is going to do this sort of thing is going to do it in conformance with yet another IETF document on the topic, I think asking whether DNSSEC ought to work normally in this case is to make an error.  The only way you can get DNSSEC to work reliably under such a case of name-overloading is to have local trust anchors that allow you to establish trust at some point in the private namespace.  But since the namespace is private and unmanaged, there is no way to make that work reliably in a world where devices regularly wander between networks.  In the absence of an automatic local trust-anchor installation mechanism that happens at network auto configuration (the very idea of which strikes me as creating way more problems than it is likely to fix), I don't see how DNSSEC is compatible with this degenerate use of a global namespace with an overloaded private use space.

Perhaps this is just a long way of saying that RFC 1918-for-DNS is actually a terrible, no good, very bad idea, but people are going to do it anyway.  So all one can do is accept that degenerate cases entail more degenerate uses, and I therefore think that trying to make DNSSEC work in any reliable way with .internal is a fool's errand, no matter what one tries.  Other cases like .onion are irrelevant, because they're protocol switches that tell you go go somewhere else.

Best regards.

A

-- 
Andrew Sullivan
[e-mail]