2008-09-01 23 views

Respuesta

342

Usted querrá la SOA (Inicio de autoridad) récord para un determinado nombre de dominio, y esta es la forma de lograrlo mediante el nslookup universalmente disponibles herramienta de línea de comandos:

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. 

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

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

+6

¿Hay un indicador de línea de comando para el tipo de consulta SOA? –

+116

nslookup -type = soa stackoverflow.com –

+0

De todas las herramientas examinadas a continuación, nslookup es la única herramienta que también está disponible en la línea de comandos de MS-Windows. El método anterior también funciona muy bien en Windows 7. – Druvision

-2

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

NS51.DOMAINCONTROL.COM 
    NS52.DOMAINCONTROL.COM 
15

Tengo un DNS propagation tool diseñado para responder este tipo de preguntas.

La fuente se lanza bajo AGPLv3.

(Sí, la interfaz es bastante básico en el momento :))

También podría descubrir los servidores de nombres para un dominio con el comando "host":

 
[[email protected]:~]$ host -t ns stackoverflow.com 
stackoverflow.com name server ns51.domaincontrol.com. 
stackoverflow.com name server ns52.domaincontrol.com. 
+1

Su herramienta no proporciona la información de SOA –

+0

@cacho Es cierto; Bien puedo agregar eso, si tengo la oportunidad. –

1

Usted puede utilizar el servicio de whois. En un sistema operativo como UNIX, ejecutaría el siguiente comando. Alternativamente, puede hacerlo en la web al http://www.internic.net/whois.html.

stackoverflow.com whois

Obtendría la siguiente respuesta.

... texto eliminado aquí ...

servidores de dominio en orden indicado: NS51.DOMAINCONTROL.COM NS52.DOMAINCONTROL.COM

Puede utilizar nslookup o excavar para obtener más información sobre registros para un dominio dado. Esto podría ayudarlo a resolver los conflictos que ha descrito.

+2

Nada dice que la información proporcionada por whois está actualizada. Con frecuencia, no se debe a que las personas actualicen los registros NS en el archivo de zona sin notificar al registro o al registrador. – bortzmeyer

31

En * nix:

$ dig -t ns <domain name> 
+2

Pidió los servidores de nombres, no la dirección IPv4. Entonces, el tipo (-t) debe ser NS, no A. – bortzmeyer

5

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

En Linux o Mac puede utilizar los comandos whois, , host, nslookup o varios otros. nslookup tambié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 adicional: Sí, es posible.


aryeh es definitivamente incorrecto, ya que su sugerencia por lo general solo le dará la dirección IP para el nombre de host. Si utiliza , usted tiene que buscar registros NS, así:

dig ns stackoverflow.com 

Tenga en cuenta que esto puede preguntar a su servidor DNS local y por lo tanto pueden dar respuestas erróneas o fuera de la fecha en que se tiene en su caché

+6

Estos comandos son ** no ** equivalentes. Nada dice que la información dada por whois está actualizada. Con frecuencia, no se debe a que las personas actualicen los registros NS en el archivo de zona sin notificar al registro o al registrador. – bortzmeyer

+0

Nunca dije que lo fueran;) Puede cambiar los registros NS en su zona todo lo que desee, siempre que la zona principal no se actualice, 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). – hop

143

Ha utilizado el singular en su pregunta, pero normalmente hay varios servidores de nombres autorizados, el RFC 1034 recomienda al menos dos.

A menos que quiera decir "servidor de nombres primario" y no "servidor de nombres autorizado". Los servidores de nombres secundarios son autoritativos.

para averiguar los servidores de nombres de dominio en Unix:

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

a averiguar el servidor enumerado como primaria (la noción de "primaria" es bastante difusa en estos días y por lo general no tiene buena respuesta) :

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

para comprobar discrepancias entre los servidores de nombres, mi preferencia va a la antigua herramienta check_soa, se describe en Liu & Albitz "DNS BIND &" libro (editor de 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.

+3

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 simplemente devuelve el objetivo CNAME. –

+0

¿Cómo se hace un NS autorizado? – Overmind

+0

@Overmind usted no hace una NS "autorizada". Si un servidor de nombres está configurado como autoritativo para algunos dominios, significa que tiene archivos de zona localmente (generalmente archivos de texto plano, pero también se podría hacer de forma diferente) para estos dominios y responde a la consulta de ellos. Para ser útiles, deben estar listados como registros NS en la zona principal para cada uno de los dominios para los que están autorizados, de lo contrario nadie los consultaría de manera predeterminada. –

0

Desafortunadamente, la mayoría de estas herramientas solo devuelven el registro NS proporcionado por el propio servidor de nombres. Para ser más precisos al determinar qué servidores de nombres son realmente responsables de un dominio, debe usar "whois" y verificar los dominios allí enumerados O usar "dig [dominio] NS @ [servidor de nombres raíz]" y ejecutar eso de forma recursiva hasta que obtenga los listados de servidores de nombres ...

Ojalá hubiera una línea de comando simple que pudiera ejecutar para obtener ESE resultado de manera confiable y en un formato consistente, no solo el resultado del servidor de nombres . El propósito de esto para mí es poder consultar aproximadamente 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" u otra cosa en * nix?

+2

Simple. 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 tienen autoridad). Vamos a elegir d0.org.afilias-nst.org. Consulta con 'dig @ d0.org.afilias-nst.org NS ejemplo.org.'. – bortzmeyer

+0

El hecho de que la resolución devuelva, por defecto, los servidores de nombres listados por el dominio en sí es una buena cosa. Esa es la información autorizada. La delegación en la zona padre NO tiene autoridad. – bortzmeyer

+0

Y el puntero a whois es una pista falsa. La información del servidor whois name a menudo está desactualizada. El recurso autorizado es el DNS. – tripleee

2

Hemos creado un dns lookup tool que le proporciona 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 mediante la realización de un tiempo real (sin caché) búsqueda de DNS en los servidores de nombres raíz y luego siguiendo las referencias de servidores de nombres hasta llegar a los servidores de nombres autorizados. Esta es la misma lógica que usan los resolutores DNS para obtener respuestas autoritativas. Se selecciona (e identifica) un servidor de nombres autorizado y aleatorio en cada consulta, lo que le permite encontrar registros de DNS en conflicto mediante la realización de solicitudes múltiples.

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

Ejemplo: https://www.misk.com/tools/#dns/[email protected]

2

He encontrado que la mejor manera para añadir siempre la opción de rastreo +:

dig SOA +trace stackoverflow.com 

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

0

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 en realidad apuntan al único servidor de nombres autorizado bajo el control del propietario del dominio. El registro SOA en el servidor autoritativo 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 de otro modo) y no se debe confiar en ellos para determinar el servidor de nombres autorizado para un dominio dado.

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

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

Cuando tiene información confiable sobre el SOA del servidor autoritario de TLD, puede consultar el servidor de nombres primarios autoritativo (el que está en el registro SOA en el servidor de nombres gTLD!) Para cualquier otro registro NS, y luego continúe con la comprobación de todos los servidores de nombres que tiene al consultar los registros NS, para ver si hay alguna incoherencia para cualquier otro registro particular, en cualquiera de esos servidores.

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

Cuestiones relacionadas