DNS: Deja de Adivinar, Lee la Respuesta

DNS no es una guía telefónica en la nube. Es una cadena de cachés preguntando a servidores autoritativos por registros tipados. Una vez que ves esa cadena, "el dominio está roto" se convierte en una lista corta de fallos comprobables.

🎙️ Publicado y grabado: ·

01La cadena de resolución

Tu navegador normalmente no pregunta al dueño de un dominio. Le pregunta al sistema operativo, que pregunta a un resolver recursivo. En un cache miss, ese resolver camina desde la raíz al dominio de nivel superior y luego al nameserver autoritativo del dominio. La respuesta autoritativa es la fuente de verdad; todo lo anterior es una caché o una señal.

browser → OS cache → recursive resolver
                       ↓ cache miss
                    root → .com → authoritative nameserver
                                      ↓
                               api.example.com. 300 IN A 203.0.113.10
La distinción útil
Si el servidor autoritativo tiene la respuesta correcta pero tu resolver normal tiene la antigua, sospecha de caché. Si el servidor autoritativo está equivocado, esperar no cambia nada. Corrige la zona.

02A y AAAA son direcciones, no alias

A apunta un nombre a una dirección IPv4. AAAA lo apunta a IPv6. Los navegadores pueden preferir IPv6, así que un registro AAAA obsoleto puede romper solo para algunos usuarios mientras cada test IPv4 se ve saludable. No publiques AAAA porque el panel de control ofreció un campo; publícalo solo cuando esa dirección sirva el sitio.

example.com.      300 IN A     203.0.113.10
example.com.      300 IN AAAA  2001:db8::10
api.example.com.  300 IN A     203.0.113.40

# inspect each family separately
dig example.com A +short
dig example.com AAAA +short
Una media-caída muy real
Los usuarios de teléfono dan timeout, los portátiles de oficina funcionan. El servidor antiguo sigue en AAAA. Elimina o corrige AAAA, verifica con dig AAAA, luego prueba sobre IPv6. Cambiar el registro A de nuevo es trabajo inútil.

03CNAME, y el incómodo apex

Un CNAME dice que un nombre es otro nombre. No copia una IP; los resolvers continúan y buscan el destino. Eso es excelente para www y subdominios de servicios. Es incómodo en el apex de la zona, el example.com desnudo, porque el apex también debe llevar registros SOA y NS, mientras que un CNAME conforme a estándares no puede coexistir con otros datos.

www.example.com. 300 IN CNAME sites.host.example.

Error: CNAME record is not allowed at the zone apex
# Fix: use the provider's ALIAS/ANAME or CNAME flattening feature,
# or use A/AAAA values supplied by the host. Do not delete apex NS/SOA.

ALIAS, ANAME y "flattening" son características del proveedor, no tipos de registro DNS ordinarios. Sintetizan respuestas de dirección en el apex. Esa distinción importa al mover proveedores DNS: la funcionalidad puede no moverse con el archivo de zona.

04TXT es prueba y política

Los registros TXT son cadenas de texto asociadas a nombres. Los sistemas de email los usan para SPF, DKIM y DMARC; los servicios los usan para probar propiedad del dominio. El hostname importa tanto como el valor. Un token de verificación colocado en el apex no satisfará a un verificador que pregunta por _acme-challenge.example.com.

example.com.                 IN TXT "v=spf1 include:_spf.mail.example ~all"
_acme-challenge.example.com. IN TXT "R4nd0m-proof-token"
selector1._domainkey.example.com. IN TXT "v=DKIM1; p=MIIB..."

# Query the exact owner name the service requested
dig TXT _acme-challenge.example.com +short
"Registro de verificación no encontrado"
Primero comprueba el nombre exacto con dig TXT. Los dashboards DNS suelen añadir la zona automáticamente, así que introducir el nombre completo puede crear _acme-challenge.example.com.example.com. Corrige el campo del propietario; no sigas regenerando tokens.

05TTL controla la reutilización, no la velocidad

TTL es cuántos segundos un resolver puede reutilizar una respuesta. Un TTL de 3600 significa "cachea esto hasta una hora". No promete que un registro nuevo aparezca en una hora. Si planeas una migración, baja el TTL antes del cambio y espera a que expire el TTL anterior. Bajarlo después del cambio no puede recuperar respuestas ya cacheadas.

# Answer includes TTL in the second column
$ dig example.com A +noall +answer
example.com.  2874  IN  A  203.0.113.10

# 2874 seconds remain in this resolver's cached copy
La caché negativa también existe
Un NXDOMAIN puede cachearse usando la configuración SOA de la zona. Crear el registro faltante inmediatamente puede dejar a un resolver diciendo que no existe. Compara ese resolver con el servidor autoritativo en vez de editar el registro cinco veces.

06"Esperar la propagación" suele ser un mal diagnóstico

DNS no se extiende como pintura mojada. Los servidores autoritativos publican datos; los resolvers recursivos cachean respuestas hasta que expira el TTL. Cuando alguien dice "espera 48 horas", pregunta qué resolver tiene qué respuesta y cuánto TTL le queda. Muy a menudo, esperar la propagación es el diagnóstico equivocado: el registro está en la zona incorrecta, la delegación apunta a otro sitio, o la respuesta autoritativa ya está mal.

# Ask public recursive resolvers
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

# Ask an authoritative server directly
dig @ns1.dns-host.example example.com A +noall +answer

# Trace delegation from the root
dig +trace example.com
Una prueba decisiva
Si cada servidor autoritativo devuelve la dirección antigua, no hay nada que propagar. Editaste un proveedor no autoritativo, guardaste la zona equivocada o no publicaste. Encuentra los nameservers con dig NS example.com y edita el proveedor que realmente nombran.

07NXDOMAIN significa que el nombre no existe

NXDOMAIN es más fuerte que "no hay registro A". Dice que el nombre consultado no existe en DNS. Un nombre existente sin registro del tipo solicitado es una respuesta diferente: NOERROR con respuesta vacía. Esa distinción atrapa typos, sufijos dobles accidentales y subdominios faltantes.

$ dig api.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41822

# Diagnose
dig example.com NS +short                 # correct delegation?
dig @ns1.dns-host.example api.example.com A # source of truth?
dig api.example.com A +trace              # where does it fail?
Corrige el nombre, no el navegador
Comprueba la ortografía y el comportamiento de auto-sufijo del editor de zona. Confirma que el registro existe en cada nameserver autoritativo. Si las respuestas autoritativas ya son correctas, solo entonces una respuesta negativa cacheada es razón para esperar a que expire su TTL.

08SERVFAIL significa que DNS no pudo completar la consulta

SERVFAIL no es "el servidor no devolvió sitio web". Un resolver o servidor autoritativo no pudo producir una respuesta DNS utilizable. Causas comunes son DNSSEC roto tras un cambio de proveedor, nameservers autoritativos inalcanzables, timeouts, una delegación defectuosa o un bucle de CNAME. DNSSEC es lo primero que reviso después de cambiar nameservers, pero no es el único significado de SERVFAIL.

$ dig example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9351

# If normal validation fails but this returns an answer, suspect DNSSEC
dig +cdflag example.com A

# Inspect delegation and authoritative reachability
dig +trace example.com
dig @ns1.dns-host.example example.com SOA
Fallo clásico de migración
Moviste los DNS pero dejaste el registro DS antiguo en el registrar. Los validadores no pueden hacer coincidir las firmas de la nueva zona y devuelven SERVFAIL. Publica los datos DS correctos del nuevo proveedor, o elimina DS antes de una migración deliberadamente sin firma. No desactives la validación en los clientes como "solución".

09dig y nslookup: haz preguntas precisas

dig expone status, flags, TTL, respuesta, autoridad y servidor que responde. nslookup está instalado en la mayoría de máquinas Windows y sirve para verificaciones directas de registros. Siempre nombra el tipo de registro y, al comparar comportamientos, nombra el resolver.

# dig
dig example.com A
dig example.com MX +short
dig @1.1.1.1 example.com AAAA
dig +trace example.com

# Windows-friendly nslookup
nslookup -type=TXT example.com 1.1.1.1

;; communications error to 10.0.0.53#53: timed out
;; no servers could be reached
# This is not NXDOMAIN. The configured resolver is unreachable.
# Check VPN/firewall/network DNS, then compare: dig @1.1.1.1 example.com.
Lee la línea SERVER
nslookup puede decir *** UnKnown can't find api.example.com: Non-existent domain. "UnKnown" suele significar que la IP del resolver no tiene DNS inverso; no es el fallo. "Non-existent domain" es NXDOMAIN. Prueba el servidor autoritativo para decidir si el nombre falta o simplemente está en caché negativa.

10El playbook de depuración DNS

Empieza en la fuente de verdad, luego muévete hacia el usuario. Este orden evita que el folklore de caché te haga perder una tarde.

1. dig NS example.com             # who is authoritative?
2. dig @authoritative name TYPE   # what is the source saying?
3. dig @1.1.1.1 name TYPE         # what is a recursive cache saying?
4. compare status, answer and TTL # NXDOMAIN? SERVFAIL? stale value?
5. dig +trace name                # only when delegation is suspicious

Authoritative wrong → edit the actual authoritative zone.
Authoritative right, recursive old → wait only for the shown TTL.
SERVFAIL → inspect DNSSEC, delegation, reachability, loops.
Timeout → resolver/network path, not "propagation."

Mi regla directa: nunca cambies un registro DNS hasta que puedas decir qué servidor dio la respuesta incorrecta. DNS es observable. Adivinar es opcional.

Tell me what missed

A correction is more useful than a compliment. This goes straight to the person who writes SwiftGrasp.

Was this page useful?
0/1000

Please do not include passwords, private keys, or personal information.