On Mon, Mar 26, 2018 at 9:21 PM, John C Klensin <john-i...@jck.com> wrote: > (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.
Actually, I'm not sure that that *is* a perfectly valid record, but for a completely different reason to your statement / argument. Many implementations simply will not resolve an underscore name to an A or AAAA, and at least one implementation (BIND) won't load a zonefile with them without bludgining: foo IN 600 A 192.0.2.1 _foo IN 600 A 192.0.2.2 _bar IN 600 CNAME foo.example.com. _txt IN 600 TXT "I'm a lumberjack..." gets you: $ named-checkzone example.com example.com example.com:11: _foo.example.com: bad owner name (check-names) zone example.com/IN: not loaded due to errors. 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. W > > 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 > <d...@dcrocker.net> 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/ > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
