On 9/12/2011 2:39 PM, Keith Moore wrote:
On Sep 12, 2011, at 4:57 PM, Joe Touch wrote:
Most RRs tie some set of data to a domain name which is historically
a host name, though in recent years it's become a somewhat more
nebulous concept (e.g. "a collection of services", or in the case of
MX records "a collection of recipient mailboxes"). SRV is odd in that
it overloads the domain to include "service name" and transport
protocol.
Yes - it was defined that way.
It was defined poorly, based on assumptions that were already
disconnected from reality and have become even moreso over time.
It would be useful to have a richer way to describe services, which
could include:
- late-binding of transport (or even network)
- layering of protocols
e.g., CMD-over-SOAP-over-HTML-over-SSL
- out-of-band service bootstrap info
- richer descriptions of service variants
that support richer searches than DNS supports
Any of these requires an overhaul to the IANA notion of services and
port numbers, as well as SRV records.
It's not clear to me that this would actually be useful, or to put it
another way, that defining such a service description mechanism would
solve more problems than it creates. Yes there are corner cases where
something like this would be nice. But do we really need a generic
mechanism that /encourages/ so much agility? Do we want the additional
complexity and degraded reliability that would inevitably go along with it?
Again I'm confused.
You claim there's a clear need to revise SRV syntax, but not the
registry that basically defines that syntax?
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*.
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.
SRV appears to have been designed with the idea that the DNS was a
good place to advertise port numbers of services, and that it would
make sense to have a standard mechanism to advertise alternate port
numbers that would work across all applications. For a wide variety
of reasons, this is not a good idea. But because SRV already exists
and is deployed, and we occasionally find applications that need
something similar to SRV, people keep trying to use it in ways that
are contrary to its design.
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. The worldwide system for doing otherwise is SRV records.
Either one works fine, and either one assumes that both sides make the
same assumption.
SMTP is not unique in this sense.
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.
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.
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.
Yes, it'd be nice to late-bind that without an SRV lookup. I wrote a TCP
option about that a while back (port names), and there are other similar
mechanisms that don't use the DNS (TCPMUX).
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).
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).
Any level of indirection can be abused. But so can any kind of hardwired
configuration.
(Disclaimer: I do use /etc/services as documentation. e.g. when I want
to know which port a particular protocol uses, it's easier to grep
/etc/services than it is to look up the port number in the IANA
registry. I just don't use getservbyname whenever I can help doing so.)
Or would your arguments against SRV use also apply to the DNS? :-)
In general, there's an unfortunate potential for DNS to get out of sync
with reality. DNS as it was originally designed made more sense when all
hosts were large boxes that required a significant portion of a room and
dedicated air conditioning and power, and thus were mostly immobile.
It's not such a good fit for PCs and even less applicable to mobile hosts.
My preferred way to use DNS for mobile hosts is to have each host be its
own authoritative DNS/LLMNR server, with its domains explicitly
delegated to it by its parent zones, and replicated from there to
secondary servers with stable IP addresses. That way, the master copy is
always in sync with reality, DNS and LLMNR are always in sync, and the
replica copies of the zone are always in sync with the master copy
whenever the host has network access and the replica servers are reachable.
No disagreement from me, as per my response to the E2E issue above.
If DNS were generally implemented that way, using SRV as originally
intended would make a bit more sense, because it would take the DNS
administrator out of the loop and increase the potential for the DNS and
the host to be in sync with one another about which services were
running on which ports. But it would still increase the potential for
NATs to cause even more trouble than they do now. NATs are something
that need to be phased out as IPv6 is phased in, not something that need
more support and encouragement from the architecture.
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).
If DNS were easier to extend - in particular if RR types weren't
limited to small integers but rather something like OIDs, and if the
format of RDATA weren't hard-coded into DNS servers - I'd absolutely
agree that the thing to do would be to deprecate SRV for new
applications and define new RR types whenever needed.
OK. So basically you claim that new RR types are bad because they are
defined in a way that doesn't do what you want.
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.
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?
Again, I remain confused as to your position.
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).
Joe
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf