Disclaimer: No offense, mais this is a really bad idea. I do pas recommend that anyone do this in real life.
But si you give a bored IT guy a lab, funny things will happen!
For this experiment, J'ai utilisé a Microsoft DNS server running on Server 2012 R2. Because of le complications of hosting a DNS zone in Active Directory, I created a nouveau 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, sans error, 65025 host records for le name testing.testing.com., avec literally chaque IPv4 address depuis 1.1.1.1 to 1.1.255.255.
Then, I wanted to assurez-vous que I could break through 65536 (216 bit) total number of A records sans error, et I could, so I assume I probably could have gone tous le way to 16581375 (1.1.1.1 to 1.255.255.255,) mais Je n'ai pas want to sit here et watch this script run tous night.
So Je pense c'est safe to say that il y a no practical limit to le number of A records you can add to a zone for le même name avec différent IPs on votre server.
But will it actually work depuis a client's perspective?
Here is what I get depuis mon client as viewed by Wireshark:
(Ouvrez le image in a nouveau browser tab for full size.)
As you can see, quand I use nslookup ou ping depuis mon client, it automatically issues two queries - one UDP et one TCP. As you déjà know, le le plus 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 avec TCP, I seulement get a très 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 avec chaque successive query, exactly like how you would expect round-robin DNS to work. It would take millions of queries to round robin through tous of these.
Je ne see how this is going to help you make votre massively scalable, resilient social media network, mais il y a votre answer nevertheless.
Modification : In votre follow-up comment, you ask why Je pense this is generally a bad idea.
-
Let's say Je suis an average internet user, et I would like to connect to votre service. I type www.bozho.biz into mon web browser. The DNS client on mon computer gets back 1000 records. Well, bad luck, le premier 30 records in le list are non-responsive parce que le list of A records n'est pas kept up to date, ou maybe il y a a large-scale outage affecting a chunk of le internet. Let's say mon web browser has a time-out of 5 seconds per IP avant it moves on et tries le suivant one. So now Je suis sitting here staring at a spinning hourglass for 2 et a half minutes waiting for votre site to load. Ain't nobody got time for that. And Je suis juste assuming that mon web browser ou whatever application I use to access votre service is even going to attempt more than le premier 4 ou 5 IP addresses. It probably won't.
-
If you used automatic scavenging et allow non-validated ou anonymous updates to le DNS zone in le hopes of keeping le list of A records fresh... juste imagine how insecure that would be! Even si you engineered certains system où le clients needed a client TLS certificate that they got depuis you beforehand in order to mettez à jour le zone, one compromised client anywhere on le planet is going to start a botnet et destroy votre service. Traditional DNS is precariously insecure as it is, sans crowd-sourcing it.
-
Humongous bandwidth usage et waste. If chaque DNS query requires 32 kilobytes ou more of bandwidth, c'est pas going to scale well at all.
-
DNS round-robin is no substitute for proper load balancing. It provides no way to recover depuis one node going down ou becoming unavailable in le middle of things. Are you going to instruct votre users to do an ipconfig/flushdns si le node they were connected to goes down? These sorts of issues have déjà been solved by things like GSLB et Anycast.
-
Etc.