Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

Dave Crocker <> Mon, 26 March 2018 16:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B006112D77C; Mon, 26 Mar 2018 09:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0nQZsJb2heWb; Mon, 26 Mar 2018 09:55:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 528FE129C6B; Mon, 26 Mar 2018 09:55:02 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w2QGuQP7005462 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Mar 2018 09:56:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1522083386; bh=er0ycBWGawM5sYl76dKD/9oC+bYbX/vCHdhVwZjEv10=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=VgIbzXPmGKTzR/DQnWX4dvlD6upOYtVCFNRezNJxtozmOOgQN7CCnHqdLe4AFtq63 Mu1HZlXupD4zb1VmYtcLRduEfq6u3ZgEtVXgqtxUMtsvdbuw4Ee4lHwkploooYch3d gD596rho8dKzf7TL1A70wsPPtF2lUnsJr31UXpzs=
To: John C Klensin <>
References: <> <> <> <> <> <alpine.OSX.2.21.1803211104210.9553@ary.local> <> <5F44FA5B42805C52479DE491@PSB> <> <1DF1564CC2B88726B2B54CF4@PSB> <> <32837C4DF5CB5BDD00DAD0FD@PSB>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Mon, 26 Mar 2018 09:54:56 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <32837C4DF5CB5BDD00DAD0FD@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Mar 2018 16:55:03 -0000

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.


Dave Crocker
Brandenburg InternetWorking