Quel est le nombre maximal d'adresses IP qu'un enregistrement DNS A peut avoir?

J'ai une idée étrange - laisser plusieurs personnes / organisations héberger la même application et laisser tous leurs nœuds accessibles via un seul nom de domaine. C'est pour avoir, disons, un réseau social vraiment distribué, où la convivialité n'est pas sacrifiée (c'est-à-dire que les utilisateurs n'ont pas à se souvenir des différentes URL des fournisseurs et puis lorsqu'un fournisseur tombe en panne, basculez sur un autre)

Pour y parvenir, j'ai pensé qu'un enregistrement DNS avec plusieurs IP peut être utilisé.

Alors, combien d'adresses IP un seul enregistrement DNS A peut-il contenir? Cette réponse indique que c'est environ 30, mais le cas d'utilisation est différent. Pour le scénario ci-dessus, je m'en fous si un FAI donné ne met en cache que 30, tant qu'un autre FAI met en cache 30 autres, et ainsi de suite.

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.

Pour répondre à la question posée ("combien d'IP un seul enregistrement DNS A peut-il contenir?"), La réponse est très simple: un seul Aenregistrement contient exactement une adresse. Il peut cependant y avoir plusieurs Aenregistrements pour le même nom.

Chaque adresse IPv4 prendra 16 octets dans la réponse. Chaque adresse IPv6 prendra 28 octets dans la réponse.

Il est fortement recommandé de vous assurer que la réponse tiendra en 512 octets. Cela permettrait environ 25 adresses IPv4 et 14 adresses IPv6 (étant donné que vous avez également besoin d'autres informations dans le paquet). La limite exacte dépend de la longueur de votre nom de domaine.

Si vous avez à la fois 25 adresses IPv4 et 14 adresses IPv6, vous comptez sur les clients demandant des adresses IPv4 et IPv6 dans des requêtes distinctes. Si le client demande les deux types d'adresses dans une seule requête (ce qui est rare), vous devrez alors descendre plus bas.

Si la taille de la réponse dépasse 512 octets, elle peut toujours fonctionner sur UDP si le client et le serveur prennent en charge EDNS. Sans EDNS, le client recevrait une réponse tronquée et devrait réessayer via TCP. Cela augmente la communication de 1 à 4 allers-retours. Mais pire encore, des erreurs de configuration empêchent parfois DNS sur TCP de fonctionner.

Même si vous pouvez insérer plus de 14 adresses dans la réponse sans causer de problèmes au niveau de la couche DNS, il est peu probable que cela soit très utile. Le délai d'attente utilisé par le client avant de renoncer à une adresse et de passer à la suivante est souvent important.

Devoir attendre ce délai une seule fois peut entraîner une mauvaise expérience utilisateur. Si le client devait passer par 14 adresses avant d'obtenir une réponse, l'utilisateur devrait attendre 13 délais d'attente.

Ce que vous décrivez n'est pas une idée particulièrement nouvelle. Comme d'autres réponses ont déjà couvert, vous êtes limité dans le nombre d'enregistrements A que vous pouvez avoir dans une réponse, mais cela ne dit rien sur le nombre d'enregistrements A qu'il pourrait y avoir au total.

Vous pouvez, par exemple, implémenter un serveur DNS qui répond à toute requête pour un enregistrement A avec une IP aléatoire. Interrogé suffisamment de fois, cela entraînerait 4294967296 enregistrements A uniques: un pour chaque adresse IPv4.

Comme je l'ai dit, ce n'est pas une nouvelle idée. En fait, c'est en partie comment Akamai fonctionne (et probablement beaucoup d'autres CDN). L'enregistrement A que vous obtenez pour n'importe quel domaine Akamai est déterminé par leurs serveurs DNS magiques noirs. Je parie que la réponse que vous obtenez dépend de l'équilibrage de charge dynamique et des préoccupations géographiques.

Par exemple, j'ai choisi a338.g.akamaitech.net. Si je regarde cela sur mon ordinateur en ce moment, qui utilise un serveur de noms DHCP attribué par Comcast:

$ host a338.g.akamaitech.net
a338.g.akamaitech.net has address 23.3.98.65
a338.g.akamaitech.net has address 23.3.98.89

Et si je demande le DNS de Google?

$ host a338.g.akamaitech.net 8.8.8.8
Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases: 

a338.g.akamaitech.net has address 23.3.96.152
a338.g.akamaitech.net has address 23.3.96.120

Je parie que si vous l'essayez, je parie que vous obtiendrez une réponse différente. Combien de serveurs périphériques Akamai possède-t-il pour une ressource particulière? Plus de deux, je parie.

D'autres l'ont mentionné comme détail, mais d'un point de vue pratique, la limite stricte est la limite de taille de paquet UDP de 512 octets. Bien qu'il soit possible de passer à TCP lorsque la troncature est détectée, dans la pratique, de nombreux clients / la plupart ne le feront pas (et sans doute ils ne devraient pas; cela donnerait une mauvaise expérience utilisateur pour la plupart des applications, et je ne m'attendrais qu'à des transferts de zone ou autres recherches spéciales pour prendre en charge TCP). Vous envisagez donc une limite d'environ 30 adresses pour IPv4 (enregistrements A) et un peu moins pour IPv6 (AAAA) car elles sont plus grandes. La longueur du nom de domaine y coupe et limitera davantage le nombre.

La réponse courte: environ 25 enregistrements A tiennent dans un paquet UDP. Au-delà de cela, DNS passera à TCP et ce ne sera pas aussi rapide. Vous aurez également des problèmes avec les clients qui n'utilisent pas de résolveurs DNS capables de choisir l'IP "la plus proche". De plus, avec le wifi et le mobile, le "plus proche" ne sera souvent pas le bon serveur.

Réponse plus longue:

Ne fais pas ça. Une meilleure façon serait de configurer des enregistrements CNAME individuels pour chaque utilisateur qui pointent vers le serveur approprié. Disons que vous avez deux serveurs server-fet que vous server-rutilisez pour IMAP. Configurez le client IMAP de chaque personne avec le nom de serveur USERNAME.imap.example.com où "USERNAME" est remplacé par leur nom d'utilisateur de messagerie. Vous pouvez désormais déplacer des personnes entre des serveurs sans avoir à reconfigurer leur client de messagerie.

server-f.example.com. IN A 10.10.10.10 server-r.example.com. IN A 10.20.20.20 wilma.imap.example.com. IN CNAME server-f.example.com. fred.imap.example.com. IN CNAME server-f.example.com. betty.imap.example.com. IN CNAME server-r.example.com. barney.imap.example.com. IN CNAME server-r.example.com.

Cependant, si vous procédez ainsi, JE RECOMMANDE FORTEMENT FORTEMENT de générer automatiquement les enregistrements DNS à partir d'une base de données d'utilisateurs. Vous voulez vous assurer que lorsque des comptes sont créés et supprimés, les enregistrements DNS sont également créés et supprimés. Sinon, vous vous retrouverez avec un gâchis et beaucoup de confusion.

J'ai vu cela dans des entreprises comptant littéralement des milliers d'utilisateurs et, comme les choses étaient automatisées, cela fonctionne très bien.

Comme d'autres l'ont souligné, c'est une idée terrible pour une utilisation dans le monde réel.

Dans le monde réel, il existe des clients et des résolveurs non conformes qui ont des problèmes avec des réponses qui ne peuvent pas tenir dans un seul datagramme UDP, et il existe des pare-feu qui appliqueront des idées spécifiques mais non conformes au protocole sur les limites de taille des messages DNS.

Et même si vous pouviez compter sur votre réponse énorme dans tous les cas (ce que vous ne pouvez absolument pas), il y a une autre raison pour laquelle c'est une très mauvaise idée. Plus votre taille de réponse DNS est grande, plus elle est tentante en tant que charge utile pour les attaques par réflexion car vous fournissez un énorme facteur d'amplification. Dans ce type d'attaque par déni de service, qui est courant dans DNS, une requête UDP est envoyée à un résolveur récursif ouvert. L'adresse source des requêtes UDP est généralement facilement usurpée et l'attaquant définit la source de la requête sur l'adresse IP de leur cible. Deux effets souhaitables (pour l'attaquant) sont obtenus: premièrement - un effort d'envoi relativement faible de leur part (à partir d'une petite requête usurpée) se traduit par un torrent relativement important de trafic indésirable arrivant sur la cible (c'est le facteur d'amplification), et deuxièmement - la source réelle de l'attaque est cachée à la cible; la cible ne connaît que les adresses des résolveurs récursifs utilisés comme réflecteurs.

Point intéressant de trivia historique sur ce sujet. Dans les années 90, AOL a étendu ses enregistrements DNS de sorte qu'une requête MX renvoie> 512 octets. Cela a violé la RFC, cassé de nombreux serveurs SMTP (qmail étant populaire à l'époque) et causé de nombreux maux de tête aux administrateurs système. Le correctif nécessitait soit l' application de correctifs , soit l'ajout de routes statiques.

Je ne sais pas quelle est la situation actuelle, mais il y a quelques années, lorsque j'ai touché qmail pour la dernière fois, les correctifs étaient toujours en place.

http://www.gossamer-threads.com/lists/qmail/users/30503