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.
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.
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.
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.
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.
It's totally ridiculous that with 100 Mbps 'down' and 20 Mbps 'up' you still need a hosting account for a small web server.
For example on a rather high-end netgear home router I can apply QoS by port, but that means Crashplan, Web and Skype use the same port. Even though I'd like them to be low, medium and high priority respectively.
Oh, SRV records, right that's what I was going to post about. Yes, once again, SRV records would have solved this problem in quite an elegant and simple way. And it's backwards compatible until we hit an actual port number crisis... cool!
Until people start to offer tens of thousands of services per IP, we won't hit any port shortage. And in the hypothetical future where that happens we hopefully moved to IPv6 and can just use another IP address.
Most notably: the ability to exist at the apex of a domain, resolving to both IPv4 and IPv6 addresses simultaneously, and weighted-round-robin and fallback support.
The overload of the address record to discover service endpoints is ultimately a murky throwback to when servers were named like pets, not disposable commodities.
Secondly, in this age of containerized deployment it is already common to have many HTTP-substrate services bound to a single address, disambiguated by port. Leveraging the SRV record in DNS means not having to invent yet another endpoint discovery mechanism just to know what port number to connect to.
The reference to "typing an extra 5 characters" invokes a world of manual, static configuration that many of us are happy to have replaced with services that find each other through discovery protocols.
If I want to run an ssh server on port 80 (HTTP) then I can, and it will work just fine, and it won't bother anyone else.