On Sep 12, 2011, at 7:06 PM, Joe Touch wrote:
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.
right. but given that you can include the same things in a TXT record, if you
have to query for TXT RRs anyway, what's the value added by doing an additional
query for SRV RRs?
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.
Perhaps, but their interpretations don't have to be 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.
Your notion of "currently" seems like a stretch. My understanding is that
they're currently used in several different ways, the RFC notwithstanding.
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.
Thanks. :)
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?
Right now, if you want to be able to receive mail reliably, you have to have an
MX which listens on port 25. If you want to send mail across administrative
boundaries, in general, you have to be able to send to port 25. There's no way
to do pairwise port negotiation.
Of course, in some hypothetical other world with a slightly different mail
protocol, the problem could be solved differently.
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.
I'd be very happy to see SRV records deprecated, or at least discouraged, for
new protocols.
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.
You might have an easier time understanding what I'm saying, if you weren't so
busy trying to prove to yourself that I'm confused.
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.
Or if you really need to support arbitrary ports, just encode the port number
in the TXT record.
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*. ;-)
If I were going to fix DNS, that would be only one of several things on my list
of things to fix. But I don't think the Internet is desperate enough to want
to fix DNS yet.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf