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