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.
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 document for
reasons that seem to me to be pedantic.
Port numbers are inherently meaningful only between pairs of
consenting endpoints.
Mumble. I'd argue that in the case of SMTP at least that port 25 is much
more significant than that. Sure, any given SMTP session could
potentially occur over a different port as long as client and server had
some mechanism for agreeing to use it. But the worldwide basis for
exchange of email is that MX servers for a domain listen on port 25, and
clients know to use port 25 to contact them.
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.
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 reasons already
cited. And SMTP is somewhat unique in that it doesn't make sense to think of
it entirely in terms of pairwise connections.
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.
The ability to indicate the local map of service:port seems entirely
appropriate in an E2E sense.
Actually it breaks the E2E model, by introducing the potential for a
third party (in the form of a NAT + DNS server) that expects to be able
to mediate between client and server.
That "third party" could be at the same endpoint as the destination; in that
case you'd be using that endpoint's DNS to bootstrap other services. Moving
that capability to a separate location does compromise E2E, but the ability
to remap ports has nothing to do with it per se.
In abstract theory, perhaps. But in practice, you and I both know that there
continues to be considerable pressure to impose additional layers of NAT and
prolong use of IPv4.
Endpoints already can (and do) assume services on ports other than their IANA
defaults, e.g. The point is that this is an endpoint decision, under control
of the endpoints.
In many cases it's purely an endpoint decision. Not all of them.
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. I also think that IANA
service names as currently defined are not a reasonable constraint to impose.
But in general I'd like to find a way to escape the 2^16 limitation on port
numbers, and I think that that area deserves further study.
Consider that the DNS distributed /etc/hosts, and basically SRVs
distribute /etc/services
/etc/services is itself a dubious idea. When a protocol specification
defines a constant port to be used (even if just as a default), and
/etc/services purports to override that, that extra layer of indirection
harms interoperability. I remember a time when the MTA for my mail
domain dropped a significant amount of mail on the floor because
getservbyname("smtp", "tcp") failed (it was implemented in terms of
NIS). I immediately changed the code to replace that line with
htons(25), and it never failed again. Since then, I never use
getservbyname when implementing protocol engines, because it's simply
wrong to do so.
We had this discussion recently elsewhere. You may not want that level of
indirection when it doesn't do what you want, but others need that for other
reasons (e.g., to push DNS through a firewall that hijacks it otherwise).
Sigh. It needs to be understood that the existence of brain-damage in the
network is not an inherent justification for adding more complexity. There's
a tussle between users and network administrators that exists because network
administrators don't have good tools to do what they need to do, and also
because they've developed mindshare around using poor tools and using them
poorly. But adding another level of indirection only makes this problem worse
in the long run.
Right, but SRV records don't work with NATs anyway, unless they aren't
indicating a new port (which is their intended use). The portnames solution
would be NAT-friendly (if the NAT parsed the option).
The NAT would just intercept port 43 traffic and translate the SRV record.
Then we'd have NAT polluting the DNS as much as it's polluting IP.
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 DNS would
reliably let you get both RR types in a single query, that would be fine, but
it doesn't.
But then you want to change SRVs - for the same reason you don't want
a new RR type.
I want to relax the requirements for domain names associated with SRV
records. But the only reason I think that's okay is because I assume
that existing DNS servers and client code doesn't enforce the syntax
restrictions on domains associated with SRV records. (given various
difficulties with rigidly enforcing such syntax, I think it's unlikely
that existing code does that, though perhaps I'm wrong about that).
Do you really want to take that risk, rather than using TXT records which
cannot be syntax-enforced anyway?
Personally I think it's a reasonable risk. But I don't think that mine (or
yours) is the only opinion that should be taken into consideration.
My claim is that:
SRVs represent services as they are currently assigned by IANA
a new RR could be useful for things that aren't sufficiently
expressible in the IANA service/port registry
Agree with that much. But "services as they're currently assigned by
IANA" and that are reasonable to use with SRV are few, and a new RR is
difficult to and time-consuming to deploy. This is a case where I think
pragmatic reuse of SRV makes more sense than a purist approach.
Why then doesn't the pragmatic view include using TXT records the way other
SRV users do?
I'm not being dogmatic at all here; I'm just applying the same kind of
pragmatism to the most widely-deployed solution I'm aware (SRV + TXT).
I just think it's a mess to do things that way. And I see dubious benefit in
propagating that mess. IMO.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf