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