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)
2) service lookups already depend on the semantic structure of
IANA service names, which is already only [name, transport]
Adding further structure to these entities requires both a change to the
standard and a change to the registry.
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.
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.
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.
(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.
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf