The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, February 17, 2015

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

Hacker News comment about DNS

The argument being presented is that DNS SRV resource records should be used more often than they are (I agree), but that to use them for HTTP 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, and if that failed, a followup A RR lookup for the IP address (or worse, an AAAA RR lookup for an IPv6 address and then fallback to an A RR lookup). But that's only the case because of a stupid limitation on a particular implementation 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 and was testing them out. The specification, RFC- 1035, describes the format for a DNS packet:

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"

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 18th, 2015

It might not take multiple requests, even on that DNS server …

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.