¿Cómo encuentro el servidor de nombres autorizado para un nombre de dominio?

317

¿Cómo puedo encontrar el origen de los registros DNS en conflicto?

dns 
— Cuentos binarios
fuente

Respuestas:

413

Querrá el registro SOA (Start of Authority) para un nombre de dominio dado, y así es como lo logra utilizando la herramienta de línea de comando nslookup disponible universalmente :

command line> nslookup
> set querytype=soa
> stackoverflow.com
Server:         217.30.180.230
Address:        217.30.180.230#53

Non-authoritative answer:
stackoverflow.com
        origin = ns51.domaincontrol.com # ("primary name server" on Windows)
        mail addr = dns.jomax.net       # ("responsible mail addr" on Windows)
        serial = 2008041300
        refresh = 28800
        retry = 7200
        expire = 604800
        minimum = 86400
Authoritative answers can be found from:
stackoverflow.com       nameserver = ns52.domaincontrol.com.
stackoverflow.com       nameserver = ns51.domaincontrol.com.

los origen (o servidor de nombres primario en Windows) le dice que ns51.domaincontrol es el servidor de nombres principal para stackoverflow.com .

Al final de la salida, se enumeran todos los servidores autorizados, incluidos los servidores de respaldo para el dominio dado.

— Antti Kissaniemi
fuente
158
nslookup -type = soa stackoverflow.com
— Ben Amada
66
Sin embargo, en Windows, no puedo ver la respuesta "Respuestas autorizadas". Tengo Windows 8 y Ubuntu 12 uno al lado del otro y luego el mismo comando para el mismo dominio funciona en Ubuntu correctamente pero no en Windows.
— Mario Awad
1
tenga en cuenta que este programa no necesariamente muestra cambios recientes en las configuraciones de DNS, sin embargo, el uso me digpareció (ver respuesta a continuación)
— rogerdpack
66
¿Qué significa si no hay una respuesta autorizada pero la respuesta no autorizada está bien?
— Overmind
66
Si ejecuta nslookup -type=soa stackoverflow.comLinux hoy (2019-feb), la sección autoritativa está vacía.
— simpleuser
174

Usó el singular en su pregunta, pero generalmente hay varios servidores de nombres autorizados, el RFC 1034 recomienda al menos dos.

A menos que se refiera a "servidor de nombres primario" y no a "servidor de nombres autorizado". Los servidores de nombres secundarios son autorizados.

Para averiguar los servidores de nombres de un dominio en Unix:

  % dig +short NS stackoverflow.com
 ns52.domaincontrol.com.
 ns51.domaincontrol.com.

Para descubrir el servidor listado como primario (la noción de "primario" es bastante confusa en estos días y generalmente no tiene una buena respuesta):

% dig +short  SOA stackoverflow.com | cut -d' ' -f1
ns51.domaincontrol.com.

Para verificar las discrepancias entre los servidores de nombres, mi preferencia va a la check_soaherramienta anterior, descrita en el libro "DNS & BIND" de Liu & Albitz (editor O'Reilly). El código fuente está disponible en http://examples.oreilly.com/dns5/

% check_soa stackoverflow.com
ns51.domaincontrol.com has serial number 2008041300
ns52.domaincontrol.com has serial number 2008041300

Aquí, los dos servidores de nombres autorizados tienen el mismo número de serie. Bueno.

— bortzmeyer
fuente
55
dig + short no siempre da la respuesta que espero. Por ejemplo, un sitio definido como www.pressero.com, que es un CNAME para otro sitio: dig + short SOA solo devuelve el objetivo CNAME.
— Ross Presser
¿Cómo hacer que un NS tenga autoridad?
— Overmind
1
@Recuerde que no hace un NS "autoritario". Si un servidor de nombres está configurado como autorizado para algunos dominios, significa que tiene archivos de zona locales (normalmente archivos de texto planos, pero también se podría hacer de manera diferente) para estos dominios y responde a la consulta de ellos. Para que sean útiles, deben aparecer como registros NS en la zona principal para cada uno de los dominios para los que tienen autoridad; de lo contrario, nadie los consultaría de forma predeterminada.
— Patrick Mevzek
@RossPresser la respuesta estaba hablando de registros NS / SOA y dudo que lo haga www.pressero.com, probablemente estaba pensando en registros A (que es el tipo de registro predeterminado digsi no lo especifica). Pero si es necesario, solo agregue un tail -1para recuperar el resultado final.
— Patrick Mevzek
@PatrickMevzek Como dije en mi comentario, solía dig +short SOA www.pressero.com. Esto devuelve solo el objetivo CNAME, no el registro SOA para el pressero.comdominio, que es lo que esperaba. tail -1no ayuda a las cosas; dig +short SOAsolo emite una línea.
— Ross Presser
40

En * nix:

$ dig -t ns <domain name>
— aryeh
fuente
3
Pidió los servidores de nombres, no la dirección IPv4. Entonces, el tipo (-t) debe ser NS, no A.
— bortzmeyer
1
¿Por qué no escribir SOA @bortzmeyer?
— Randy L
Uh, porque eso devuelve el SOA en lugar del resultado NS?
— tripleee
17

Tengo una herramienta de propagación de DNS diseñada para responder a este tipo de preguntas.

La fuente se publica bajo AGPLv3.

(Sí, la interfaz es bastante básica en este momento :))

También puede encontrar los servidores de nombres para un dominio con el comando "host":

[davidp @ supernova: ~] $ host -t ns stackoverflow.com
servidor de nombres stackoverflow.com ns51.domaincontrol.com.
servidor de nombres stackoverflow.com ns52.domaincontrol.com.
— David precioso
fuente
@ cacho Eso es cierto; Bien puedo agregar eso, si tengo la oportunidad.
— David Precious
1
Está roto, muestra "502 Bad Gateway nginx / 1.14.2"
— Marco Demaio
8

Descubrí que la mejor manera de agregar siempre la opción + trace:

dig SOA +trace stackoverflow.com

Funciona también con CNAME recursivo alojado en diferentes proveedores. + trace trace implica + norecurse, por lo que el resultado es solo para el dominio que especifique.

— Alex
fuente
Tenga en cuenta que si está ejecutando un servidor NS local como dnsmasq + trace no devolverá nada ...
— Daniel Sokolowski
Este comando proporciona 53 líneas, 3652 bytes de salida, muchos de los cuales son valores aleatorios. ¿Cómo debería alguien interpretar el resultado para determinar cuál es el servidor de nombres autorizado?
— theferrit32
Lo leí de abajo hacia arriba. El registro SOA es lo que busca. Puede grep para que SOA tenga menos datos.
— Alex
6

El término que debe buscar en Google es "autoritario", no "definitivo".

En Linux o Mac puede utilizar los comandos whois, dig, host, nslookupo varios otros. nslookupTambién podría funcionar en Windows.

Un ejemplo:

$ whois stackoverflow.com
[...]
   Domain servers in listed order:
      NS51.DOMAINCONTROL.COM
      NS52.DOMAINCONTROL.COM

En cuanto al crédito extra: Sí, es posible.

aryeh definitivamente está equivocado, ya que su sugerencia generalmente solo le dará la dirección IP para el nombre de host. Si usa dig, debe buscar registros NS, así:

dig ns stackoverflow.com

Tenga en cuenta que esto puede preguntarle a su servidor DNS local y, por lo tanto, puede dar respuestas incorrectas o desactualizadas que tiene en su caché.

66
Estos comandos no son equivalentes. Nada dice que la información dada por whois esté actualizada. Con frecuencia, no es porque las personas actualicen los registros NS en el archivo de zona sin notificar al registro o al registrador.
— bortzmeyer
Nunca dije que lo fueran;) Puede cambiar los registros NS en su zona todo lo que desee, siempre que la zona principal no esté actualizada, nada cambiará. Y una actualización de la zona principal generalmente va de la mano con una actualización de los datos whois (al menos con mis proveedores).
5

Hemos creado una herramienta de búsqueda de DNS que le brinda los servidores de nombres autorizados del dominio y sus registros DNS comunes en una sola solicitud.

Ejemplo: https://www.misk.com/tools/#dns/stackoverflow.com

Nuestra herramienta encuentra los servidores de nombres autorizados realizando una búsqueda de DNS en tiempo real (sin caché) en los servidores de nombres raíz y luego siguiendo las referencias del servidor de nombres hasta llegar a los servidores de nombres autorizados. Esta es la misma lógica que utilizan los solucionadores de dns para obtener respuestas autorizadas. Se selecciona (y se identifica) un servidor de nombres autorizado aleatorio en cada consulta que le permite encontrar registros DNS en conflicto realizando múltiples solicitudes.

También puede ver la ruta de delegación del servidor de nombres haciendo clic en "Servidores de nombres autorizados" en la parte inferior de los resultados de búsqueda de DNS del ejemplo anterior.

Ejemplo: https://www.misk.com/tools/#dns/stackoverflow.com@f.root-servers.net

— Nitin Agarwal
fuente
2

Puedes usar el servicio whois. En un sistema operativo similar a UNIX, ejecutaría el siguiente comando. Alternativamente, puede hacerlo en la web en http://www.internic.net/whois.html .

whois stackoverflow.com

Obtendría la siguiente respuesta.

... texto eliminado aquí ...

Servidores de dominio en el orden indicado: NS51.DOMAINCONTROL.COM NS52.DOMAINCONTROL.COM

Puede usar nslookup o cavar para obtener más información sobre los registros de un dominio determinado. Esto podría ayudarlo a resolver los conflictos que ha descrito.

— Chris de Vries
fuente
2
Nada dice que la información dada por whois esté actualizada. Con frecuencia, no es porque las personas actualicen los registros NS en el archivo de zona sin notificar al registro o al registrador.
— bortzmeyer
Si bien no es una respuesta directa a la pregunta, "whois" es útil porque le dice quiénes deben ser los servidores de nombres en algún lugar (incluso si por alguna razón no lo son actualmente).
— SomeoneElse
1

Desafortunadamente, la mayoría de estas herramientas solo devuelven el registro NS tal como lo proporciona el propio servidor de nombres. Para ser más exactos al determinar qué servidores de nombres son realmente responsables de un dominio, debe usar "whois" y verificar los dominios enumerados allí O usar "cavar [dominio] NS @ [servidor de nombres raíz]" y ejecutarlo recursivamente hasta que obtenga los listados del servidor de nombres ...

Desearía que hubiera una línea de comando simple que pudieras ejecutar para obtener ESE resultado de manera confiable y en un formato consistente, no solo el resultado que se proporciona desde el servidor de nombres en sí. El propósito de esto para mí es poder consultar sobre 330 nombres de dominio que administro para poder determinar exactamente a qué servidor de nombres apunta cada dominio (según la configuración de su registrador).

¿Alguien sabe de un comando usando "dig" o "host" o algo más en * nix?

2
Sencillo. Supongamos que el dominio es example.org. Primero, necesita encontrar los servidores de nombres de ".org" con 'dig + short NS org.'. Luego consulta uno de ellos (cualquiera, todos son autorizados). Elijamos d0.org.afilias-nst.org. Usted consulta con 'dig @ d0.org.afilias-nst.org NS example.org.'.
— bortzmeyer
El hecho de que la resolución devuelva, por defecto, los servidores de nombres enumerados por el dominio en sí es algo bueno. Esa es la información autorizada. La delegación en la zona principal NO tiene autoridad.
— bortzmeyer
Y el puntero a whois es un arenque rojo. La información del servidor de nombres whois a menudo es obsoleta. El recurso autorizado es el DNS.
— tripleee
1
Whois es completamente arbitrario. El valor que ve en la lista whois no tiene vínculos técnicos con DNS. A menudo está desactualizado o está bien mal. Llegaría al extremo de decir que los datos whois casi nunca deberían ser confiables. Hay registros 'delgados' y 'gruesos'. Los dos registros gruesos bien conocidos son los registros .com y .net. Es probable que estos registros contengan todos los datos de DNS y sirvan respuestas whois de confianza. Casi todos los demás registros son 'cosa' y ejecutan sus propios registros whois. Estos datos son frecuentemente incorrectos.
— Mark
1

Los registros SOA están presentes en todos los servidores más arriba en la jerarquía, sobre los cuales el propietario del dominio NO tiene control, y todos en efecto apuntan al único servidor de nombres autorizado bajo el control del propietario del dominio.

El registro SOA en el servidor autorizado en sí mismo, por otro lado, no es estrictamente necesario para resolver ese dominio, y puede contener información falsa (o servidores primarios ocultos o restringidos) y no se debe confiar en él para determinar el servidor de nombres autorizado para un dominio dado

Debe consultar el servidor que tiene autoridad para dominio de nivel superior para obtener información SOA confiable para un dominio secundario determinado.

(La información sobre qué servidor tiene autoridad para qué TLD se puede consultar desde los servidores de nombres raíz).

Cuando tenga información confiable sobre el SOA del servidor autorizado de TLD, puede consultar el servidor de nombres primario en sí mismo (¡el que está en el registro SOA en el servidor de nombres de gTLD!) Para cualquier otro registro NS, y luego verificar todos esos servidores de nombres que tiene al consultar los registros NS, para ver si hay alguna inconsistencia para algún otro registro en particular, en cualquiera de esos servidores.

Todo esto funciona mucho mejor / confiable con Linux y Dig que con nslookup / windows.

— Dennis
fuente
0

Una manera fácil es usar una herramienta de dominio en línea. Mi favorito es Herramientas de dominio (anteriormente whois.sc). Sin embargo, no estoy seguro de si pueden resolver registros DNS conflictivos. Como ejemplo, los servidores DNS para stackoverflow.com son

  NS51.DOMAINCONTROL.COM
  NS52.DOMAINCONTROL.COM
— Kyle Cronin
fuente
0

He encontrado que para algunos dominios, las respuestas anteriores no funcionan. La forma más rápida que he encontrado es primero buscar un registro NS. Si eso no existe, busque un registro SOA. Si eso no existe, resuelva recursivamente el nombre usando dig y tome el último registro NS devuelto. Un ejemplo que se ajusta a esto esanalyticsdcs.ccs.mcafee.com.

  1. Busque un registro NS

host -t NS analyticsdcs.ccs.mcafee.com.

  1. Si no se encuentra NS, busque un registro SOA

host -t SOA analyticsdcs.ccs.mcafee.com.

  1. Si ni NS ni SOA, haga recursivo completo y tome el último NS devuelto

dig +trace analyticsdcs.ccs.mcafee.com. | grep -w 'IN[[:space:]]*NS' | tail -1

  1. Probar que el servidor de nombres devuelto funciona

host analyticsdcs.ccs.mcafee.com. gtm2.mcafee.com.

— dannyw
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.