Subject: Re: SRV RR Questions

From: Michael Mealling <[email-masked]>
Date: 05 Dec 2002 18:41:49 -0500

On Thu, 2002-12-05 at 17:48, Cricket Liu wrote:
> Dave Wilcox wrote:
> > Are the underscores really required? or could I use:
> > 
> > service.protocol.target
> 
> The underscores are there by design, to avoid naming collisions with
> existing domain names.

As the author of RFC 3403 and 3404 and the co-author of the update to
RFC 2916 (ENUM), I get asked this quite a bit. Usually of the form:

The DDDS documents don't have the underscores that RFC 2782 says have to
be there. Does 2782 require me to put them in there or is RFC 3403
right?

The issue is/was that one of the iterations of the 2782 draft had
language saying that, if SRV was being used in a context where a client
was explicitly directed to retrieve a set of SRV records for an exact
domainname instead of doing the query-language-encoded-as-a-domainname
defined in 2782, then there was no requirement to use the underscores.
Due to time and those inevitible miscommunications that text never made
it into the final version that became 2782. Thus there is now a
confusion between 2872 and 3403 about whether or not '_' is needed in
the specific way that the DDDS uses SRVs.

Is it possible to get some kind of clarification that this is indeed the
case and that I don't need to go update 3403 and 3404 just to stick an
underscore into a domain-name that doesn't need it?

-MM

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Peter Koch <[email-masked]>
Date: Sun, 08 Dec 2002 17:37:18 +0100

> underscore into a domain-name that doesn't need it?

I did not find the critical section in 3403 but there is that example in
section 5.1 of 3404.
It seems to me that 'service' and 'protocol' shouldn't have been provided as
domain name prefixes but instead as seperate strings in the first place.
However, there's no option to change that now.

RFC 2782 does not only specify the SRV RR but also the way applications or
libraries are going to use this RR type to locate services. Unfortunately
in "The format of the SRV RR" it explicitly requires the first two labels
of the owner domain name to start with a '_'. So, following 2782 by the
letter, your usage would not be covered by the SRV spec. Then, this does
not make sense.

On the other hand, the way you use the SRV RRs starts one layer below where
2782 steps in. You already have the "translated" version at hand, so why
bother with "udp" and "tcp" at all? "foolink.udp.example.com" is as good or
bad as "foolink.example.com". But then, if you have a SRV-aware "rcds"
client (2nd example), it would ask for "_rcds._udp.example.com" and you'd
end up with two parallel sub-namespaces for the same purpose (_udp and udp).

So, for the sake of consistency, I'd think the '_' should always be used,
especially in documentation and examples to reduce readers' confusion.

-Peter

---

From: Paul Vixie <[email-masked]>
Date: Sun, 08 Dec 2002 17:39:55 +0000

> of the owner domain name to start with a '_'.

yes.  however, it's amendable.  we wanted to make sure that these names
could not conflict with any naturally occuring names, and leading _ is
naturally an error condition.  think of _ as the BPV used in DS1 B8SZ
to signal six 0-bits.

> especially in documentation and examples to reduce readers' confusion.

that'll certainly work.  however, in the ENUM case, where you're building a
tree from scratch, there really are not naturally occuring names to worry
about conflicting with.  if your SRV library insists on putting _'s in front
of things, that may be the determining factor (assuming that you're planning
to leverage existing SRV fetching logic in your deployment plan.)  otherwise
you could just put SRV RR's wherever you want them, in an otherwise known to
be non-preexisting tree, like ENUM's.

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Dec 2002 10:14:06 -0800

> naturally an error condition.  think of _ as the BPV used in DS1 B8SZ

o it would be nice to have a clue to whom you are replying

o as far as the protocol is concerned, names begining with _ are no
  more 'un-natural' than names begining with any other octet

o this is how we create increasing kink

randy

---

From: Peter Koch <[email-masked]>
Date: Sun, 08 Dec 2002 19:38:56 +0100

>   more 'un-natural' than names begining with any other octet

that's why I said "unfortunately" when referring to the "_" requirement
in RFC 2782. While I understood and support the motivation for the "_"
escape, the particular way the RR type is specified there is a bit misleading.
RR types should be defined for owner names in general, not for specific
labels or set of labels. This does, however, not mean, that certain applications
(as in: usage scenarios) for an RR type could not restrict its usage.
<scnr>And now welcome to our regular hostname vs domainname debate</scnr>

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 Dec 2002 09:56:13 -0500

At 17:39 +0000 12/8/02, Paul Vixie wrote:
>  Someone else wrote:
>yes.  however, it's amendable.

RFC 2782 is still at "just" proposed standard...awaiting 
implementation experience and interoperability before progressing to 
draft standard.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Michael Mealling <[email-masked]>
Date: 09 Dec 2002 10:51:18 -0500

> However, there's no option to change that now.

That example in 5.1 is an unfortunate once since there is no need for
the 'udp' portion of the domain-name to be there. The point (as Paul
says in another message) is that in the case of 3403 and 3404 one
already knows the protocol and transport before the SRV query is done.
The usage of SRV in this case is not to discovery a service but to
merely find where (host, port) a previously discovered service can be
found.

> letter, your usage would not be covered by the SRV spec. Then, this does

Right, and the text that discussed other usages of SRV was lost during
the final edit rounds on the document.

> end up with two parallel sub-namespaces for the same purpose (_udp and udp).

If I have an SRV aware rcds client there should be a seperate record for
'arbitrary' rcds clients to contact that server. I.e. an RCDS server
located via the method laid out in RFC 3404 is logically different than
an RCDS server that can be contacted arbitrarily. Vastly different trust
models as the one in 3404 is considered to be authoritative. Thus,
anyone setting up an RCDS server could (and maybe should in lots of
cases) have both records in there, pointing to possibly two different
servers.

> especially in documentation and examples to reduce readers' confusion.

But I think it is causing confusion. By putting the '_' in RFC 3404
based usages you are suggesting to the reader that the SRV usage is of
the general case (i.e. you can and should contact this server for
general RCDS usage when you actually shouldn't). IMHO, the solution
should be for RFC 3404 to specify that it should NEVER allow underscores
in SRV records so that it is explicitly _not_ confused with the full
2782 usage.

-MM