Re: SRV RR Questions

[Paul Vixie <paul@vix.com>]

> 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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>