Comment by kragen | Hacker News Reader

Comment by kragen | Hacker News Reader

SRV records, used in DNS-SD and notably in Zeroconf, provide you the port numbers dynamically. Assigning port numbers to internet services globally across the entire internet was a mistake, and one that we can avoid for newly defined services. It creates two problems:

1. The one mentioned in this article: the namespace is finite and small, leading to conflicts over the administration of its allocation;

2. virtual hosting — you can only have one instance of a service per IP address, unless you kludge into the higher-layer protocol (every higher-layer protocol) some way of telling the server which instance of the service you were trying to connect to. And even then, all your “virtual hosts” have to be running on the same software — you can’t run some of them on Courier IMAP and others on Dovecot, say. By contrast, if you just bind them to different ports and publish those port numbers in DNS SRV records, these problems go away.

TCPMUX on port 1 was the first attempt to solve this problem, but it didn't catch on. DNS-SD/Zeroconf/Bonjour/Rendezvous/SRV records seem like a viable and highly usable alternative, as long as we don’t get lost in the alphabet soup.

I agree entirely. You'd still have a string namespace, but that string namespace is more easily subdivided.

One key downside, though: for a conversation with any service not in your cache, you need to resolve the service before connecting, rather than knowing in advance. So there's still an advantage to any service that can use a well-known port. That advantage partly goes away if you can resolve a hostname in the same DNS request as a service on that host, but that would require improving the current level of integration between clients and system resolvers.

Really? I didn’t realize there was a client-side problem there. I guess there’s still a security problem, though, if the SRV record points to a hostname that nameserver may not be authoritative for.

Edited to be more specific: I mean, if you want to cut the time to resolve a service name to an IP:port pair from two round-trip times down to one, then you need to get the A or AAAA record from the same nameserver as the SRV record. Getting the nameserver to include that record in the “additional” section, like a glue record for NS delegations, isn’t hard; but if it’s in another gTLD, how does the client know that nameserver is authoritative for that domain? It could be sending you a false A record. You wouldn’t want to cache that; it could enable a MITM attack! Better check with the gTLD servers. But that means another round-trip-time delay.

> Really? I didn’t realize there was a client-side problem there.

You'd need some new API for resolving a given host:service combination in a single request, which to the best of my knowledge does not exist today. With current APIs, you'd make one request to resolve the name and a separate request to resolve the service.

> I guess there’s still a security problem, though, if the SRV record points to a hostname that nameserver may not be authoritative for.

That seems like the same kind of issue that can occur today if you make a hostname you control point to an IP you don't. Both seem like similar problems with similar solutions.

Hostport combinations are in use in many tools. Hadoop represents all it's servers as a hostport.

The proper name is "netloc".

It could be sending you a false A record. You wouldn’t want to cache that; it could enable a MITM attack! Better check with the gTLD servers. But that means another round-trip-time delay.

If the nameserver you're connecting to is doing things like that, this is a problem for all your traffic, not just traffic that relies on SRV records.

This is not necessarily the nameserver local to you; this may be the nameserver that’s authoritative for the SRV record you’re trying to look up. Maybe you’re trying to talk to a machine in North Korea.

Is there any reason browsers couldn’t start supporting this for websites? Seems like it would be significantly simpler than today's Host header-based proxying.

Reply on news.ycombinator.com