¿Cómo probar si la información de DNS se ha propagado?

16

Configuré una nueva entrada de DNS para uno de mis subdominios (todavía no he configurado ningún host virtual de Apache ni nada por el estilo). ¿Cómo puedo verificar que la información del DNS se haya propagado?

Supuse que podía simplemente ping my.subdomain.comy supongo que si se pudiera resolver, mostraría la dirección IP que especifiqué en el registro A. Sin embargo, no sé si estoy asumiendo correctamente. ¿Cuál es la mejor manera de verificar esta información?

domain-name-system Andrés
fuente
3
No es una pregunta tonta. No es tan sencillo descubrir este tipo de cosas.
aseq
1
Estoy de acuerdo con @aseq en que esta no es una pregunta tonta , pero "pruébalo y verás" también te habría dado la respuesta. También es algo que Google podría responder con la misma facilidad con un poco de esfuerzo (busque How to test if DNS information has propagated- el título de la pregunta sangrienta genera buenos resultados de Google).
voretaq7
44
No creo que hayas perdido el tiempo de la gente. Su pregunta provocó algunas respuestas valiosas. Nunca se sabe cómo puede resultar una pregunta aparentemente simple que podría "simplemente buscarse en Google". Uno de los valores de este foro es que las respuestas y las preguntas se pueden ampliar fácilmente.
aseq
1
@andrew no tiene nada de malo en preguntar lo que muchos de nosotros vemos como preguntas simples: este será probablemente el mejor resultado de Google para esa cadena en unos pocos días debido a cómo se indexa / clasifica el sitio. En general, aunque Google es un lugar mejor (más rápido) para buscar: si Google no sabe, pregunte aquí (y Google aprenderá) :-)
voretaq7
1
Descubrí por qué nada de lo que intentaba funcionaba. Aparentemente, nuestra red está configurada de manera que también se debe agregar un nuevo subdominio en nuestro DNS local. Entonces el subdominio era accesible desde el mundo exterior, solo que no en nuestra red donde estaba probando. = [Pero al usar nslookupy digal especificar un servidor externo, lo hice para poder verificar la información de DNS externo.
Andrew

Respuestas:

15

Puede usar dig o nslookup, digamos que su servidor de nombres (o el de su proveedor si no ejecuta el suyo) es ns1.example.com.

Usando nslookup:

nslookup - ns1.example.com

En el tipo de solicitud:

my.example.com

Si se resuelve a lo que esperaba, entonces funciona. Debería darte algo como:

Name:   example.com
Address: 192.0.43.10

Todavía puede tomar un tiempo propagarse al resto de Internet, eso está fuera de su control.

Usando cavar:

[email protected] my.example.com

Deberías ver algo como:

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

Solo usar ping puede darle una idea, pero solo cuando se ha propagado (el almacenamiento en caché de servidores de nombres remotos puede ser una mejor manera de describirlo) y su caché dns local puede necesitar ser vaciada. Aunque en su caso esto no se aplica porque se trata de un nuevo registro. En ese caso, debería estar disponible de inmediato. La forma anterior es más precisa para darle una idea en lugar de simplemente hacer ping.

Si usa Windows, entonces los comandos y la sintaxis pueden diferir ligeramente, pero son bastante similares.

aseq
fuente
3
+1 Si está haciendo algo con DNS, obtenga una copia de dig(* los sistemas nix ya lo tienen, hay varias versiones para Windows disponibles).
Chris S
3
-1. Lo siento. Realmente lo estoy, pero esta respuesta "propaga" el mito de que los registros DNS se propagan, lo que ciertamente NO HACEN. El término que está buscando es "almacenamiento en caché", que es lo que sucede con los registros DNS, según el TTL del registro. Como el OP se refiere a un nuevo registro DNS, no se puede haber producido el almacenamiento en caché, por lo tanto, cualquier cliente DNS que busque resolver el registro en cuestión obtendrá la respuesta ... inmediatamente ... ya que ese cliente no puede haberlo almacenado en caché ... o ese servidor DNS de los clientes ... o cualquier otro servidor DNS. Los registros DNS no se propagan al "resto de Internet".
joeqwerty
1
joeqwerty es absolutamente correcto. Los servidores dns almacenarán en caché un golpe positivo o negativo durante un tiempo predefinido. Sin embargo, además de la publicación original, hay varios servidores de nombres públicos con los que puede verificar, incluidos el antiguo GTE (4.2.2.1, 4.2.2.2, 4.2.2.3 y 4.2.2.4) y google (8.8.8.8, 8.8. 4.4) Como regla general, los nuevos cambios pueden llevar hasta la duración del ttl para un impacto positivo o negativo. Sin embargo, hay casos en los que las aplicaciones implementan una mala lógica y respuestas de caché durante un período de tiempo más largo.
bangdang
2
No creo que realmente tengas que apegarte a la definición exacta para entender. Además, creo que propagar no es una mala palabra para usar. Cubre el tema en el sentido de que el almacenamiento en caché del registro DNS se extiende a una gama más amplia de servidores. A esa propagación se refiere la propagación. Actualicé mi respuesta para reflejar el hecho de que un nuevo registro está disponible de inmediato.
aseq
1
@aseq, es un término engañoso. Y sobre todo resulta que las personas que piensan / hablan sobre DNS como una especie de "propagación" no saben cómo funciona DNS. Por lo general, dicen una mierda como "lleva de 2 a 3 días que su información de DNS se propague a través de Internet / Tierra", y así sucesivamente.
poige
7

No puede probar la propagación de registros DNS porque no se produce la propagación DNS. Lo que puede probar es si un cliente o servidor DNS tiene o no un registro DNS particular en caché.

Como se trata de un nuevo registro DNS, no se pudo haber producido el almacenamiento en caché. Suponiendo que sus servidores de nombres están registrados correctamente en los servidores principales y que sus servidores de nombres funcionan correctamente, este registro DNS debe estar disponible de inmediato para todos y cada uno de los clientes o servidores DNS.

joeqwerty
fuente
Me alegra ayudar ...
joeqwerty
¿Hay alguna forma de verificar que ingresé una IP válida? Solo quería estar seguro de que la dirección IP que utilicé era la correcta. Alguien con quien hablé parecía pensar que el ping fallaría si aún no tuviera un Apache VHost configurado.
Andrew
Ping no es una herramienta de prueba de DNS. Dig y Nslookup son herramientas de prueba de DNS. Use Dig o Nslookup para probar el nuevo registro DNS. Consulte el registro en su servidor de nombres y luego consulte el registro en otros servidores de nombres para asegurarse de que encuentren su servidor de nombres y que su servidor de nombres responda con la respuesta correcta.
joeqwerty
1
"propagación" es una noción creada en caso de que las personas no puedan entender la situación real, que es el envejecimiento y la caducidad de la memoria caché. Lo que los proveedores de DNS tenían que decir es que "sus datos no se verán hasta después de las XX horas". Una explicación de por qué era necesaria para que no pareciera que el proveedor de DNS fue la demora. Demasiada gente "no puede manejar la verdad". La "propagación" inventada es una historia de portada efectiva. Los verdaderos expertos en DNS saben lo que realmente sucede porque leen los detalles técnicos.
Skaperen
Es cierto ... odio usar un término que "propaga" un concepto erróneo de cómo funciona DNS.
joeqwerty
5

Si bien las otras respuestas son bastante buenas, recuerde que lo que se le propaga a usted puede no serlo a mí. en lugar de usar DIG o NSlookup y pasar una hora revisando servidores DNS en todo el mundo, generalmente uso http://www.whatsmydns.net/ para ver cómo va la propagación.

Jim B
fuente
No hay propagación en DNS, este término es bastante engañoso para todo tipo de lamers que no se encontrarán leyendo RFC, así que no <strike> propague </strike> use este término, por favor. ;-D
poige
1
Por supuesto, hay una propagación en DNS que los RFC suponen que el lector entiende que la información puede propagarse a medida que los servidores realizan búsquedas y caché. Es particularmente obvio cuando los lectores leen RFC y luego se preguntan por qué un registro en su servidor no coincide con los resultados de una búsqueda desde un servidor diferente. Descubren que propagar tiene la definición de "propagarse ampliamente" (que es exactamente lo que debe verificarse - la distribución de registros actualizados)
Jim B
Ni distribución, ni propagación (excepto maestro a esclavo).
poige
Probablemente sea una reliquia de cuando a veces se tardaba casi un día en realizar cambios en los dominios .com cargados en los servidores de nombres raíz (¡allá cuando .com estaba en las raíces!)
Cakemox
@ poige- gracias por verificar tu falta de comprensión de cómo funciona el almacenamiento en caché de DNS. Sugeriría leer los RFC sobre cómo funciona el DNS y quizás consultar el sitio web al que me vinculé para ver ejemplos del mundo real.
Jim B
3

La forma más fácil de asegurarse de que sus servidores DNS autorizados en su ruta de delegación responden correctamente es usar dig +trace:

; <<>> DiG 9.7.3 <<>> +trace www.google.com a
;; global options: +cmd
.           80050   IN  NS  m.root-servers.net.
.           80050   IN  NS  f.root-servers.net.
.           80050   IN  NS  i.root-servers.net.
.           80050   IN  NS  h.root-servers.net.
.           80050   IN  NS  c.root-servers.net.
.           80050   IN  NS  k.root-servers.net.
.           80050   IN  NS  d.root-servers.net.
.           80050   IN  NS  g.root-servers.net.
.           80050   IN  NS  a.root-servers.net.
.           80050   IN  NS  b.root-servers.net.
.           80050   IN  NS  e.root-servers.net.
.           80050   IN  NS  l.root-servers.net.
.           80050   IN  NS  j.root-servers.net.
;; Received 509 bytes from 192.168.1.1#53(192.168.1.1) in 0 ms

com.            172800  IN  NS  c.gtld-servers.net.
com.            172800  IN  NS  k.gtld-servers.net.
com.            172800  IN  NS  g.gtld-servers.net.
com.            172800  IN  NS  d.gtld-servers.net.
com.            172800  IN  NS  j.gtld-servers.net.
com.            172800  IN  NS  f.gtld-servers.net.
com.            172800  IN  NS  i.gtld-servers.net.
com.            172800  IN  NS  m.gtld-servers.net.
com.            172800  IN  NS  e.gtld-servers.net.
com.            172800  IN  NS  a.gtld-servers.net.
com.            172800  IN  NS  l.gtld-servers.net.
com.            172800  IN  NS  h.gtld-servers.net.
com.            172800  IN  NS  b.gtld-servers.net.
;; Received 504 bytes from 198.41.0.4#53(a.root-servers.net) in 127 ms

google.com.     172800  IN  NS  ns2.google.com.
google.com.     172800  IN  NS  ns1.google.com.
google.com.     172800  IN  NS  ns3.google.com.
google.com.     172800  IN  NS  ns4.google.com.
;; Received 168 bytes from 192.43.172.30#53(i.gtld-servers.net) in 20 ms

www.google.com.     604800  IN  CNAME   www.l.google.com.
www.l.google.com.   300 IN  A   173.194.35.180
www.l.google.com.   300 IN  A   173.194.35.178
www.l.google.com.   300 IN  A   173.194.35.176
www.l.google.com.   300 IN  A   173.194.35.177
www.l.google.com.   300 IN  A   173.194.35.179
;; Received 132 bytes from 216.239.34.10#53(ns2.google.com) in 27 ms

Esto seguirá a las delegaciones a los servidores de nombres autorizados para su consulta. La última respuesta es normalmente la que más le preocupa, pero el seguimiento es útil ya que mostrará quién está respondiendo para cada delegación. Sin embargo, si está cambiando los servidores de nombres, esto puede ser muy útil.

Tenga en cuenta que trace rastreará los servidores autorizados directamente, por lo que no hay almacenamiento en caché. Esta es la mejor indicación de que las respuestas se devuelven como se esperaba, pero no es una buena indicación de lo que los usuarios finales podrían experimentar. Sin embargo, dado que a menudo no tiene control sobre los servidores de nombres de almacenamiento en caché de otras personas de todos modos (más allá de tener la previsión de reducir su TTL, espere el TTL original, realice el cambio y luego restaure el TTL), por lo general no vale la pena verificarlo.

Cakemox
fuente