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

[Ted Lemon <[e-mail]>]

I think a usefully relevant bibliography would have to include RFC8375 and BCP 163.

> On 3 May 2025, at 19:18, Philip Homburg <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]