Re: [DNSOP] [apps-discuss] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07

Dave Crocker <> Sat, 14 November 2015 23:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B88F1A8F44; Sat, 14 Nov 2015 15:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eCC5rhABXZDD; Sat, 14 Nov 2015 15:26:07 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFF801A8AAF; Sat, 14 Nov 2015 15:26:07 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id tAENQ65I016446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 15:26:06 -0800
References: <20151114202844.9601.qmail@ary.lan>
To: John Levine <>
From: Dave Crocker <>
X-Enigmail-Draft-Status: N1110
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sat, 14 Nov 2015 15:26:04 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151114202844.9601.qmail@ary.lan>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sat, 14 Nov 2015 15:26:06 -0800 (PST)
Archived-At: <>
Subject: Re: [DNSOP] [apps-discuss] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Nov 2015 23:26:09 -0000

On 11/14/2015 12:28 PM, John Levine wrote:
> RFC 6335 came out five years after the
> first version of your draft and would have been a fine opportunity to
> de-mess.

Given what it was trying to do, I don't think they could reasonably have
tackled this topic.  However I suppose it's nice that they sought to
enfoce a "no underscores" rule for their table, since it facilitates the
re-use of the names under SRV.

The more serious problem, IMO, is that the SRV spec has such a fuzzy
spec for the alternative names that might be used besides _udp and _tcp.

I tried to accommodate this actively in the earliest versions of the
draft -- even to the point of having the registry be hierarchical -- but
seem to have fallen back to something as fuzzy as the SRV spec itself.
I finally decided flat organization suffices but didn't care the
requirement for explicit registration forward. Yuck.

At this point, after looking at the relevant SRV spec text again, I
believe the only respectable solution is to change that part of the SRV
spec and dictate that the service names must be registered in this IANA
table.  I do not see a "inherited from the IANA service names table"
model as being viable, since it almost encourages name collisions.

> Assuming the places in the draft where you refer to the left-most name
> you mean the right-most name for what gets registered, it needs to
> make clear what names enable what sub-names.

oh my.  ummm.  yes.  i only wish i could attribute this to alcohol or

> For example, if a name is _tcp or _udp, all of the names in the RFC
> 6335 service name registry are eligible.  This includes _soap-beep and
> _xmlrpc-beep which are in that registry, and _certificates and _crls
> which should be but aren't.  But RFC 2782 is pretty casual about what
> protocols other than _tcp and _udp correspond to SRV names.  IANA has
> a protocol registry at
> but a lot of the entries are not obvious candidates for SRV.  On the
> other hand, RFC 5509 makes _sip a SRV protocol name even though it's
> also a service.
> DKIM currently allows _adsp as a subtag, probably not worth making a
> registry, since there don't seem to be any other likely DKIM subtags.
> Similarly there's _report._dmarc which seems to be a one-off.

For got that.  Thought it was indepedent. ADSP is now removed from the


Dave Crocker
Brandenburg InternetWorking