A.gtld-servers.net a-t-il une liste de tous les domaines .com?

14

Lorsque je le fais dig @a.gtld-servers.net example.com, il retourne rapidement les serveurs de noms example.comet les adresses IP de ces serveurs de noms (enregistrements de colle).

Est-ce à dire a.gtld-servers.net(et *.gtld-servers.net) avoir un enregistrement de tous les .comdomaines localement? Ils répondent très rapidement, donc je ne pense pas qu'ils posent eux-mêmes une autre question. De même, une demande pour example.comles serveurs de noms de ne me redirige pas vers domains.starting.with.e.gtld-servers.netquoi que ce soit.

Je me rends compte qu'il a.gtld-servers.nets'agit probablement de plusieurs machines et que je suis redirigé vers celle la plus proche de moi (grâce à cette nouvelle technologie one-ip-multiple-machine), mais cela signifierait simplement que plusieurs autres machines ont tous les .comdomaines.

EDIT: Merci à tous ceux qui ont répondu! Question de suivi: si quelqu'un "pirate" une de ces machines, ne pourrait-il pas obtenir une liste de tous les .comdomaines? Cela semble être une information utile, à moins qu'elle ne soit déjà disponible quelque part gratuitement? Je me rends compte que les informations sur le domaine sont publiques, mais sont toujours difficiles à obtenir en masse. Je suppose que *.gtld-servers.netne prend pas en charge les transferts de zone (bien que .edules serveurs de noms l'aient fait, il y a au moins quelques années).

REMARQUE: je me rends compte que example.com n'est pas un domaine réel - remplacez-le simplement par tout autre domaine .com ci-dessus (j'avais à l'origine xyz.com, mais quelqu'un l'a correctement modifié pour éviter d'utiliser un vrai nom de domaine).

barrycarter
la source
Question de suivi: oui, ils pourraient obtenir la liste, et pour la plupart des domaines de premier niveau, cette liste n'est pas accessible au public et vous n'êtes "autorisé" à interroger que par nom. Certaines zones sont toujours publiques (actuellement), par exemple la zone racine ou la zone suédoise.
Vladimír Čunát
1
@ VladimírČunát pour tous les gTLD, les fichiers de zone sont publics, voir czds.icann.org/en Ceci est conforme au contrat de l'ICANN. Pour les ccTLD, cela varie, mais la plupart ne donnent pas cette liste.
Patrick Mevzek
@PatrickMevzek sympa, bien que les gTLD les plus intéressants ne soient apparemment pas là (com, org, ...).
Vladimír Čunát
@ VladimírČunát pour ceux qui ne sont pas là, vous devez contacter le registre des gTLD: ils auront un processus séparé car ils sont tenus par leur contrat ICANN de donner accès à leurs fichiers de zone.
Patrick Mevzek

Réponses:

18

Oui, les "x.gtld-servers.net" sont les serveurs faisant autorité pour le domaine de premier niveau "com", donc ils ont tous les "pointeurs" pour les domaines .com. Vous pouvez voir les serveurs de noms pour le TLD en exécutant

dig -t ns com
dig -t ns us
dig -t ns dk
dig -t ns aero
Poser une question à Bjørn Hansen
la source
Avec les noms à étiquette unique, il est préférable d'inclure la fin .- com., us.- pour éviter que le nom de domaine par défaut ne soit ajouté. (Par exemple, lors de la résolution à l' comintérieur du réseau de Contoso Inc, le système peut essayer com.contoso.net. avant juste com.)
user1686
4
Je ne pense pas que digjamais utilise le chemin de recherche; les autres "vrais outils de débogage DNS" ne devraient pas non plus. (nslookup le fait, mais ne l'utilisez pas pour déboguer DNS). :-)
Demandez à Bjørn Hansen le
1
Oh les vieilles manières. : D @ AskBjørnHansen a tout à fait raison. utilisez simplement creuser plutôt que nslookupdans tous les cas
Dan Bradbury
ils ont donc tous les "pointeurs" pour les domaines .com. pour être précis, ils ont tous les noms de domaine .COM qui sont délégués, c'est-à-dire avoir des enregistrements NS, ce qui n'est pas absolument tous les noms de domaine .COM existants, il y a quelques différences en pourcentage.
Patrick Mevzek
@grawity le point final ne serait strictement nécessaire qu'en cas d'ambiguïté. -test facultatif, vous pouvez le faire dig com NSet creuser fera la bonne chose (je mets le type d'enregistrement en majuscules juste comme convention pour la lisibilité mais ce n'est pas obligatoire). Mais quand vous voulez faire une requête pour quelque chose qui pourrait être interprété comme une option, vous avez un problème, résolu par le point.
Patrick Mevzek
3

Effectuez une requête pour le domaine lui-même - dig @a.gtld-servers.net com.- et recherchez l'indicateur "réponse faisant autorité":

snowflake ~ $ dig @a.gtld-servers.net com | grep flags
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
             ^^
user1686
la source
1

Vous avez déjà reçu une réponse il y a longtemps, mais je pense que nous pouvons être plus précis et vous avez une question complémentaire, qui aurait dû être une autre question en fait.

Revenons donc au début.

Si vous interrogez les serveurs racine pour en savoir plus sur la .COMdélégation (notez que tout ce qui suit s'applique de la même manière car .NETles deux sont gérés par le même registre), vous obtenez cette réponse:

$ dig @a.root-servers.net com. NS +noall +auth

; <<>> DiG 9.12.0 <<>> @a.root-servers.net com. NS +noall +auth
; (1 server found)
;; global options: +cmd
com.            172800 IN NS e.gtld-servers.net.
com.            172800 IN NS b.gtld-servers.net.
com.            172800 IN NS j.gtld-servers.net.
com.            172800 IN NS m.gtld-servers.net.
com.            172800 IN NS i.gtld-servers.net.
com.            172800 IN NS f.gtld-servers.net.
com.            172800 IN NS a.gtld-servers.net.
com.            172800 IN NS g.gtld-servers.net.
com.            172800 IN NS h.gtld-servers.net.
com.            172800 IN NS l.gtld-servers.net.
com.            172800 IN NS k.gtld-servers.net.
com.            172800 IN NS c.gtld-servers.net.
com.            172800 IN NS d.gtld-servers.net.

Donc, en résumé, l'un de ces serveurs de noms fait autorité .COMet ils ont tous les mêmes données (vous pouvez donc élargir votre question, ce a.gtld-servers.netn'est en rien spécial, tout ce qui suit s'applique à l'un de ces serveurs de noms).

Lorsque vous interrogerez ces serveurs de noms pour tout .COM/.NETnom de domaine dont ils ont besoin pour répondre avec autorité aux serveurs de noms faisant autorité pour le nom de domaine que vous demandez.

Par conséquent, par définition, "Cela signifie-t-il que a.gtld-servers.net (et * .gtld-servers.net) ont un enregistrement de tous les domaines .com localement?", Pourtant cela signifie exactement cela! Avec une mise en garde autour de "tous" qui est abordé ci-dessous.

Notez que vous parlez d'enregistrements de colle, il s'agit d'un cas spécifique et non le plus fréquent. En règle générale, une demande de domaine auprès de l'un des serveurs de noms ci-dessus ne fera que restituer un ou plusieurs enregistrements NS.

Prenons le temps d'aborder les autres points mineurs de votre texte:

Ils répondent très rapidement, donc je ne pense pas qu'ils posent eux-mêmes une autre question.

Un serveur de noms faisant autorité, par définition, dispose des données dont il a besoin pour répondre aux requêtes, sans avoir à s'appuyer sur une ressource externe, sinon il ne fait pas vraiment autorité.

Quant à la vitesse, elle est en partie subjective et dépend fortement de quoi et comment vous testez, mais il y a plusieurs facteurs: par défaut, DNS utilise UDP qui est plus léger que TCP donc plus rapide, et ces serveurs de noms sont anycasted ce qui signifie qu'avec un peu de chance, vous avez toujours en avoir un «près» de vous.

Je réalise que a.gtld-servers.net est probablement plusieurs machines

Vous pouvez supprimer le "probablement" :-) Ces serveurs de noms reçoivent tellement de requêtes qu'aucune boîte ne pourra jamais résister.

Si vous allez sur https://stat.ripe.net/192.5.6.30#tabId=routing, vous verrez beaucoup d'informations qui peuvent être difficiles à digérer, mais en gros, vu que cette seule IP de a.gtld-servers.net(en fait le bloc dans lequel c'est) est annoncé par plusieurs AS tous contrôlés par une seule société, ce qui est un indicateur fort de anycasting, qui fonctionne à merveille pour la plupart des DNS.

Si vous allez sur http://www.root-servers.org/ vous pouvez en savoir plus. Ceci est lié aux serveurs de noms root, plus à .COMceux-ci, mais techniquement c'est exactement la même chose. Vous pourriez découvrir par exemple que les 13 serveurs racine sont gérés par 12 organisations différentes réparties sur 930 instances (une instance n'est pas seulement un serveur, c'est un emplacement, un "point de présence" où l'opérateur a un "nœud" qui est généralement équipement de routage, plusieurs serveurs dans la configuration d'équilibrage de charge / basculement, certaines capacités de surveillance / mains distantes, etc.). Fpar exemple est dans 222 endroits.

et que je suis routé vers celui le plus proche de moi (grâce à cette nouvelle technologie one-ip-multiple-machine), mais cela signifierait simplement que plusieurs autres machines ont tous les domaines .com.

Oui, de nombreuses machines ont la liste de tous .COMles noms de domaine. Mais d'abord une précision: sur ces serveurs de noms, vous obtiendrez la liste de tous les serveurs de noms pour tous les noms de domaine .COM ... ce qui signifie que pour les noms de domaine non délégués, vous ne les trouverez pas ici. Cela peut se produire dans plusieurs cas:

  1. lorsque vous enregistrez un nom de domaine, vous pouvez choisir de ne pas définir de serveurs de noms ou de les supprimer ultérieurement.
  2. votre bureau d'enregistrement, par exemple en raison d'un litige de paiement, pourrait ajouter le statut clientHoldsur votre nom de domaine, ce qui le fait disparaître du DNS
  3. le registre pourrait mettre le domaine serverHoldpour quelque raison que ce soit.

(voir https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en si vous souhaitez en savoir plus sur ces statuts et autres).

Selon la façon dont vous définissez «tout» et ce que vous feriez avec ces données, il se peut que vous ne les obteniez pas vraiment absolument toutes.

Dans tous les cas ci-dessus, le domaine n'apparaîtra pas sur les serveurs DNS du registre, mais apparaîtra lorsque vous effectuez une requête whois. Ainsi, les serveurs whois (encore une fois, pas une seule boîte) auront également ... la liste de tous les noms de domaine .COM et encore plus de données que sur les serveurs de noms car:

  1. vous avez vraiment tous les noms de domaine, y compris ceux qui ne se résolvent pas et donc pas sur les serveurs de noms de registre
  2. whois fournit beaucoup plus d'informations, telles que les données de contact

Et ce ne sont encore que des services de registre accessibles au public ayant, d'une manière ou d'une partie, la liste (ou une partie) des noms de domaine.

Quant à votre suivi:

Question de suivi: si quelqu'un "pirate" une de ces machines, ne pourrait-il pas obtenir une liste de tous les domaines .com?

Techniquement, oui. Mais:

  1. Ce n'est certainement pas la cible la plus simple que vous trouverez en ligne
  2. Et dans ce cas précis, les données sont déjà disponibles gratuitement.

.COMest un gTLD et en tant que tel est sous contrat avec l'ICANN. L'ICANN oblige tous les registres gTLD à publier leurs fichiers de zone (ce qui est fondamentalement ce que les serveurs de noms utilisent eux-mêmes, donc les enregistrements NS plus les colles A / AAAA), au moins une fois par jour, et l'accès est gratuit pour tous tant que vous signez un accord afin de vous assurer que vous ne réutilisez pas ces données à de "mauvaises" fins (comme les republier vous-même).

Voir https://czds.icann.org/en pour tous les détails à ce sujet. Cela peut vous donner accès à des centaines de fichiers de zone gTLD.

Notez que si votre question est étendue à "si quelqu'un pirate une de ces machines et modifie le contenu qui ajoute ou supprime des noms de domaine .COM ...", alors nous pouvons répondre rapidement avec:

  1. les changements ne seront pas visibles dans le monde entier, car vous ne piratez qu'une seule boîte et il existe de nombreux serveurs de noms, d'abord par nom puis par anycasting
  2. DNSSEC peut faire apparaître vos modifications comme des erreurs et sera donc repéré rapidement (en plus de toute contre-mesure locale par l'opérateur lui-même bien sûr).

En bref, ce n'est pas la meilleure idée de le faire pour jouer avec .COMles noms de domaine, et il existe d'autres moyens.

Je me rends compte que les informations sur le domaine sont publiques, mais qu'elles sont toujours difficiles à obtenir en masse.

Voir ci-dessus pour le programme ICANN. Quant aux ccTLD, la situation varie mais le plus souvent ils ne donnent pas accès à leur fichier de zone, et pas en temps réel.

Parfois, vous pouvez y accéder après un certain temps, par exemple par le biais de mouvements "open data". Un exemple: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html pour .FRles noms de domaine.

Je suppose que * .gtld-servers.net ne prend pas en charge les transferts de zone (bien que les serveurs de noms de .edu l'ont fait, il y a au moins quelques années).

Facile à tester:

$ for ns in $(dig NS . +noall +ans | grep 'IN NS' | awk '{print $5}') ; do echo $ns ; dig @$ns com. AXFR; done
c.root-servers.net.

; <<>> DiG 9.12.0 <<>> @c.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
m.root-servers.net.

; <<>> DiG 9.12.0 <<>> @m.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
i.root-servers.net.

; <<>> DiG 9.12.0 <<>> @i.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
e.root-servers.net.

; <<>> DiG 9.12.0 <<>> @e.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
j.root-servers.net.

; <<>> DiG 9.12.0 <<>> @j.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
l.root-servers.net.

; <<>> DiG 9.12.0 <<>> @l.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
g.root-servers.net.

; <<>> DiG 9.12.0 <<>> @g.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
k.root-servers.net.

; <<>> DiG 9.12.0 <<>> @k.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
b.root-servers.net.

; <<>> DiG 9.12.0 <<>> @b.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
h.root-servers.net.

; <<>> DiG 9.12.0 <<>> @h.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
d.root-servers.net.

; <<>> DiG 9.12.0 <<>> @d.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
;; QUERY SIZE: 44

;; connection timed out; no servers could be reached
;; Connection to 199.7.91.13#53(199.7.91.13) for com. failed: timed out.
a.root-servers.net.

; <<>> DiG 9.12.0 <<>> @a.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.
f.root-servers.net.

; <<>> DiG 9.12.0 <<>> @f.root-servers.net. com. AXFR
; (1 server found)
;; global options: +cmd
;; QUERY SIZE: 44

; Transfer failed.

Non, pour l'instant, aucun .COMserveur de noms faisant autorité n'accepte les requêtes AXFR. Mais ce n'est pas forcément la même partout. Si vous interrogez le f.root-servers.netserveur de noms, vous pouvez effectuer une requête AXFR pour publier tous les TLD. Certains autres TLD peuvent également permettre cela.

Notez qu'il existe «beaucoup» de recommandations contre l'autorisation des requêtes AXFR publiques. Les faits sont que ce sont d'énormes réponses par définition, et pourraient peser sur un serveur s'ils sont répétés, c'est vrai. On peut se disputer sans cesse sur pourquoi / si le public a besoin de ces informations. Il était plus utilisé au début du DNS pour copier des zones entre serveurs de noms (il existe maintenant de bien meilleures alternatives). AXFR est donc souvent désactivé ... sauf que si vous faites DNSSEC en même temps, d'une manière spécifique (c'est-à-dire NSEC et non NSEC3), il est facile de parcourir, à travers les requêtes DNS standard et sans AXFR, tous vos zone et reconstruire le fichier de zone. Des outils existent pour le faire.

Notez également que divers fournisseurs en ligne vous vendront des fichiers de zone et / ou une liste de tous les noms de domaine pour de nombreux TLD, qu'ils ont acquis par divers moyens (une idée parmi d'autres: vous prenez les fichiers de zone ouverts, comme .COM, et pour les TLD, .examplevous interrogez un par un tout le nom que vous avez trouvé .COM, qui pourrait vous donner quelques idées, en plus bien sûr de la marche de dictionnaire basée sur les langues les plus utilisées dans le TLD recherché).

Patrick Mevzek
la source