Consultar el DNS con dig y nslookup

Módulo 8: Seguridad y resolución de problemas · Tiempo de lectura: 10 minutos

Objetivo de aprendizaje: Después de esta lección podrá consultar registros con dig y nslookup, interrogar un servidor de nombres concreto y leer la salida.

Conceptos clave: dig, nslookup, Resolve-DnsName, +short, @server, +trace, secciones ANSWER y AUTHORITY, estado NOERROR, NXDOMAIN, SERVFAIL, dig -x

¿Por qué consultarlo usted mismo?

Un panel le muestra lo que usted ha introducido. Lo que ve el resto del mundo puede ser distinto: quizás otra entidad gestiona el DNS, o quizás todavía hay una respuesta antigua en una caché. Con un programa de consulta hace la misma pregunta que un navegador o un servidor de correo, y ve la respuesta real.

Existen tres programas habituales:

¿No tiene a mano una ventana de comandos? Entonces puede hacer exactamente lo mismo con una herramienta dig en línea (lección 8.3).

Su primera consulta con dig

Abra Terminal (macOS/Linux) y escriba:

$ dig example.com A

La salida, resumida, tiene este aspecto:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                  IN      A

;; ANSWER SECTION:
example.com.           2847    IN      A       192.0.2.10

;; Query time: 12 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)

Lo que debe leer:

• status: la palabra más importante. Vea la tabla a continuación.
• flags: ad significa que el resolver ha comprobado la respuesta con DNSSEC (lección 8.1).
• ANSWER SECTION: los registros en sí. Las columnas son las mismas que en una zona: nombre, TTL, clase, tipo, valor.
• TTL (aquí 2847): cuántos segundos permanecerá esta respuesta todavía en la caché del resolver. Si en la zona figuraba 3600, esta respuesta ya tiene 753 segundos. Si la vuelve a consultar, verá el número descender.
• SERVER: qué resolver ha consultado. En casa, suele ser su router.

Los tres estados que debe conocer

Variantes útiles

Solo la respuesta con +short:

$ dig +short MX example.com
10 mail.example.com.
20 mail2.example.com.

Consultar directamente otro resolver o un servidor de nombres con @. Este es el truco más importante en caso de problemas. Si pregunta directamente al servidor de nombres autoritativo, siempre obtiene la respuesta más reciente, sin caché:

$ dig +short NS example.com
ns1.hosting.example.
ns2.hosting.example.

$ dig +short A www.example.com @ns1.hosting.example
192.0.2.20

$ dig +short A www.example.com @9.9.9.9
192.0.2.10

Aquí ve de un vistazo qué está pasando: el servidor de nombres ya da la dirección nueva (.20), el resolver público todavía tiene la antigua en la caché (.10). No tiene que hacer nada, solo esperar a que pase la TTL (módulo 6).

Otros tipos: ponga el tipo después del nombre.

$ dig +short TXT example.com
"v=spf1 a mx include:_spf.hosting.example ~all"
"google-site-verification=AbC123..."

$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

$ dig +short CNAME shop.example.com
shops.platform.example.

Seguir todo el recorrido con +trace. dig hace entonces lo mismo que un resolver: primero la raíz, luego el TLD, luego el servidor autoritativo (lección 1.4):

$ dig +trace example.com A
.                 518400  IN  NS  a.root-servers.net.
;; Received 239 bytes from 192.168.1.1#53
com.              172800  IN  NS  a.gtld-servers.net.
;; Received 708 bytes from 198.41.0.4#53(a.root-servers.net)
example.com.      172800  IN  NS  ns1.hosting.example.
;; Received 412 bytes from 192.5.6.30#53(a.gtld-servers.net)
example.com.      3600    IN  A   192.0.2.10
;; Received 57 bytes from 198.51.100.53#53(ns1.hosting.example)

Con +trace ve qué servidores de nombres entrega realmente el registro de dominios (registry). Esto resulta útil si duda si ya se ha aplicado un cambio de servidor de nombres.

Ver DNSSEC con +dnssec: obtiene también las firmas RRSIG. Con +cd desactiva la validación para comprobar si un SERVFAIL viene de DNSSEC.

DNS inverso con -x (lección 4.6):

$ dig +short -x 192.0.2.25
mail.example.com.

Lo mismo con nslookup

nslookup funciona en cualquier ordenador. Las formas más importantes:

C:\> nslookup example.com
Server:  router.lan
Address:  192.168.1.1

Non-authoritative answer:
Name:    example.com
Address:  192.0.2.10

C:\> nslookup -type=mx example.com
example.com    MX preference = 10, mail exchanger = mail.example.com

C:\> nslookup -type=txt _dmarc.example.com 9.9.9.9

Una segunda dirección detrás del nombre (aquí 9.9.9.9) es el servidor que está consultando, igual que @ en dig. "Non-authoritative answer" significa solo que la respuesta procede de un resolver y no del servidor de nombres autoritativo: esto es normal. Si el nombre no existe, nslookup dice Non-existent domain, que es lo mismo que NXDOMAIN.

Windows PowerShell: Resolve-DnsName

PS> Resolve-DnsName example.com -Type MX
PS> Resolve-DnsName _dmarc.example.com -Type TXT -Server 9.9.9.9
PS> Resolve-DnsName example.com -Type A -DnsOnly

Vaciar su propia caché

¿Una herramienta en línea ya ve la respuesta nueva, pero su ordenador todavía no? Entonces la respuesta antigua está en la caché de su propio ordenador o navegador.

• Windows: ipconfig /flushdns en el símbolo del sistema.
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder en Terminal.
• Linux con systemd-resolved: resolvectl flush-caches.
• Navegador: una ventana privada, o su teléfono por 4G/5G con el wifi apagado.

La caché de su proveedor o router no la puede vaciar usted mismo; ahí tiene que esperar a que pase la TTL.

En la práctica: así se ve en un panel

En la mayoría de paneles no puede ejecutar dig. Por eso, use dig junto a su panel: primero mire en el panel qué ha introducido, luego compruebe con dig @<su servidor de nombres> si el servidor de nombres realmente entrega eso, y después con dig @9.9.9.9 si el mundo exterior ya lo ve. Mi WebOké dispone de un diagnóstico DNS que compara los servidores de nombres entre sí; otras entidades tienen botones de "comprobación DNS" similares.

Resumen

• dig <nombre> <tipo> hace la misma pregunta que un navegador o un servidor de correo; lea primero el estado.
• NOERROR con respuesta es correcto, NOERROR sin respuesta significa "el nombre existe, el tipo no", NXDOMAIN significa "el nombre no existe", SERVFAIL significa "sin respuesta fiable".
• Con @server consulta directamente un resolver determinado o el servidor de nombres autoritativo; así ve la diferencia entre un error y una caché.
• +short, +trace, +dnssec, +cd y -x son las variantes que más necesitará.
• nslookup y Resolve-DnsName hacen lo mismo en Windows.

Cuestionario

Ejercicio

Ejercicio Z8.2: dig y nslookup. Con dig, nslookup o Resolve-DnsName (o una herramienta dig en línea), consulte tres cosas:

1. el estado de un nombre que no existe: bestaat-niet-dnscursus.sidn.nl;
2. los registros MX de wikipedia.org, directamente en uno de los servidores de nombres de wikipedia.org (búsquelo primero);
3. la TTL que un resolver público devuelve en este momento para el registro A de sidn.nl (consúltelo dos veces, con un minuto de diferencia, y anote ambos números).

Introduzca las respuestas.

Para saber más

Estos artículos describen los pasos en WebOké; los comandos funcionan igual en todas partes.

• Manual de DirectAdmin 18.7: Mi dominio todavía no funciona tras una transferencia o modificación
• ¿Cuánto tarda un cambio de nameserver o DNS, y qué hacer si no lo ve?
• Enviar correo desde su VPS y configurar el DNS inverso