Re: [dnsop] Underscore registration summary

[Edward Lewis <[e-mail]>]

This seems to be in conflict with the iab-dns-choices document.  One 
reason I brought up the existence of that document in the meeting in 
Montreal was situations like this - if the WG wants to recommend 
"prefixing names" it wouldn't be too wise to have the IAB saying 
"don't do that" at the same time.

I'm undecided on whether this is a good approach.  We do something 
similar for non-ASCII domain names and that seems to work.  But that 
isn't tying semantics to the label, just syntax.

We heard about the HTTP cookies and their folly of trying to 
distinguish "delegation-only" zones from others based on label count, 
only to find that 192.in-addr.arpa is more TLD-like than 
root-servers.net.

I know that SRV records have the concept of "_app+._transport.<base>" 
but I've seen that not work so well when CNAMEs are used for 
"services."  My SIP phone was configured with sip.ourlabs.example., 
so it tried to look up _sip._tcp.sip.ourlabs.example.  Problem was 
there is only a CNAME at sip.ourlabs.example.  There's a weakness in 
defining the shape of the tree to be such-and-such, as the IAB 
document mentions.  Not that this means the idea is dead (to me). 
But, still...

After umpteen years of DNS development, the basics ought to be 
getting more coherent...not just the data space.

At 7:26 AM -0700 7/17/06, Bill Fenner wrote:
>There are two possibly orthogonal issues here:
>
>1. Registration for any _foo that may appear, possibly just
>the one closest to the root in a given domain name.
>http://tools.ietf.org/html/draft-crocker-dns-attrleaf
>Its introduction points out that the semantics of records
>underneath the reserved node name may be restricted;
>however, this wording may need a bit of work because,
>e.g., dnssec may need to put records there no matter
>what the semantics defined elsewhere.
>
>2. Registration for service names used in SRV records.
>http://tools.ietf.org/html/draft-fenner-iana-dns-srv
>was my proposal some time ago (summary: update 2782
>to use the WKS name registry instead of a vague reference
>to 1700 that many have taken to refer to the port number/name
>registry, possibly populate the registry, define rules
>for new registrations).  This is related to
>http://tools.ietf.org/html/draft-lear-iana-no-more-well-known-ports
>in that it also says that IANA keeps registrations for
>SRV records; presumably whether or not IANA charges for
>well known ports is outside the scope of dnsop.
>
>
>How to move forward?  In a way, it's a question of one registry
>or two.  If draft-crocker-dns-attrleaf intends to have all
>protocols and services used in SRV records as well as the other
>contents, it could serve as both.  However, given the history, I
>think SRV records need a little bit different registration rules,
>so it may make sense to split them out into a different registry.
>The question there would be whether it's just the top-most
>prefixed label that gets registered in draft-crocker-dns-attrleaf
>or all of them.
>
>   Bill
>.
>dnsop resources:_____________________________________________________
>web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
>mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html