Subject: Re: SRV RR Questions

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

> 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 '_'.

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.

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

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.

--
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: 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: 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

On Sun, 2002-12-08 at 11:37, Peter Koch wrote:
> Michael Mealling wrote:
> 
> > 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?
> 
> 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.

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.

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

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