Ya recibiste una respuesta hace mucho tiempo, pero creo que podemos ser más precisos y tienes una pregunta de seguimiento, que debería haber sido otra pregunta.
Así que volvamos desde el principio.
Si consulta a los servidores raíz para obtener información sobre la .COM
delegación (tenga en cuenta que todo lo siguiente se aplica de la misma manera .NET
ya que ambos son manejados por el mismo registro) obtendrá esta respuesta:
$ 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.
En resumen, cualquiera de estos servidores de nombres tiene autoridad .COM
y todos tienen los mismos datos (por lo que puede ampliar su pregunta, a.gtld-servers.net
de ninguna manera es especial, todo lo siguiente se aplicará a cualquiera de estos servidores de nombres).
Cuando consulte a estos servidores de nombres para cualquier .COM/.NET
nombre de dominio, deben responder con autoridad con los servidores de nombres autorizados para el nombre de dominio que está solicitando.
Por lo tanto, por definición, "¿Eso significa que a.gtld-servers.net (y * .gtld-Server.net) tienen un registro de todos los dominios .com localmente?", ¡Pero significa exactamente eso! Con algunas advertencias sobre "todo" que se aborda más abajo.
Tenga en cuenta que habla de registros de pegamento, este es un caso específico y no el más frecuente. Normalmente, una solicitud de un dominio en cualquiera de los servidores de nombres anteriores devolverá uno o más registros NS.
Dediquemos tiempo a abordar los otros puntos menores en su texto:
Responden muy rápido, así que no creo que estén haciendo una consulta más.
Un servidor de nombres autorizado, por definición, tiene los datos que necesita para responder consultas, sin tener que depender de ningún recurso externo, de lo contrario no es realmente autorizado.
En cuanto a la velocidad, esto es en parte subjetivo y altamente dependiente de qué y cómo se prueba, pero hay varios factores: de forma predeterminada, el DNS utiliza UDP, que es más ligero que TCP y, por lo tanto, más rápido, y tales servidores de nombres se emiten, lo que significa que con un poco de suerte siempre tener uno "cerca" de usted.
Me doy cuenta de que a.gtld-servers.net es probablemente varias máquinas
Puede eliminar el "probablemente" :-) Estos servidores de nombres reciben tantas consultas que cualquier casilla nunca podrá resistir.
Si va a https://stat.ripe.net/192.5.6.30#tabId=routing , verá mucha información que puede ser difícil de digerir, pero básicamente, al ver que esta IP única de a.gtld-servers.net
(de hecho, el bloque en el que es) es anunciado por varios AS, todos controlados por una compañía, lo cual es un fuerte indicador de cualquier difusión, que funciona muy bien para la mayoría de DNS.
Si va a http://www.root-servers.org/ puede obtener más información. Esto está relacionado con los servidores de nombres raíz, ya no son los .COM
mismos, pero técnicamente es exactamente lo mismo. Podría descubrir, por ejemplo, que los 13 servidores raíz son administrados por 12 organizaciones diferentes en 930 instancias (una instancia no es solo un servidor, es una ubicación, un "punto de presencia" donde el operador tiene un "nodo" que normalmente es equipo de enrutamiento, múltiples servidores en equilibrio de carga / configuración de conmutación por error, algunas capacidades de monitoreo / manos remotas, etc.). F
por ejemplo está en 222 lugares.
y que estoy siendo enrutado al más cercano a mí (a través de esa nueva tecnología one-ip-multiple-machine), pero esto solo significaría que varias otras máquinas tienen todos los dominios .com.
Sí, muchas máquinas tienen la lista de todos .COM
los nombres de dominio. Pero primero una precisión: en estos servidores de nombres obtendrá la lista de todos los servidores de nombres para todos los nombres de dominio .COM ... lo que significa que para los nombres de dominio no delegados no los encontrará aquí. Esto puede suceder en múltiples casos:
- cuando registra un nombre de dominio, puede elegir no establecer servidores de nombres o eliminarlos más tarde.
- su registrador, por ejemplo, debido a una disputa de pago podría agregar el estado
clientHold
en su nombre de dominio, lo que hace que desaparezca del DNS
- el registro podría poner el dominio
serverHold
por cualquier razón.
(consulte https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en si desea obtener más información sobre estos estados y otros).
Dependiendo de cómo defina "todos" y de lo que haría con dichos datos, es posible que no obtenga absolutamente todos ellos.
En todos los casos anteriores, el dominio no aparecerá en los servidores DNS del registro, pero aparecerá cuando realice una consulta whois. Entonces, los servidores whois (de nuevo, ni una sola caja) también tendrán ... la lista de todos los nombres de dominio .COM e incluso más datos que en los servidores de nombres porque:
- realmente tiene todos los nombres de dominio, incluidos los que no se resuelven y, por lo tanto, no están en los servidores de nombres de registro
- whois proporciona mucha más información, como datos de contacto
Y estos todavía son solo servicios de registro públicos que tienen, de alguna manera o parte, la lista (o parte de ella) de nombres de dominio.
En cuanto a su seguimiento:
Pregunta de seguimiento: si alguien "piratea" una de estas máquinas, ¿no podrían obtener una lista de todos los dominios .com?
Técnicamente sí. Pero:
- Este ciertamente no es el objetivo más fácil que encontrarás en línea
- Y en este caso específico, los datos ya están disponibles de forma gratuita.
.COM
es un gTLD y, como tal, está bajo contrato con ICANN. La ICANN exige a todos los registros de gTLD que publiquen sus archivos de zona (que es básicamente lo que usan los servidores de nombres, por lo que los registros NS más las colas A / AAAA), al menos una vez al día, y el acceso es gratuito para cualquier persona siempre que firme un acuerdo para asegurarse de que no reutiliza estos datos con fines "malos" (como volver a publicarlos usted mismo).
Consulte https://czds.icann.org/en para obtener todos los detalles al respecto. Esto puede darle acceso a cientos de archivos de zona de gTLD.
Tenga en cuenta que si su pregunta se extiende a "si alguien piratea una de estas máquinas y cambia el contenido que agrega o elimina nombres de dominio .COM ...", entonces podemos responder rápidamente con:
- los cambios no se verán en todo el mundo, ya que solo hackea una casilla y hay numerosos servidores de nombres, primero por nombre y luego por anycasting
- DNSSEC puede hacer que sus cambios aparezcan como errores y, por lo tanto, se detectarán rápidamente (además de cualquier contramedida local por parte del operador, por supuesto).
En resumen, no es la mejor idea hacer eso para meterse con .COM
los nombres de dominio, y hay otras formas.
Me doy cuenta de que la información del dominio es pública, pero aún es difícil de obtener a granel.
Ver arriba para el programa ICANN. En cuanto a los ccTLD, la situación varía, pero con mayor frecuencia no dan acceso a su archivo de zona, y no en tiempo real.
A veces, puede acceder a él después de un tiempo, por ejemplo a través de movimientos de "datos abiertos". Un ejemplo: https://opendata.afnic.fr/en/products-and-services/services/opendata-en.html para .FR
nombres de dominio.
Supongo que * .gtld-Server.net no admite transferencias de zona (aunque los servidores de nombres de .edu lo hicieron, al menos hace unos años).
Fácil de probar:
$ 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.
No, en este momento, ningún .COM
servidor de nombres autorizado acepta consultas AXFR. Pero esto no es necesariamente lo mismo en todas partes. Si consulta el f.root-servers.net
servidor de nombres, puede hacer una consulta AXFR para publicar todos los TLD. Algunos otros TLD también pueden permitir eso.
Tenga en cuenta que hay "muchas" recomendaciones en contra de permitir consultas públicas de AXFR. Los hechos son que, por definición, son respuestas enormes y que podrían dañar al servidor si se repiten, es cierto. On puede discutir sin cesar sobre por qué / si el público necesita esta información. Al principio del DNS se usaba más para copiar zonas entre servidores de nombres (ahora hay alternativas mucho mejores). Entonces, AXFR a menudo está deshabilitado ... excepto que si hace DNSSEC al mismo tiempo, de alguna manera específica (que es NSEC y no la variante NSEC3), es fácil caminar, a través de consultas DNS estándar y sin AXFR, todos sus zona y reconstruir el archivo de zona. Existen herramientas para hacer eso.
Tenga en cuenta también que varios proveedores en línea le venderán archivos de zona y / o una lista de todos los nombres de dominio para muchos TLD, que adquirieron por diversos medios (una idea entre otras: toma los archivos de zona abiertos, como .COM
, y para TLD .example
consulta uno por uno todo el nombre que ha encontrado .COM
, que podría darle algunas ideas, además de, por supuesto, caminar por el diccionario en función de los idiomas más utilizados en el TLD buscado).