(I'm responding inline, and I'm not looking at all the aforementioned posts/comments, so forgive me if I'm missing something here.)
It sounds like you're arguing that SRV records are no slower than A records, which, on it's face, seems reasonable. A DNS request is a DNS request, and aside from a response being too big for UDP and having to switch to TCP, you should get nearly-identical performance.
The part, to me, that looks like a real performance issue is potentially having to double the minimum amount of queries to serve a website. We couldn't possibly switch directly to SRV records; there would have to be an overlap of browsers using both SRV and A records for backwards compatibility.
If we stick with that invariant, then we can say that the first-load cost of a page not using SRV records doubles in the worst case: websites that only have an A record. Now we're looking for a SRV record, not getting it, and falling back to an A record. So, now, all of the normal websites who don't give a crap about SRV records, won't ever use them, pay a performance penalty. A marginal one, sure. but it's there.,
So, overall, their claim seems valid, even if low in severity.
I'd love to hear from someone that has the data, but I can count on one hand the number of times where a loss of IP connectivity has happened where I wish I had SRV records for load balancing. It's usually bad DNS records, or slow/bad DNS propagation, or web servers behind my load balancers went down, or a ton of other things. Your point is still totally valid about being able to more easily load balance across multiple providers, datacenters, what have you... but I'm not convinced it's as much of a problem as you make it out to be.
If you really are in the position where an additional DNS request will kill you (unlike the overwhelming majority), there is an easy solution: Make sure all the servers pointed to by the SRV records are in the same domain (or at least that the domain is served by the same DNS server). Then the A (and AAAA) records should be present in the “ADDITIONAL” section of the DNS response. No more DNS questions are then necessary to get this data.
> […] or web servers behind my load balancers went down […]
I’m getting the impression that you think that even having a load balancer is a natural state of affairs, but it should not be. Getting more performance should be as easy as spinning up an additional server and editing the DNS data; done. Your attitude reminds me of the Unix-haters handbook, describing people who have grown up with Unix and are irreversibly damaged by it: “They regard the writing of shell scripts as a natural act.” (quoted from memory).
You make a valid point, but that relies on systems asking for all records on an RR. If a DNS server decides to send along A records with a SRV request, it's likely those A records won't be cached[1], and thus you'd have to make a second query.
As far as load balancers, sure, it'd be great if nobody needed to do anything other than spread requests across a pool of heterogeneous machines... but there's plenty more to be had by using a load balancer in front of web servers, namely intelligent routing. Things you just couldn't possibly figure out, as the browser, from looking at SRV records.
Besides that, I appreciate your thorough and clearly-informed thoughts on my attitude and state of mind when it comes to engineering systems. It definitely elevated this discussion to new heights, to be sure.
> You make a valid point, but that relies on systems asking for all records on an RR.
Um, no? If a DNS client asks a DNS server for an SRV record, and the DNS server has the A (and AAAA) records for the domain names contained within that SRV record, the DNS server will send those A (and AAAA) records along in the reply in the “ADDITIONAL” section; i.e. not in the “ANSWER” section as a reply to the actual SRV query, but still contained within the same DNS response. So the tiny performance issue for this minor case can be solved for those who need to solve it.
> […] a load balancer [can also be used for] intelligent routing.
Well, yes, SRV records can’t be all things to all people. This is, however, nothing which will affect, I guess, at least 90% of those even today using load balancers. Those needing this extra functionality can perfectly well keep their load balancers or (to call them for what they actually would be) HTTP routers.
These are, however, both minor quibbles (the first of them even has a solution) and should not affect the decision to specify SRV usage in HTTP/2.
(Also, being overly ironic does not help discourse, either.)
That's making an assumption that they will send back the A/AAAA records. Empirically, you might be right, but it's a recommendation, not a requirement, in RFC2782. (Not sure if there's an RFC that supercedes that particular point.)
So, either you hope the server responds with the A/AAAA records in the additional section, or you have to query for all records on an RR, or further still, do multiple queries. What happens when your SRV records point to CNAMEs? Do most DNS servers that support sending back the A/AAAA records in the ADDITIONAL section also support resolving the CNAMEs before populating the additional section?
There's a few other things, too,, like having to make interesting tradeoffs on TTLs: if you have low enough TTLs to support using DNS as a near-real-time configuration of what web servers to use, what happens when DNS itself breaks? There's some operational pain there, to be sure.
This is all to say: there's clearly a lot of angles to something as simple as using SRV records in lieu of A/AAAA/CNAME records, and we're here, right now, talking about this, all because of the rushed design of HTTP/2.0, which is a protocol unto itself. It's not surprising that a standard that went through so quickly managed to not include something, like SRV records, which have been in a weird state of existence since their inception. To think it would be so simple, so easy, seems incredibly overoptimistic.
If you have this problem, you are in control of what DNS server you use, and can make sure it sends the appropriate records. We are talking about a “problem” which affects very few people, and those it affects have the budget to make sure this is the case.
Also, there is, by now, a lot of operational experience with both MX records and SRV records, and they are well understood. They are not the wild unknown you make them out to be.
It sounds like you're arguing that SRV records are no slower than A records, which, on it's face, seems reasonable. A DNS request is a DNS request, and aside from a response being too big for UDP and having to switch to TCP, you should get nearly-identical performance.
The part, to me, that looks like a real performance issue is potentially having to double the minimum amount of queries to serve a website. We couldn't possibly switch directly to SRV records; there would have to be an overlap of browsers using both SRV and A records for backwards compatibility.
If we stick with that invariant, then we can say that the first-load cost of a page not using SRV records doubles in the worst case: websites that only have an A record. Now we're looking for a SRV record, not getting it, and falling back to an A record. So, now, all of the normal websites who don't give a crap about SRV records, won't ever use them, pay a performance penalty. A marginal one, sure. but it's there.,
So, overall, their claim seems valid, even if low in severity.
I'd love to hear from someone that has the data, but I can count on one hand the number of times where a loss of IP connectivity has happened where I wish I had SRV records for load balancing. It's usually bad DNS records, or slow/bad DNS propagation, or web servers behind my load balancers went down, or a ton of other things. Your point is still totally valid about being able to more easily load balance across multiple providers, datacenters, what have you... but I'm not convinced it's as much of a problem as you make it out to be.