--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari <war...@kumari.net> wrote:
> On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker > <d...@dcrocker.net> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop