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.
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.
> 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.
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.