Avertissement: Aucune infraction, mais c'est une très mauvaise idée. Je ne recommande à personne de faire cela dans la vraie vie.
Mais si vous donnez un laboratoire à un informaticien ennuyé, des choses drôles se produiront!
Pour cette expérience, j'ai utilisé un serveur DNS Microsoft fonctionnant sur Server 2012 R2. En raison des complications liées à l'hébergement d'une zone DNS dans Active Directory, j'ai créé une nouvelle zone principale nommée testing.com qui n'est pas intégrée à AD.
En utilisant ce 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
}
}
}
J'ai procédé à la création, sans erreur, 65025 enregistrements d'hôte pour le nom testing.testing.com., avec littéralement chaque adresse IPv4 de 1.1.1.1 à 1.1.255.255.
Ensuite, je voulais m'assurer que je pouvais percer 65536 (2 ^ 16 bits) nombre total d'enregistrements A sans erreur, et je le pouvais, donc je suppose que j'aurais probablement pu aller jusqu'au 16581375 (1.1.1.1 à 1.255 .255.255,) mais je ne voulais pas rester ici et regarder ce script s'exécuter toute la nuit.
Je pense donc qu'il est prudent de dire qu'il n'y a pas de limite pratique au nombre d'enregistrements A que vous pouvez ajouter à une zone pour le même nom avec des adresses IP différentes sur votre serveur.
Mais cela fonctionnera- t-il réellement du point de vue du client?
Voici ce que j'obtiens de mon client vu par Wireshark:
(Ouvrez l'image dans un nouvel onglet de navigateur pour la taille réelle.)
Comme vous pouvez le voir, lorsque j'utilise nslookup ou ping depuis mon client, il émet automatiquement deux requêtes - une UDP et une TCP. Comme vous le savez déjà, le maximum que je puisse entasser dans un datagramme UDP est de 512 octets, donc une fois que cette limite est dépassée (comme 20-30 adresses IP), il faut utiliser TCP à la place. Mais même avec TCP, je ne reçois qu'un très petit sous-ensemble d'enregistrements A pour testing.testing.com. 1000 enregistrements ont été renvoyés par requête TCP. La liste des enregistrements A tourne correctement de 1 à chaque requête successive, exactement comme vous vous attendez à ce que le DNS à tour de rôle fonctionne. Il faudrait des millions de requêtes pour effectuer un round robin à travers tout cela.
Je ne vois pas comment cela va vous aider à rendre votre réseau de médias sociaux massivement évolutif et résilient, mais il y a quand même votre réponse.
Edit: Dans votre commentaire de suivi, vous demandez pourquoi je pense que c'est généralement une mauvaise idée.
Disons que je suis un internaute moyen et que je souhaite me connecter à votre service. Je tape www.bozho.biz dans mon navigateur Web. Le client DNS sur mon ordinateur récupère 1000 enregistrements. Eh bien, pas de chance, les 30 premiers enregistrements de la liste ne répondent pas parce que la liste des enregistrements A n'est pas tenue à jour, ou peut-être qu'il y a une panne à grande échelle affectant une partie d'Internet. Supposons que mon navigateur Web ait un délai d'expiration de 5 secondes par IP avant de continuer et d'essayer le suivant. Alors maintenant, je suis assis ici à regarder un sablier en rotation pendant 2 minutes et demie en attendant que votre site se charge. Personne n'a le temps pour ça. Et je suppose simplement que mon navigateur Web ou toute autre application que j'utilise pour accéder à votre service va même tenter plus que les 4 ou 5 premières adresses IP. Ce ne sera probablement pas le cas.
Si vous avez utilisé le nettoyage automatique et autorisez les mises à jour non validées ou anonymes de la zone DNS dans l'espoir de garder la liste des enregistrements A fraîche ... imaginez à quel point ce ne serait pas sûr! Même si vous avez conçu un système où les clients avaient besoin d'un certificat TLS client qu'ils ont obtenu de vous afin de mettre à jour la zone, un client compromis n'importe où sur la planète va démarrer un botnet et détruire votre service. Le DNS traditionnel est précaire de manière précaire, sans le faire appel à la foule.
Utilisation et gaspillage énormes de bande passante. Si chaque requête DNS nécessite 32 kilo-octets ou plus de bande passante, cela ne va pas du tout évoluer correctement.
Le round robin DNS ne remplace pas un équilibrage de charge approprié. Il ne fournit aucun moyen de récupérer d'un nœud en panne ou devenant indisponible au milieu des choses. Allez-vous demander à vos utilisateurs de faire un ipconfig / flushdns si le nœud auquel ils étaient connectés tombe en panne? Ces types de problèmes ont déjà été résolus par des choses comme GSLB et Anycast.
Etc.