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

[Joe Touch <[e-mail]>]

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