Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

[John C Klensin <[e-mail]>]

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari
<[e-mail]> wrote:

> On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker
> <[e-mail]> wrote:
>> On 3/29/2018 1:45 PM, Warren Kumari wrote:
>>> 
>>> I don't want to get into if this is the*right*  behavior or
>>> not, but it seems like worth mentioning in the draft as it
>>> has much background already...
>>> I can find nothing which states that A / AAAA cannot be
>>> associated with underscore names, but they sure don't seem
>>> to work in practice.

>> The current version is:
>> 
>>    https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>> 
>> Please suggest specific text to use and where to put it.
> 
> I'm hoping someone will pipe up with "Gee, RFCfoo, Section
> bar, Bullet N clearly says this, I can't believe you never
> knew that...."
> 
> If that doesn't occur I'll craft text.

Warren, just to clarify where I'm coming from (and noting Paul
Vixie's recent comment).  I think there is no question that
putting a label starting with an underscore (or containing one)
on an RRSET that includes an address record would be
ill-advised, nor that some implementations (possibly because
they consider it ill-advised or just plain dumb) won't allow it
or won't make it easy.   I think there is no question that
underscores (leading or otherwise) have no more place in either
historical (e.g., RFC 952) host names or the "preferred syntax"
of RFC 1034/1035 than, e.g., "+", "$", "%", or "/" do.  I am
reasonably confident that you are not going to find a normative
statement that says that the term "host name" (with or without
an intervening space) is any label, or the left-most label,
associated with one or more address records, nor as statement
that host names in the DNS MUST conform to the preferred syntax.
Indeed, the description in RFC 7719 appears to me to be
consistent with what the specifications actually say and it
contains the same "any octet value" language that appears in
earlier, normative, documents including RFC 8121.

My objection was narrow.  The text, even at -06, reads

	'"host" (host name) are not allowed to use the
	underscore character, this distinguishes the underscore
	name from all legal host names [RFC1035]"'

That is objectionable for two reasons.  First and most
important, RFC 1035 just does not say that.  If the text had
referenced RFC 952 instead, it would have been correct, but
maybe not so useful.   Similarly, if it had said, more or less
following 7719, that generally-accepted domain names that
identify hosts ("host names") conform to the preferred syntax of
RFC 1034 (or 1035) and hence do not include underscores, there
would be no problem (if someone wants to take that as proposed
text, feel free).  

Second, as has been discussed many times before in the last
decade or two, "legal" is not a good term to use to describe
validity or conformance in RFCs.  Our standards are voluntary,
which makes it hard for them to assign legality or illegality
to, in this case, particular bits of syntax.  Moreover, the
concept of something being legal or illegal implies that, if the
latter is discovered, I should be able to call the Protocol
Police and have the offending label or its perpetrator arrested.
When last I tried, they were not answering their phone or even
their email.  The IESG has pushed back on that term in the past
and should, I believe, be pushing back on it today, regardless
or what might have been said in kinder and gentler times.

However, I believe that this discussion is, however
unintentionally, a distraction from a far more important issue.
The way the DNS, and particularly DNS queries, are defined makes
the idea of a namespace for all labels starting with "_" very
difficult and potentially a source of confusion.  While sorting
the registry by RRTYPE is an improvement over earlier versions,
the correct structure  is to have subregistries by RRTYPE, each
with whatever keywords (starting with underscore) are
appropriate for use with it listed.  I do not believe it is
appropriate to lose that distinction while we quibble about the
language used to describe the syntax of host names.

best,
   john