What's the maximum number of IPs a DNS A record can have?

I have a strange idea - let multiple people/organizations host the same application, and let all their nodes be accessible via a single domain name. That's in order to have, let's say, a really distributed social network, where usability is not sacrificed (i.e. users don't have to remember different provider urls and then when one provider goes down, switch to another one)

To achieve that, I thought a DNS record with multiple IPs can be used.

So, how many IPs can a single DNS A record hold? This answer says it's around 30, but the usecase there is different. For the above scenario I wouldn't care if a given ISP caches only 30, as long as another ISP caches another 30, and so on.

Disclaimer: No offense, but this is a really bad idea. I do not recommend that anyone do this in real life.

But if you give a bored IT guy a lab, funny things will happen!

For this experiment, I used a Microsoft DNS server running on Server 2012 R2. Because of the complications of hosting a DNS zone in Active Directory, I created a new primary zone named testing.com that is not AD-integrated.

Using this script:

$Count = 1
for ($x = 1; $x -lt 256; $x++)
{
    for ($y = 1; $y -lt 256; $y++)
    {
        for ($z = 1; $z -lt 256; $z++)
        {
            Write-Host "1.$x.$y.$z`t( $Count )"
            $Count++
            dnscmd . /RecordAdd testing.com testing A 1.$x.$y.$z
        }
    }
}

I proceeded to create, without error, 65025 host records for the name testing.testing.com., with literally every IPv4 address from 1.1.1.1 to 1.1.255.255.

Then, I wanted to make sure that I could break through 65536 (2^16 bit) total number of A records without error, and I could, so I assume I probably could have gone all the way to 16581375 (1.1.1.1 to 1.255.255.255,) but I didn't want to sit here and watch this script run all night.

So I think it's safe to say that there's no practical limit to the number of A records you can add to a zone for the same name with different IPs on your server.

But will it actually work from a client's perspective?

Here is what I get from my client as viewed by Wireshark:

(Open the image in a new browser tab for full size.)

As you can see, when I use nslookup or ping from my client, it automatically issues two queries - one UDP and one TCP. As you already know, the most I can cram into a UDP datagram is 512 bytes, so once that limit is exceeded (like 20-30 IP addresses,) one must use TCP instead. But even with TCP, I only get a very small subset of A records for testing.testing.com. 1000 records were returned per TCP query. The list of A records rotates by 1 properly with each successive query, exactly like how you would expect round-robin DNS to work. It would take millions of queries to round robin through all of these.

I don't see how this is going to help you make your massively scalable, resilient social media network, but there's your answer nevertheless.

Edit: In your follow-up comment, you ask why I think this is generally a bad idea.

• Let's say I am an average internet user, and I would like to connect to your service. I type www.bozho.biz into my web browser. The DNS client on my computer gets back 1000 records. Well, bad luck, the first 30 records in the list are non-responsive because the list of A records isn't kept up to date, or maybe there's a large-scale outage affecting a chunk of the internet. Let's say my web browser has a time-out of 5 seconds per IP before it moves on and tries the next one. So now I am sitting here staring at a spinning hourglass for 2 and a half minutes waiting for your site to load. Ain't nobody got time for that. And I'm just assuming that my web browser or whatever application I use to access your service is even going to attempt more than the first 4 or 5 IP addresses. It probably won't.

• If you used automatic scavenging and allow non-validated or anonymous updates to the DNS zone in the hopes of keeping the list of A records fresh... just imagine how insecure that would be! Even if you engineered some system where the clients needed a client TLS certificate that they got from you beforehand in order to update the zone, one compromised client anywhere on the planet is going to start a botnet and destroy your service. Traditional DNS is precariously insecure as it is, without crowd-sourcing it.

• Humongous bandwidth usage and waste. If every DNS query requires 32 kilobytes or more of bandwidth, that's not going to scale well at all.

• DNS round-robin is no substitute for proper load balancing. It provides no way to recover from one node going down or becoming unavailable in the middle of things. Are you going to instruct your users to do an ipconfig/flushdns if the node they were connected to goes down? These sorts of issues have already been solved by things like GSLB and Anycast.

• Etc.

To answer the question as it was stated ("how many IPs can a single DNS A record hold?") the answer is very simple: a single A record holds exactly one address. There can however be multiple A records for the same name.

Each IPv4 address will take up 16 bytes in the reply. Each IPv6 address will take up 28 bytes in the reply.

It is strongly recommended that you ensure the reply will fit in 512 bytes. That would allow for about 25 IPv4 addresses and 14 IPv6 addresses (considering that you need some other information in the packet as well). The exact limit depends on the length of your domain name.

If you have both 25 IPv4 addresses and 14 IPv6 addresses, then you are counting on the clients requesting IPv4 and IPv6 addresses in separate queries. Should the client ask for both types of addresses in a single query (which is rare), then you would have to go lower.

Should the reply size exceed 512 bytes, it may still work over UDP if client and server supports EDNS. Without EDNS, the client would receive a truncated reply, and it would have to retry over TCP. This increases the communication from 1 to 4 roundtrips. But even worse, sometimes there are misconfigurations preventing DNS over TCP from working.

Even if you could squeeze more than 14 addresses into the reply without causing problems at the DNS layer, it is unlikely to be very useful. The timeout used by the client before giving up on one address and proceeding to the next is often significant.

Having to wait for that timeout even once can lead to poor user experience. If the client had to go through 14 addresses before getting a response, the user would have to wait for 13 timeouts.