(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 (Service) records are no slower than A records, which, on it's face, seems reasonable. A DNS (Domain Name Service) request is a DNS request, and aside from a response being too big for UDP (User Datagram Protocol) and having to switch to TCP (Transmission Control Protocol), 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 (Internet Protocol) 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.
“Hacker News comment about DNS [1]”
The argument being presented is that DNS SRV (Service) [2] resource records should be used more often than they are (I agree), but that to use them for HTTP (HyperText Transport Protocol) during a transitional period would lead to a slower web browsing experience as two (or more) DNS lookups would be required— one for the SRV RR (Resource Record), and if that failed, a followup A RR lookup for the IP address (or worse, an AAAA RR lookup for an IPv6 (Internet Protocol, Version 6) address and then fallback to an A RR lookup). But that's only the case because of a stupid limitation on a particular implementation [3] of DNS that happens to hold, oh, 80% of the DNS traffic on the web (and 97% of all statistics are made up on the spot).
I only noticed this when I wrote my own DNS parsing routines [4] and was testing them out. The specification, RFC- 1035 [5], describes the format for a DNS packet:
Table: DNS Packet Layout Header Question what RRs are we interested in Answer RRs that match our question Authority RRs pointing toward an authority Addtional RRs holding additional information
And the “Header” section contains four 16 bit fields, described as such:
>
```
QDCOUNT an unsigned 16 bit integer specifying the number of
entries in the question section.
ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
```
“RFC-1035: Domain Implementation and Specification" [6]”
Take special note of the QDCOUNT field—“number of entries in the question section.”
Nowhere in RFC-1035 states that “QDCOUNT shall be one, and one shall be the only number in QDCOUNT, which shall be one, and nothing more shall appear therein. Amen.” Nowhere.
So, in theory, a program can ask for the following RRs in a single DNS packet: SRV, AAAA and A. But sadly, in theory, there is no difference between theory and practice, but in practice … sigh. You need three separate queries because the most popular DNS server in use decided to support only a single question.
It might not take multiple requests [7], even on that DNS server …
[1] https://news.ycombinator.com/item?id=8851151
[2] http://en.wikipedia.org/wiki/SRV_record
[3] https://www.isc.org/downloads/bind/
[5] https://www.ietf.org/rfc/rfc1035.txt