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
a...@crankycanuck.ca
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
