Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
Warren Kumari <warren@kumari.net> Thu, 29 March 2018 20:46 UTC
Return-Path: <warren@kumari.net>
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 28626129C59 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 13:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 TpG5bW1ovhX3 for <dnsop@ietfa.amsl.com>; Thu, 29 Mar 2018 13:46:06 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052EC12741D for <dnsop@ietf.org>; Thu, 29 Mar 2018 13:46:05 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id u11so6475685wri.12 for <dnsop@ietf.org>; Thu, 29 Mar 2018 13:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A6mmHpO38cikM9BxXRC5/zOj/IKvp46q4dLJfSybSF0=; b=KJj1ZL7uvpHFcmFI5ekgfl+Xwv3j/upFJNh1Dlj8Iz1EA8O6zGSfGf+i9irBenB9Xk pbzyRBS+vTNrBHVTwlm83aMhoR1OHJqIFyS7RPrrr5VB0jf5iCELjmHEX9hqK7m8s6aM JAokETqqUF78S7iYpAymBxCCo4toRsaJmyqkhHpNSeS958O8bTUG/SJRSSGlJraPbdnv l8cFdOynWHDhUqjrHfq3EeZJHCSqc8KXLbWt5DdfkMGCUP1F/BSvekW+VVAE6J6RfNJC 7snFzEnGztyTvsqBHRl2s+huJZtKXcMAyHRiqR7Ui8B73Gwufl0Vz0H4qj1cO2+QesbA IL+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A6mmHpO38cikM9BxXRC5/zOj/IKvp46q4dLJfSybSF0=; b=C4hh3JX8hMU+0B58ju3ltw8sOHxV02NP+XIt9PHbVb+MkZ4D6zbF5PFqpwghcnpMOB V3qRNOqX4M3qZwJvhIbCKRtDIe0cH8VNL+S9VSP+zcMRlC2a5Q0POhOhYzaAOWjrC+0E OcCjsm3KciPFM3b8FjMEwBZ3Jb+ftqJUYeFVA7yzLiN5qpfMd9AqDXk9t4ODlHrysUY0 dKp8srUpQvA0tXi+u6IMP0vgK2h/Py9XuA7Xi3nNv0MpGFuGLMATQcC5YNpvGVUVYXF0 EE2Ri6lcC+5mUHgszZlDagM6g/v+aDJXQfC7OhZirO0MLZ2h9h6yeQrN/i78usLDBffq FFRw==
X-Gm-Message-State: AElRT7GRT8t3fL/FAEMODeruFzzQbDaAO0nQREKu8SPmnD8kmEPcnxxj NHNfixp66S4/1CGtbhF6ZX1b/U86ss67NsDDw+6rPpWmwnY=
X-Google-Smtp-Source: AIpwx4/hMUA904Zt8nTLv1QL3PUhXcajZo965rYD7ABVD2RPbUmrRm/11IIru3llOdpO2ZXo60SVUz4egvzp3SoZNlU=
X-Received: by 10.223.131.229 with SMTP id 92mr7896403wre.249.1522356363795; Thu, 29 Mar 2018 13:46:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.226.76 with HTTP; Thu, 29 Mar 2018 13:45:23 -0700 (PDT)
In-Reply-To: <C10EFF0FB6AC68625A75D485@PSB>
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> <C10EFF0FB6AC68625A75D485@PSB>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 29 Mar 2018 21:45:23 +0100
Message-ID: <CAHw9_i+69CGrZnW6XqvP6Qk1Cw+QoFKHCzqO4Hb=C6UkDvZkVg@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Applications and Real-Time Area Discussion <art@ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/UdpzbRgnmZrGUF2jfW1EkEWn4JY>
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: Thu, 29 Mar 2018 20:46:10 -0000
On Mon, Mar 26, 2018 at 9:21 PM, John C Klensin <john-ietf@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 > <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 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] 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