Avertissement : Sans vouloir vous offenser, 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 qui s’ennuie, des choses amusantes se produiront !
Pour cette expérience, j’ai utilisé un serveur DNS Microsoft fonctionnant sous Server 2012 R2. En raison des complications de l’hébergement d’une zone DNS dans Active Directory, j’ai créé une nouvelle zone primaire 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 créé, 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 dépasser 65536 (2^16 bits) enregistrements A au total sans erreur, et j’ai pu, donc je suppose que j’aurais probablement pu aller jusqu’à 16581375 (1.1.1.1 à 1.255.255.255), mais je ne voulais pas rester assis ici à regarder ce script tourner toute la nuit.
Je pense donc qu’il est sûr 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 IP différentes sur votre serveur.
Mais est-ce que cela fonctionne réellement du point de vue d’un client ?
Voici ce que j’obtiens depuis mon client, vu par Wireshark :
(Ouvrez l’image dans un nouvel onglet du navigateur pour la taille complète.)
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 l’on peut faire tenir dans un datagramme UDP est de 512 octets, donc une fois cette limite dépassée (environ 20-30 adresses IP), il faut utiliser TCP à la place. Mais même avec TCP, je n’obtiens qu’un très petit sous-ensemble d’enregistrements A pour testing.testing.com. 1000 enregistrements ont été retournés par requête TCP. La liste des enregistrements A tourne de 1 correctement à chaque requête successive, exactement comme on s’y attendrait avec un DNS en round-robin. Il faudrait des millions de requêtes pour faire le tour complet de tous ces enregistrements.
Je ne vois pas comment cela va vous aider à construire votre réseau social massivement évolutif et résilient, mais voilà votre réponse néanmoins.
Modification : Dans votre commentaire de suivi, vous demandez pourquoi je pense que c’est généralement une mauvaise idée.
Supposons que je suis un utilisateur moyen d’Internet et que je souhaite me connecter à votre service. Je tape www.bozho.biz dans mon navigateur web. Le client DNS de mon ordinateur reçoit 1000 enregistrements en retour. Pas de chance, les 30 premiers enregistrements de la liste ne répondent pas car la liste d’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 passer à la suivante et d’essayer. Donc maintenant je suis assis là à fixer un sablier tournant 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 l’application que j’utilise pour accéder à votre service va même essayer plus que les 4 ou 5 premières adresses IP. Il ne le fera probablement pas.
Si vous utilisiez le nettoyage automatique et autorisiez les mises à jour non validées ou anonymes de la zone DNS dans l’espoir de garder la liste d’enregistrements A à jour… imaginez à quel point ce serait non sécurisé ! Même si vous conceviez un système où les clients avaient besoin d’un certificat TLS client que vous leur aviez fourni au préalable pour mettre à jour la zone, un seul client compromis n’importe où sur la planète va démarrer un botnet et détruire votre service. Le DNS traditionnel est déjà dangereusement non sécurisé tel quel, sans en faire du crowdsourcing.
Utilisation et gaspillage de bande passante énormes. Si chaque requête DNS nécessite 32 kilo-octets ou plus de bande passante, cela ne va pas bien passer à l’échelle du tout.
Le DNS round-robin ne remplace pas un véritable équilibrage de charge. Il ne fournit aucun moyen de récupérer si un nœud tombe en panne ou devient indisponible au milieu d’une opération. Allez-vous demander à vos utilisateurs de faire un ipconfig/flushdns si le nœud auquel ils étaient connectés tombe en panne ? Ces problèmes ont déjà été résolus par des technologies comme le GSLB et l’Anycast.
Etc.