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 .COM
délégation (notez que tout ce qui suit s'applique de la même manière car .NET
les 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é .COM
et ils ont tous les mêmes données (vous pouvez donc élargir votre question, ce a.gtld-servers.net
n'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/.NET
nom 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 à .COM
ceux-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.). F
par 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 .COM
les 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:
- 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.
- votre bureau d'enregistrement, par exemple en raison d'un litige de paiement, pourrait ajouter le statut
clientHold
sur votre nom de domaine, ce qui le fait disparaître du DNS
- le registre pourrait mettre le domaine
serverHold
pour 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:
- 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
- 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:
- Ce n'est certainement pas la cible la plus simple que vous trouverez en ligne
- Et dans ce cas précis, les données sont déjà disponibles gratuitement.
.COM
est 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:
- 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
- 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 .COM
les 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 .FR
les 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 .COM
serveur 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.net
serveur 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, .example
vous 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é).