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: ·
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
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
dig AAAA, luego prueba sobre IPv6. Cambiar el registro A de nuevo es trabajo inútil.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.
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
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.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
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
dig NS example.com y edita el proveedor que realmente nombran.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?
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
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.
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.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.