Subject: [DNSOP] Registry of non-service _prefix names?

From: "John Levine" <[email-masked]>
Date: 13 Nov 2015 18:00:33 -0000

Over in the dbound working group we have some proposals that would use yet another
underscore prefixed name to avoid name collisions.  (It's not a substitute for a
new RRTYPE; they need the prefix whether the data is TXT or a new type.)  In
the mail world we have _domainkey and _dmarc and likely others.  DANE is
proposing prefixes for publishing PGP and S/MIME keys.

The services registry from RFC 6335 includes all the names for services, but
not the prefixes for things that aren't services.  How hard would it be either
to update 6335 to provide for non-service names, or a new non-service registry
with the understanding that it shares the 6335 FCFS namespace?

R's,
John

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 13 Nov 2015 18:53:28 +0000

Seems there's some hair-splitting here over the definition of the word "service".

While RFC 6335 assumes, more than it defines, what a "service" encompasses, it offers the following "functional" definition of the kind of things which need and use "service name"s:

Service names are the unique key in the Service Name and Transport
   Protocol Port Number registry.  This unique symbolic name for a
   service may also be used for other purposes, such as in DNS SRV
   records [RFC2782].  Within the registry, this unique key ensures that
   different services can be unambiguously distinguished, thus
   preventing name collisions and avoiding confusion about who is the
   Assignee for a particular entry.

Seems like "PGP and S/MIME key publication" would fall under this definition of things-which-need-and-use-service-names, so why not just go ahead and register the names through http://www.iana.org/form/ports-services? Don't be intimidated by all of the references on the application form, to port numbers, since RFC 6335 makes it quite clear that the registry supports "port-less" service names ("Application designers also have the option of requesting only an assigned service name without a corresponding fixed port number if their application does not require one", "This document defines rules for assignment of service names without associated port numbers, for such usages as DNS SRV records [RFC2782], which was not possible under the previous IANA procedures"). If one scrolls to the bottom of http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml about 800 "port-less" entries will be found.

									- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of John Levine
Sent: Friday, November 13, 2015 1:01 PM
To: [email-masked]
Subject: [DNSOP] Registry of non-service _prefix names?

Over in the dbound working group we have some proposals that would use yet another underscore prefixed name to avoid name collisions.  (It's not a substitute for a new RRTYPE; they need the prefix whether the data is TXT or a new type.)  In the mail world we have _domainkey and _dmarc and likely others.  DANE is proposing prefixes for publishing PGP and S/MIME keys.

The services registry from RFC 6335 includes all the names for services, but not the prefixes for things that aren't services.  How hard would it be either to update 6335 to provide for non-service names, or a new non-service registry with the understanding that it shares the 6335 FCFS namespace?

R's,
John

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 13 Nov 2015 20:17:14 +0100

On 13 Nov 2015, at 19:00, John Levine wrote:

> It's not a substitute for a
> new RRTYPE; they need the prefix whether the data is TXT or a new type.

Clarification, my english is not good enough...

What you mean is that they believe they do need the prefix regardless of what RRType they will use, including TXT?

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 13 Nov 2015 14:56:00 -0500

> What you mean is that they believe they do need the prefix regardless of what RRType they will use, including TXT?

Yes, the prefix is part of the design.  See draft-levine-orgboundary-03

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2015 20:04:24 -0000

>why not just go ahead and register the names through http://www.iana.org/form/ports-services? Don't be intimidated by all
>of the references on the application form

If people think that's OK, I'll send in registrations for _domainkey and all.

R's,
John

---

From: Ray Bellis <[email-masked]>
Date: Sat, 14 Nov 2015 06:58:24 +0000

> with the understanding that it shares the 6335 FCFS namespace?

Dave Crocker previously did some work on an I-D for a (portless) service 
type registry - I recall he and I discussed it back at the Orlando IETF.

It would be good to see that resurrected.

Ray

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Nov 2015 09:07:46 -0800

> It would be good to see that resurrected.

Done.

This will be the third or fourth try for the document.  Perhaps there is
now enough community interest to make it happen?

d/

-------- Forwarded Message --------
From: [email-masked]
To: Dave Crocker <[email-masked]>
Subject: New Version Notification for draft-crocker-dns-attrleaf-07.txt

A new version of I-D, draft-crocker-dns-attrleaf-07.txt
has been successfully submitted by Dave Crocker and posted to the
IETF repository.

Name: draft-crocker-dns-attrleaf
Revision: 07
Title: DNS Scoped Data Through '_Underscore' Attribute Leaves
Document date: 2015-11-14
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/internet-drafts/draft-crocker-dns-attrleaf-07.txt
Status: https://datatracker.ietf.org/doc/draft-crocker-dns-attrleaf/
Htmlized: https://tools.ietf.org/html/draft-crocker-dns-attrleaf-07
Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-dns-attrleaf-07

Abstract:
Historically, any DNS RR may occur for any domain name. Recent
additions have defined DNS leaf nodes that contain a reserved node
name, beginning with an underscore. The underscore construct is used
to define a semantic scope for DNS records that are associated with
the parent domain. This specification explores the nature of this
DNS usage and defines the "underscore names" registry with IANA.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 14 Nov 2015 20:28:44 -0000

>now enough community interest to make it happen?

The more I look at this, the more of a mess I find.  It's not like it
would have been all up to you.  RFC 6335 came out five years after the
first version of your draft and would have been a fine opportunity to
de-mess.

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.

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
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
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.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Nov 2015 15:26:04 -0800

On 11/14/2015 12:28 PM, John Levine wrote:
> RFC 6335 came out five years after the

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.

> make clear what names enable what sub-names.

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

> 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
draft.

d/

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 14 Nov 2015 22:56:29 -0500

Dave

I would sign up as chair if there is enough interest to resurrect this.

tim

---

From: "John Levine" <[email-masked]>
Date: 15 Nov 2015 04:14:45 -0000

>I would sign up as chair if there is enough interest to resurrect this.

I brought it up, I'm willing to work on it.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 15 Nov 2015 00:55:12 -0500

I think this is OK as an individual and as co-chair.

tim

---

From: "John Levine" <[email-masked]>
Date: 15 Nov 2015 12:42:11 -0000

>I think this is OK as an individual and as co-chair.

In view of the other discussion we've had, _domainkey doesn't belong in ports and services
since it's not something you use as _blah._proto.name in a SRV or NAPTR lookup.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Nov 2015 00:19:39 -0800

> I brought it up, I'm willing to work on it.

Likewise.  Also willing to help DISPATCH it via another route if DNSOP
doesn't take it up.  :-)

-MSK

---

From: Ray Bellis <[email-masked]>
Date: Mon, 16 Nov 2015 08:39:54 +0000

> now enough community interest to make it happen?

Thanks Dave :)

>From my previous recollection of this, ISTR there was a suggestion that
your draft only directly register "single-label" names, but with "_tcp",
"_udp" et al listed in the registry as a link to RFC 6335?

kind regards,

Ray

---

From: "John Levine" <[email-masked]>
Date: 17 Nov 2015 02:05:47 -0000

>"_udp" et al listed in the registry as a link to RFC 6335?

It seems to me that this needs three columns, like this:

Name	Reference	Type
_tcp	RFC2782		Proto
_udp	RFC2782		Proto
_domainkey	RFC6376	App
_vouch	RFC5516	App

There's a short list of types.  Proto is a protocol that can have any
of the RFC6335 service names as a subnode on SRV or NAPTR records.
App is an application that names TXT records and generally has no
prefixed subnodes, or if it does it's just a handful that are
mentioned in a footnote.  There may be other types, but probably
not many.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Nov 2015 08:59:45 -0800

> "_udp" et al listed in the registry as a link to RFC 6335?

(oops.  missed the need to respond to this.)

It's taken awhile, but I've finally come around to thinking that, yes,
the public registry needs to be only for the 'global' part of any of
these namespaces.  I originally attempted to cover a complete hierarchy
of underscore names, but the term "tar baby" isn't sufficient to impart
how intractable that became.

So in DNS terms, that's the 'highest' underscore name.  Anything below
them is scoped to be invisible to the public concern.

d/