On Sep 12, 2011, at 10:57 AM, Joe Touch wrote:
On 9/11/2011 11:32 PM, Keith Moore wrote:
On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have described. Additional info is
passed in TXT records for current DNS SRVs.
I.e. what I have proposed is what is both current spec and current
widespread practice.
Before proposing a change (which would need to happen before we would use
it in a new spec anyway), is there something the current syntax (and use
of TXTs for additional info) cannot do that you want?
Why use SRV records at all if you also need TXT records to convey part of
the information needed by apps (and thus, have to do multiple queries for
the same level of information)? Why not just encode all of the
information in TXT records?
The SRV records provide a standard way of mapping a service (as per the
IANA ports and service names registry) on a specific transport to a
hostname and port number.
The TXT records are linked to the SRV records, and provide additional
bootstrap info that the service does not provide in-band.
You did not answer the question.
I had assumed familiarity with how SRV and TXT records are used together.
See: draft-cheshire-dnsext-dns-sd
The SRV record has the semantic structure that allows the DNS query to be
processed, e.g., weight, port number, target, etc.
The TXT record of the same name gives the additional information needed for
service bootstrap.
If you're looking for a more generic database query system, you might
consider using LDAP rather than the DNS.
I'm not looking for anything in particular. I just don't see any
justification for insisting that SRV records always be used with RFC
2782 style labels.
I have provided two:
1) that's the current standard (i.e., changing it requires
an update to RFC 2782, which this draft does not request)
Yes, but arguably 2782 is a poor fit for this application, and for many other
applications also.
2) service lookups already depend on the semantic structure of
IANA service names, which is already only [name, transport]
There's nothing about the definition of the SRV RR that inherently constrains
the label that such RRs are associated with.
Adding further structure to these entities requires both a change to the
standard and a change to the registry.
Well, you can't really change the structure of SRV RRs, as they're already in
use for some things and in widely deployed code. But there's no reason why an
app couldn't specify a new use of SRV RRs with different labels than specified
by 2782. As long as there were no potential for collisions between 2782-style
labels and the labels used by the app, it wouldn't break anything. The fact
that there's already a standard existing for SRV RR labels shouldn't inherently
preclude standardization of a different kind of label associated with SRV.
Nor do I immediately see any justification for using
SRV at all if the application also needs to look up TXT records to get
the service's profile.
SRV records specify the structure that yields the port number, target,
weight, etc.
Sure, you could define TXT record fields for anything you wanted -
effectively redefining the DNS inside TXT records. However, you would also
need to define an indicator *required in all TXT records* that would tell you
whether to interpret the contents as A, AAAA, CNAME, SRV, etc.
Well, that's the problem with TXT records. Or, to look at it differently, it's
a problem with the design of the DNS protocol in that its way of labeling RR
types is too limited.
But looking at it still a different way, if you pick labels that are unique to
a particular application, there's no need for a type indicator to be embedded
in the TXT record. (Effectively this is moving the type to the label.)
Right now, the DNS indicates these as separate RR types. Stuart's draft
defines TXT's with names matching corresponding SRV records as having
additional info.
Yes, you could just have the TXT record, but you'd then need to define the
SRV info in the TXT record as fields. For at many services, additional fields
beyond the SRV info isn't needed.
In principle, the apps that don't need anything beyond what SRV provides could
still use the SRV RR as it's defined in 2782 (whether or not the same style of
labels are used). It's (partially) the warts-on-warts approach of TXT + SRV
(or NAPTR + SRV, in a different context), that I'm concerned about. I get the
impression that there's a set of people out there who keep insisting that SRV
be used even though it turns out not to be a good fit for many situations.
Like this document.
I've become fairly convinced that SRV is at best not widely applicable, and at
worst fairly harmful. One reason it's not widely applicable is that there
are too many cases where the application needs to know more more than a list of
(address,port) pairs to successfully choose an instance of a service and use
it. (Part of this is because SRV isn't just being used to help an application
connect to a protocol service, but also, to choose an instance of a somewhat
more abstract service which might actually be implemented using multiple
protocols and/or multiple sets of optional features of a protocol).
One reason it's potentially harmful is that the existence of SRV tempts various
parties to think that it's okay to remap ports on the wire and/or to insist
that particular ports be used for particular services. Another reason is that
the use of default ports is subtly different from one application to another,
and trying to define a RR that treats them all as the same is a Bad Idea. Once
upon a time I ran across an implementation of getaddrinfo() that did SRV lookup
by default, and it broke applications that used it in several ways.
The bottom line for this particular draft is:
- SRV is of more limited applicability than originally assumed, therefore
- there's no need to defend the "purity" of SRV as defined by 2782, therefore
- there's no need to insist that all uses of the SRV RR use the labels as
defined in 2782
Of course, one of the problems with using SRV more widely (in
addition to backward compatibility issues) is that in many cases
what's desired is not merely to map a service name (as defined in the
IANA registry and equated with a default port) onto an address and
port, but rather, to provide instructions as to how a service may be
accessed - a service profile, if you will. So I can certainly see why
SRV alone would not do the job. What I don't immediately see is why
it's worth the trouble of using SRV at all for those cases when it
won't do the job.
The point is that there's one place to get the port number and hostname;
additional info - which isn't needed in many cases (see the IANA ports list)
- is added only when needed in these supplemental TXT records.
Warts on warts. Additional query overhead / setup latency, more opportunities
for misconfiguration, more opportunities for the TXT and SRV RRs to be out of
sync with one another. etc.
(LDAP by itself wouldn't solve this problem either - you'd still
need to define a way to represent an application service profile in
LDAP. And if the name of the service is reasonably represented by a
DNS name, then arguably, the profile belongs in DNS. Or at least, a
pointer to the profile belongs in DNS. The last thing we need is to
have LDAP and DNS providing conflicting information about what a DNS
name means.)
If you want a service that takes [service-description, hostname] and returns
a [port, hostname, additional-info] tuple, the DNS is fine.
(note that IANA *defines* service description as [name, transport] - there's
no "read-only" attribute to that query). I.e., this presumes that the client
parses the "additional-info" and determines whether this record is relevant -
NOT that the DNS performs this filter for the client.
If you want more sophisticated DNS filters inside the DNS, I'd argue you
really want LDAP.
More warts on warts. IMO, that's even worse than TXT + SRV, which itself is
worse than just using TXT.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf