Re: TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf