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

[Philip Homburg <[e-mail]>]

> 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?