Hi, Sorry for the slow response — I missed your response.
> Can you explain how this is relevant to the .internal discussion which is > specifically reserved to be used in DNS? I was apparently unclear, apologies. To clarify, in a previous message that I was responding to you stated: >> The problem starts when a standards track document promotes a name that >> does not exist for some purposes. My references to 2606 (not 2605 as you noted), 7686, and 9476 were to point out that the IETF has, for quite some time, documented (I don’t believe documenting something is equivalent to promoting it, but that may just be me) a number of domain names that "do not exist for some purpose”, all of which are now included in https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. I fail to see the problem such documentation causes. I did not say .internal (or any of the others) should or should not be in the (public) DNS, rather I suggested that contrary to your assertion, problems start when users make assumptions about names that do not exist (within the DNS being implied). I personally believe having the documents that explain the intended use of particular names in one place is better than having them in random places known largely via lore, but YMMV. > I'm perfectly fine with delaying the .internal draft until such a > documentation has been created for general end-user devices. I’m unclear how this helps anything other than providing fodder to those who argue the IETF has become too process bound. > 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? Both of which sound like good topics to include in a draft on how validating stub resolvers should handle these (and similar) names. Regards, -drc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
