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 +1-571-434-5468
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
