[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRV RR Questions
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.
> 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.
Right, and the text that discussed other usages of SRV was lost during
the final edit rounds on the document.
> 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).
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.
> So, for the sake of consistency, I'd think the '_' should always be used,
> 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
--
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/>