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