Re: [Rfc6761bis] New Non-WG Mailing List: rfc6761bis

[Keith Moore <[e-mail]>]

On 12/13/22 15:18, Joe Abley wrote:

> Hi Warren,
>
>
> On Tue, Dec 13, 2022 at 17:03, Warren Kumari <[e-mail]> wrote
>
>> I think that the root issue is that there is not a simple way to 
>> determine if a name is included in "that subset of the domain 
>> namespace that is used by IETF protocols like the DNS".
>
> Perhaps part of the problem is phrasing that particular question as 
> though it has a simple answer. The nature and composition of the 
> namespace depends on the vantage point.
>
> I think the IETF has done fine for years understanding what the 
> DNS/zeroconf/dnssd/whatever namespaces looks like without needing a 
> strict definition, with due deference to Robert Persig and apologies 
> for the oblique suggestion of quality.
>
> People have been intentionally causing name collisions with hosts.txt 
> overrides, nsswitch.conf, locally-served zones, etc, etc for decades 
> and it has not caused any great indigestion.

I might disagree here.  I've seen too many cases in which applications 
were broken by these mechanisms.   To the extent that these mechanisms 
work, they rely on users and/or IT people magically understanding which 
names will cause problems if overridden and which ones won't.   The more 
diverse the name space, the less likely that they are right.  And the 
diversity of the name space can only be expected to increase over time.

And yet, I'll admit that the ability to override a name lookup is often 
useful in corner cases, and sometimes essential.   Such as: blocking 
lookups of DNS names known to be used by malware.

> Unintentional name collisions occur every millisecond. Domains exist 
> in some networks that do not exist in any others. Domains are missing 
> from the perspective of some clients that are very much alive and well 
> to the majority. Zones do not propagate instantly. People mess things up.
>
> Every single one of these things represents an opportunity to 
> further bifurcate the domain namespace. The resulting uncertainty 
> has caused no end of angst at ICANN when they have decisions to make 
> about new TLDs but does it make the understanding of what the DNS 
> namespace is in the IETF any more difficult in practical terms?
>
> I think we need to step back and ask what it is that we are trying to 
> achieve.

I like to say that part of IETF's job is to "make the Internet safe for 
applications".  What I mean by that is that applications need to have a 
fairly predictable environment to operate in, no matter where they're 
operating from.   If applications can't trust the network and network 
infrastructure like DNS to do their jobs, the applications have to make 
unreliable guesses, and the result is a mess.

That predictable environment relies significantly on protocol 
standards.  (It also relies significantly on operational standards, 
which IETF does less well, and is less well placed to encourage or 
maintain).

I would propose this as a criterion with which to evaluate both protocol 
standards and operational practices, whether or not related to DNS.

> Are we in the business of asserting control over the whole domain 
> namespace? Do we want to be the self-appointed, enforcement-free 
> gatekeepers who decide who can use what for what?
Without answering that question, I think it's at least useful for us to 
specify what it takes to make applications operate predictably. Whether 
we can require those rules to be followed is a different question.

>
> How is the special names registry actually used? We have asserted that 
> it is useful. Was it instantiated mainly to justify a desire for the 
> use of LOCAL or does it really have a higher purpose?
>
> Is it helpful for things to be included in the special names registry 
> because the way they were assigned or registered is special, even 
> though there is nothing special in how they are used?

Consistent with the reasoning above, I would claim that the special 
names registry is potentially useful if applications can make use of the 
information in that registry to improve their 
reliability/predictability, or to be better at detecting problems that 
arise from the use of those names.

e.g. applications should not expect "something.local" to mean the same 
thing everywhere.

> Why is LOCAL better than LOCAL.ARPA?

It's easier to type, and presumably more likely to be used. Also, for 
better or worse, the .local convention was widely deployed before there 
was any attempt to standardize it.  Assuming for the purpose of argument 
that there was a valid need for something like .local, it was probably 
easier to use .local than to try to get the vendor and user communities 
to migrate to some other (and probably uglier) convention.

Incidentally, .local is a good example of how name collisions can cause 
problems.  My home router has a DNS resolver that it advertises via 
DHCP.  That resolver tries to answer lookups for .local based on who 
knows what voodoo, sets .local as a default suffix for DNS lookups, and 
responds to PTR queries with answers ending in .local.  This conflicts 
with my computers' use of .local to mean "something to be looked up 
using mDNS".   Some of my computers disable mDNS lookups when they see 
the DHCP server advertising it, others don't.  Which basically means 
".local" is worse than useless on my home network - it's both unreliable 
and inconsistent.

>
> How was it that homenet specified use of the HOME domain 
> apparently without enough scrutiny and how do we prevent that from 
> happening again?

We could start by deprecating .home and discouraging its use, just as we 
deprecated IPv6 site-locals.  (I'm not stating a firm position that we 
should deprecate .home, though offhand I think it was a Bad Idea.  
Rather, I'm saying that we do have some precedent for deprecating bad 
ideas that were once standards.)

Keith