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?
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 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.
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.
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.
(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.
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.
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.
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).
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.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf