I think a usefully relevant bibliography would have to include RFC8375 and BCP 163.
> On 3 May 2025, at 19:18, Philip Homburg <pch-dnso...@u-1.phicoh.com> wrote: > >> Like: >> >> RFC 2605 > > Maybe 2606? > > It says: > > "To safely satisfy these needs, four domain names are reserved as > "listed and described below. > " > ".test > ".example > ".invalid > ".localhost > " > "".test" is recommended for use in testing of current or new DNS > "related code. > " > "".example" is recommended for use in documentation or as examples. > " > "".invalid" is intended for use in online construction of domain > "names that are sure to be invalid and which it is obvious at a > "glance are invalid. > " > "The ".localhost" TLD has traditionally been statically defined in > "host DNS implementations as having an A record pointing to the > "loop back IP address and is reserved for such use. Any other use > "would conflict with widely deployed code which assumes this use. > > None of these is supposed to be used in production use for general end-user > devices. Which the exception of localhost, which tends to be hardcoded in > stub resolvers or is taken from /etc/hosts. > >> RFC 7686 > > .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. > >> RFC 9476 > > .alt > > Again, not DNS. No need to worry about DNSSEC validation because no DNS > is supposed to exist under .alt. > > Can you explain how this is relevant to the .internal discussion > which is specifically reserved to be used in DNS? > >> 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? > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
