* * * * *

          It's a limitation in implementation, not in specification

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

Update at 9:09 PM, Wednesday, February 18^th, 2015

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/
[4] gopher://gopher.conman.org/0Phlog:2010/12/06.1
[5] https://www.ietf.org/rfc/rfc1035.txt
[6] https://www.ietf.org/rfc/rfc1035.txt
[7] gopher://gopher.conman.org/0Phlog:2015/02/18.2

Email author at [email protected]

You are viewing proxied material from gopher.conman.org. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.