On 6 May 2025, at 02:12, David Conrad <d...@virtualized.org> wrote: > Out of curiosity, do you think > https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > should be limited only to protocols the IETF has "control and authority” and > are “implicated in IETF specifications”?
I don't think that that registry is usefully similar to the root zone. There's a long history of service names and port numbers being reserved other than by IETF documents, and I don't think the same can be said for the root zone. Maybe that doesn't matter but it seems like a difference. >> Another question, what is the difference between: > > I’ll play! :-) I don't remember an I-D that mentioned CORP but perhaps I've just blanked out the memory as a defence mechanism. And sure, almost all of my answers were terrible, almost as if they were rhetorical. However: >> 3. Nothing, in the sense that none of them require any special handling by >> DNS servers or clients. > > Since this thread has been discussing whether or not there needs to be > special handling of .internal (e.g., DNSSEC goop), this answer appears to be > wrong. I think this is an example of how 6761 is a bit vague. Adding INTERNAL to the special use domain names registry is the only useful purpose for this document, I think, which is why I think the adoption decision hinges on whether INTERNAL can usefully be considered special. I think special in this case means software changes are required in clients and servers, e.g. "use this other protocol to resolve names under LOCAL". I don't see that for INTERNAL, or CORP, or oweifeowihfoihewfwe, or whatever private-use 3166-alpha2 code I mentioned. I don't think INTERNAL is special in this way, and I don't understand why people who think INTERNAL is, in fact, special don't find CORP and friends special. I think specifying an insecure delegation in the root zone is something that this document could do, but I think it shouldn't. I think an IETF document directing the IANA to make a change to the root zone would be crossing the streams in the Ghostbusters sense, by which I mean it is not something that should be attempted casually. Any document that does something like that ought to be anchored in the IAB and littered with liaison statements and protective charms that describe all the ways in which this is a special and unusual situation. It shouldn't be the product of a working group. Making the contents of the root zone a matter of working group consensus seems like a terrible idea. Joe
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
