On 9/12/2011 3:49 PM, Keith Moore wrote:
On Sep 12, 2011, at 6:23 PM, Joe Touch wrote:
Again I'm confused.
You claim there's a clear need to revise SRV syntax, but not the registry that basically defines that syntax?
I don't claim that there's a clear need to revise the syntax of the RDATA. I claim that the syntax defined in RFC 2782 for the domains used with SRV RRs is relevant only when SRV is used as anticipated in RFC 2782... which is to say, almost never.
If you don't need a generic mechanism with agility, just use TXT records and move on IMO. That's what most other SRV users *have already done*.
Given that I think service location is almost inherently
application-specific anyway, that solution is also fine with me. I don't
know what value is added by SRV, other than confusion.
SRV indicates the port number (useful if not the default) and weight, etc.
If that's not what you want, just use the corresponding TXT record, but
include a field that indicates whether this is the correct record (e.g.,
domain-root).
If you insist on a clean, generic, system that solves this problem
for nfsv4 domain-root and other similar cases, you're clearly arguing
for the deep slog of fixing this throughout the IETF.
Eventually yes. But I'm also arguing against holding up this
documentfor reasons that seem to me to be pedantic.
All protocol specs are pedantic.
The way to avoid holding this doc up, IMO, is to use SRV records as
they're currently used - with TXT records where additional info is needed.
...
The worldwide default for services with assigned ports is to assume that port number.
yes.
The worldwide system for doing otherwise is SRV records.
no.
I'll let Apple know.
Either one works fine, and either one assumes that both sides make the same assumption.
SMTP is not unique in this sense.
False. SRV records are poorly designed and broken for several
reasonsalready cited. And SMTP is somewhat unique in that it doesn't
make sense to think of it entirely in terms of pairwise connections.
What exactly isn't pairwise about mail relay?
The only port that is difficult to change is the DNS. You need to *know* that for the host on which the DNS resides for the endpoints you want to contact before contacting them.
Using DNS to look up the port number opens Pandora's box and creates a great many opportunities for failure as well as encouraging pollution of the architecture.
Good. Then stop using SRV records. That's what they're for, in case it
was at all vague in RFC 2782.
(NAT discussion omitted - NATs break SRV use anyway)
Further, it avoids the burden of pre-allocating port numbers (a quite
constrained resource) for services that might never be used at a given
endpoint, and allows that map to be assigned dynamically and locally.
Yes, it does that, and I agree that pre-allocated port numbers are
precious. Though I think this particular mechanism causes more problems
than it solves.
I don't disagree; I would prefer port-names (for those not familiar, the idea was to use the IANA service names as a TCP option in the SYN packet, and to demux to the service based on that name string rather than the incoming port).
I identified several issues with port-names at the time you made
that
proposal. One of the bigger problems IIRC was that they assumed that
there could only be one service with a particular name on a particular
host, when these days "virtual hosts" (by which I mean multiple services
acting on behalf of different domains all supported by the same physical
host) are quite common, and the notion of "host" has become fairly
blurry.
Talk about breaking E2E. You are confusing a port with an endpoint ID.
...
...
New RR types are what they are. Some are inevitably defined better than
others. For the specific case of SRV, I don't think the RR was well
defined. But DNS is not as extensible as we'd like, new RR types are
scarce and difficult to deploy, and so there's some weight to the idea
that we should make do with what we have whenever it doesn't break anything.
RIGHT!!!!!
Which is why using TXT records with SRVs - which is what most other SRV users do when they need OOB info - is the right way to go.
Nah, if you're going to use TXT records, don't bother with SRVs. Avoid the extra lookup and the resulting hit in latency and reliability.
If you already know the port number, there's nothing that prevents you
from doing this, FWIW.
> If DNS would reliably let you get both RR types in a single query,
that would be fine, but it doesn't.
So go fix *that*. ;-)
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf