Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
John C Klensin <john-ietf@jck.com> Mon, 26 March 2018 20:21 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EF81276AF; Mon, 26 Mar 2018 13:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp3C6IOY78zu; Mon, 26 Mar 2018 13:21:42 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5E7126CC4; Mon, 26 Mar 2018 13:21:41 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1f0Ycd-000HpW-QT; Mon, 26 Mar 2018 16:21:39 -0400
Date: Mon, 26 Mar 2018 16:21:33 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net
cc: art@ietf.org, dnsop@ietf.org
Message-ID: <C10EFF0FB6AC68625A75D485@PSB>
In-Reply-To: <fe24bb1d-a2e2-c50a-4293-b9c4cadcfc69@dcrocker.net>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net> <5F44FA5B42805C52479DE491@PSB> <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.meeting.ietf.org> <1DF1564CC2B88726B2B54CF4@PSB> <20180326171842.0eacbdc4@smaug.local.partim.de> <32837C4DF5CB5BDD00DAD0FD@PSB> <fe24bb1d-a2e2-c50a-4293-b9c4cadcfc69@dcrocker.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/h9Qr7PQl5jfxdYjlgwN-kqmzTgY>
Subject: Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2018 20:21:44 -0000
(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 <dhc@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] Fwd: New Version Notification for draft-i… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… tjw ietf
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] Fwd: New Version Notification for dra… John R. Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] New Version Notification for draft-ie… P Vix
- Re: [DNSOP] New Version Notification for draft-ie… Dave Crocker
- Re: [DNSOP] New Version Notification for draft-ie… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John C Klensin
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] New Version Notification for dr… Paul Vixie
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] redefining SRV, New Version Not… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R. Levine
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… Alexey Melnikov
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] redefining SRV, New Version Not… Ray Bellis
- [DNSOP] Attrleaf _second-Level modifications (was… Dave Crocker
- Re: [DNSOP] Attrleaf _second-Level modifications Ray Bellis
- Re: [DNSOP] [art] New Version Notification for dr… John Levine
- Re: [DNSOP] [art] New Version Notification for dr… Andrew Sullivan
- Re: [DNSOP] [art] New Version Notification for dr… Dave Crocker
- Re: [DNSOP] [art] New Version Notification for dr… John R Levine
- Re: [DNSOP] [art] Attrleaf _second-Level modifica… John Levine
- [DNSOP] Another look - draft-ietf-dnsop-attrleaf-… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Martin Hoffmann
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Martin Hoffmann
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Kurt Andersen (b)
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… John C Klensin
- [DNSOP] _openpgpkey & _smimecert (was: Re: [art] … Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- [DNSOP] namespace and substring reservations (was… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Ray Bellis
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- [DNSOP] Additional uses of underscore labels (was… Martin Hoffmann
- Re: [DNSOP] Additional uses of underscore labels Dave Crocker
- [DNSOP] End-to-end _underscore arguments (was: Re… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Dave Crocker
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Warren Kumari
- Re: [DNSOP] Another look - draft-ietf-dnsop-attrl… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John C Klensin
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Adam Roach
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Dave Crocker
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… Paul Vixie
- Re: [DNSOP] [art] Another look - draft-ietf-dnsop… John R. Levine