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

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

(top post) 

Dave,

I identified that issue as a nit deliberately.  This is a WG
document and I believe the document would be improved if a less
strong assertion were made, just because the issues of what,
exactly, a "host" is for DNS purposes and what it can be called
has been a source of controversy among those who seem to enjoy
such discussions for about as long as I can remember. Trying to
address that issue through this document is unnecessary and has
a bit of a "side effect" feel to it -- it would be sufficient to
say that there is a convention about using leading underscore
followed by a keyword with some RRTYPEs and then move on.

To answer your specific question, RFC 2181, Section 11, says
"...any binary string whatever can be used as the label of any
resource record."  I have not checked as to whether one of the
many updates to that document modifies that statement, but the
point is that 
   _tcp IN A 10.0.0.1
is a perfectly valid record, whether it identifies a "host" or
not.  It just doesn't have any special interpretation there
because there is no special namespace for "_" keywords
associated with the "A" RRTYPE.

Yes, that means that the use of leading underscores as a
contention is a risk, just as the use of "xn--" to identify the
need for IDNA processing is a risk.  In practice, the risks have
proven to be low for both.  Maybe they are lower for "_" because
the label strings are interpreted only in the context of
specific label types, but that is just one more argument for
binding the concept of a namespace for these names to the
RRTYPE, not global, RRTYPE-independent, use of the DNS.

However, I certainly don't have the time or energy to turn the
validity of hostnames into a long, drawn-0ut, debate.    It is
not, IMO, a really serious error in the context of this
document, at least unless a explanatory statement made here is
cited later as an authoritative definition.   If no one else in
the WG cares about it, so be it.

    john




--On Monday, March 26, 2018 09:54 -0700 Dave Crocker
<[e-mail]> wrote:

> On 3/26/2018 9:14 AM, John C Klensin wrote:
>> (1) The text in Section 1.1 says
>> 
>> 	'the DNS rules for a "host" (host name) are not allowed
>> 	to use the underscore character... legal host names
>> 	[RFC1035]'
>> 
>> 1035 does not say that.  Its section 2.3.1 is about what is
>> preferred, not what is required (or "legal").  It says
>> "should"
> 
> Note that when that spec was written, we didn't have such
> precise and rigid vocabulary rules.
> 
> But RFC 1123 should be cited, especially since it has more
> forceful language: "The syntax of a legal Internet host name".
> (RFC6055 seems to have missed the import of 'legal'.)
> 
> 
>> and "preferred", but there is no requirement.  As far as I
>> know, there has never been a serious attempt to turn that
>> preference into a requirement.  Indeed, RFC 8121 says exactly
>> the opposite
> 
> Please cite the specific text in that RFC you are referencing.
> 
> 
>> and, if there were a prohibition, RFC 6055 would have been
>> largely unnecessary.
> 
> Overall, it appears that your claim is that the underscore
> naming convention is predicated on an erroneous interpretation
> of 'hostname' restrictions.  As such, the entire activity is
> broken.
> 
> d/