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

30

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.

Bozho
la source
2
Prenez-vous sur Anycast ?
Lie Ryan
4
J'ai appris il y a quelque temps que si jamais vous deviez demander "Quel est le nombre maximum de X?" vous l'utilisez probablement mal ...
LordOfThePigs
Pas nécessairement;) Mais en général, oui
Bozho

Réponses:

78

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.

Trop d'enregistrements

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:

deux requêtes (Ouvrez l'image dans un nouvel onglet de navigateur pour la taille réelle.)

nslookup

Requête TCP

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.

Ryan Ries
la source
15
Slow .... clap ....., monsieur.
mfinni
4
Pour ajouter à cela, si les enregistrements A sont interrogés via BIND (qui est ce qui s'exécute sur la majorité des serveurs DNS), il mélangera les enregistrements A et renverra une certaine quantité d'enregistrements A à partir de cela. Ce certain nombre est défini dans MAX_SHUFFLEle code source BIND (qui par défaut est 32).
ub3rst4r
1
Par curiosité, pourquoi ne le recommanderiez-vous pas? C'est certainement une chose très étrange, mais à part avoir des nœuds malveillants servant la demande sous un «bon» domaine et des nœuds défaillants recevant toujours des demandes, quoi d'autre peut mal tourner :-)
Bozho
De plus, l'expérience utilisateur ne changerait-elle pas constamment? Chaque nœud est-il une réplique complète? Comment feriez-vous pour que ce soit le cas s'ils sont sous le contrôle d'autres personnes? S'ils sont différents, alors les gens obtiendront un site aujourd'hui et un autre site demain. Personnellement, cela me rendrait fou!
Brandon
18

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.

Håkan Lindqvist
la source
10

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.

Kasperd
la source
2
De nos jours, chaque DNS devrait prendre en charge EDNS. La limite de 512 octets sur les réponses DNS n'est plus pratique en raison de DNSSEC.
Barmar
@Barmar Mais si vous l'avez activé, il y a un risque assez important que votre serveur soit utilisé dans des attaques d'amplification. La dernière fois que j'ai vérifié, j'ai constaté qu'en désactivant la liaison, c'était la seule chose qui pouvait être faite pour atténuer les attaques d'amplification. Jusqu'à ce qu'EDNS soit étendu avec un champ de cookie et que sa prise en charge soit largement déployée, il est toujours recommandé de désactiver la prise en charge des réponses supérieures à 512 octets.
kasperd
1
Je n'obtiens pas vraiment beaucoup de résultats de recherche pour désactiver EDNS étant une meilleure pratique. Citations s'il vous plait? Des attaques d'amplification utilisant des serveurs récursifs vont se produire, que l'EDNS soit activé ou non si votre réseau n'effectue pas de validation d'adresse source. Même si nous parlons d'un serveur faisant uniquement autorité, cela ne devient pertinent qu'une fois que vous l'avez configuré pour renvoyer autant de données dans une seule réponse, auquel cas sa désactivation ne vous aidera pas.
Andrew B
@AndrewB Je ne me souviens pas où j'ai lu cette recommandation. J'ai lu de nombreuses recommandations différentes sur la façon d'éviter les attaques d'amplification, et toutes sont nulles. C'est dommage que EDNS n'ait pas introduit de cookie, ce qui aurait pu être une solution efficace aux attaques d'amplification utilisant DNS. Ce que je recommande dans ma réponse est d'éviter de mettre autant d'enregistrements dans une requête, que vous comptez sur d'autres pour activer EDNS afin que les réponses soient efficaces.
kasperd
@AndrewB Si je place plus de 512 octets d'enregistrements A dans une zone et que je m'assure qu'il est hébergé sur un serveur DNS faisant autorité où EDNS est activé, cela peut être un problème pour les utilisateurs de résolveurs récursifs qui n'autorisent pas les réponses de cette taille. Et c'est pourquoi je recommande de garder le nombre d'enregistrements A plus bas. De plus, j'ai expliqué pourquoi l'avantage perçu de ce nombre d'enregistrements A n'est pas si pertinent.
kasperd
5

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.

Phil Frost
la source
Merci. Oui, je sais que les CDN fonctionnent de cette façon, mais à mon avis, ils ont un nombre limité d'enregistrements par sous-domaine (2 dans votre exemple). Mon autre question récente concerne exactement les CDN et leur implémentation DNS :-)
Bozho
2

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.

R ..
la source
1
Vous avez tout à fait raison, il existe de nombreux clients et résolveurs qui ne se comportent pas correctement et qui ne gèrent pas correctement les réponses DNS qui ne rentrent pas dans un seul datagramme UDP, mais veuillez abandonner l'idée que seuls les transferts de zone ou les demandes inhabituelles nécessitent des réponses de plus grande taille. D'après votre réponse, vous n'utilisez clairement pas la validation DNSSEC, mais de nombreuses personnes le sont (et DNSSEC n'est pas la seule raison pour laquelle des réponses plus importantes sont nécessaires, mais c'est très important.)
Michael McNally
@MichaelMcNally: DNSSEC n'est pas destiné (du moins pas par les implémenteurs, basé sur les threads des listes de diffusion glibc dans lesquelles j'ai été impliqué) à utiliser sur les points de terminaison (applications faisant des recherches DNS) mais sur le serveur de noms récursif local qui le fera recherches au nom des applications. Ainsi, même avec une configuration DNSSEC, il n'y a aucune raison de s'attendre à ce que les applications parlent DNS sur TCP. UDP fonctionne parfaitement bien.
R ..
1

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.

TomOnTime
la source
0

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.

Michael McNally
la source
0

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

Coops
la source