Suena el teléfono: «se cayó internet». Llegas (o te conectas) y, por supuesto, internet está impecable: lo que no carga es el sistema de facturación. Después de suficientes visitas a terreno uno aprende que casi todos los «se cayó internet» son una de cuatro cosas: el nombre no resuelve, la máquina no responde, el puerto está bloqueado, o el problema es de otro — el hosting, el ISP, el dominio que alguien olvidó renovar. La buena noticia: las cuatro se comprueban en minutos, en orden, y con evidencia que puedes pegar en un ticket. Esta guía es ese orden.
Las cuatro preguntas del detective
Antes de reiniciar nada «por si acaso», hazte las preguntas en secuencia. Cada una descarta una capa completa del problema, y cada «no» apunta a un culpable distinto:
- ¿Resuelve el nombre? Si el dominio no se traduce a una IP, todo lo demás da igual. Herramienta:
digo la consulta DNS. - ¿Responde la IP? El nombre puede resolver perfecto hacia una máquina apagada. Herramienta:
ping. - ¿Está abierto el puerto? La máquina puede estar viva pero con el servicio caído o un firewall de por medio. Herramienta: el probador de puertos.
- ¿Quién es el dueño y por dónde va el camino? Si todo lo tuyo está bien, necesitas saber a quién llamar. Herramienta: WHOIS / RDAP y
traceroute.
El orden no es capricho: si el nombre no resuelve, probar el puerto es perder el tiempo; y si la IP responde pero el puerto calla, ya sabes que el cable no es el problema. Diagnóstico es descartar capas, no adivinar.
El caso completo: de «no carga» a ticket con evidencia
Corramos el flujo con un caso típico: la sucursal reporta que facturas.ejemplo.cl «no abre», y el resto de internet funciona. Cronómetro en mano:
- ¿Resuelve?
dig +short A facturas.ejemplo.cldevuelve 203.0.113.80. La respuesta trae TTL 287 de los 300 originales: el resolutivo la cacheó hace 13 segundos, o sea otro cliente acaba de preguntar lo mismo. El nombre está sano. Siguiente. - ¿Responde la IP?
ping -c 4 203.0.113.80: 4 enviados, 4 recibidos, 0% de pérdida, rtt promedio 45,2 ms. La máquina vive y la ruta funciona. (Si el ping callara, atención: no es concluyente — muchos firewalls descartan ICMP a propósito. Pasa igual al paso 3.) - ¿Puerto abierto? Prueba TCP al 443 con el probador de puertos: el SYN se va y en 3 segundos… nada. Estado: filtrado. Eso no es un servicio caído — un servicio caído contesta de inmediato con un RST («cerrado»). El silencio total es la firma de un firewall descartando paquetes.
- ¿Quién es el dueño? RDAP de 203.0.113.80: AS64500, «Hosting Ejemplo SpA». Es el proveedor correcto — nadie secuestró la IP ni venció el dominio. El problema está en la puerta de ellos.
- El ticket. Sacas tu IP pública desde Mi IP (198.51.100.22) y escribes: «el DNS resuelve a 203.0.113.80, la IP responde ping en 45 ms, pero el TCP 443 aparece filtrado desde nuestra IP 198.51.100.22 desde las 09:40». Cuatro comandos, unos tres minutos, y el proveedor no puede contestarte «reinicie el router».
$ dig +short A facturas.ejemplo.cl 203.0.113.80 $ ping -c 4 203.0.113.80 4 packets transmitted, 4 received, 0% packet loss rtt min/avg/max = 43.8/45.2/47.1 ms $ nc -zv -w 3 203.0.113.80 443 nc: connect to 203.0.113.80 port 443 (tcp) timed out
El viaje de una consulta DNS
Para diagnosticar DNS con criterio hay que saber quién le pregunta a quién. Es como ubicar a una persona en una ciudad que no conoces: tú le preguntas al conserje del edificio; el conserje no sabe, pero sabe a quién preguntarle — y cuando averigua la respuesta, la anota para el próximo que pregunte.
- El stub es tu equipo: solo sabe delegar la pregunta completa a su resolutivo configurado.
- El resolutivo (el del ISP, o 1.1.1.1, o 8.8.8.8) es el conserje: hace el trabajo sucio y cachea cada respuesta.
- Los servidores raíz — 13 identidades, de
aam.root-servers.net, replicadas en cientos de instancias anycast por el mundo — solo saben una cosa: quién administra cada terminación. «¿.cl? Pregúntale a NIC Chile.» - El TLD (.cl, .com) tampoco sabe tu IP: sabe qué servidores mandan en
ejemplo.cl. - El autoritativo es el dueño de casa: tiene la zona con los registros de verdad y responde con autoridad.
Aquí está la clave que arruina el mito favorito del rubro: cada respuesta viaja con una fecha de vencimiento — el TTL, en segundos. Mientras no expire, el resolutivo contesta desde su caché sin preguntarle a nadie. Por eso la famosa «propagación DNS» no existe: no hay ningún proceso empujando tu registro nuevo por el mundo. Lo que hay son miles de cachés que guardaron el valor viejo y lo van soltando cada una cuando su TTL expira. «Esperar la propagación» es, literalmente, esperar que venzan los yogures.
Los registros que vas a usar
La zona DNS es una tabla de hechos con tipos. Estos seis cubren el 95% del trabajo de un integrador — puedes consultarlos todos desde la herramienta de consulta DNS:
| Registro | Qué responde | Ejemplo | Ojo con |
|---|---|---|---|
| A | nombre → IPv4 | facturas → 203.0.113.80 | un TTL alto amarra tus migraciones |
| AAAA | nombre → IPv6 | facturas → 2001:db8::50 | si existe, los clientes suelen preferirlo: pruébalo también |
| CNAME | alias hacia otro nombre | www → ejemplo.cl | no va en el apex ni convive con otros registros |
| MX | quién recibe el correo | 10 mail.ejemplo.cl | gana la prioridad más baja; debe apuntar a un A, no a CNAME ni IP |
| TXT | texto: SPF, verificaciones | v=spf1 … | puede haber varios TXT, pero solo un SPF |
| NS | qué servidores mandan en la zona | ns1.hosting.cl | deben coincidir con la delegación del TLD |
| PTR | el inverso: IP → nombre | 80.113.0.203.in-addr.arpa | lo administra el dueño de la IP (tu ISP), no tu zona; clave para correo |
El PTR merece una frase más: vive en una zona espejo (in-addr.arpa para IPv4, ip6.arpa para IPv6) donde la IP se escribe con los octetos al revés — 203.0.113.80 se busca como 80.113.0.203.in-addr.arpa. Si necesitas armar esos nombres sin dolor, la herramienta de zona PTR inversa los genera desde la IP o el CIDR.
ejemplo.cl a secas) rompe la zona: el estándar exige que un CNAME sea el único registro de ese nombre, y el apex ya tiene NS y SOA obligatorios. Por eso los proveedores inventaron ALIAS/ANAME o «CNAME flattening». Si tu panel te dejó guardarlo igual, no es que funcione: es que el panel no te quiere.
Cuando dos resolvedores no se ponen de acuerdo
Ayer migraste facturas.ejemplo.cl a un servidor nuevo, y hoy la mitad de los usuarios llega al viejo. ¿Magia negra? No: cachés. Pregúntale lo mismo a dos resolvedores distintos y compara:
$ dig A facturas.ejemplo.cl @1.1.1.1 +noall +answer facturas.ejemplo.cl. 287 IN A 203.0.113.80 $ dig A facturas.ejemplo.cl @8.8.8.8 +noall +answer facturas.ejemplo.cl. 5100 IN A 198.51.100.7
Cloudflare (1.1.1.1) ya tiene la IP nueva. Google (8.8.8.8) sigue sirviendo la vieja — y el número del medio te dice exactamente cuánto falta: 5100 segundos, 85 minutos de caché restante. No está «lento en propagar»: cacheó el registro antes del cambio, con el TTL viejo, y lo va a soltar cuando expire. Ni un segundo antes. La herramienta de propagación DNS hace esta comparación contra varios resolvedores públicos de una vez, que es la forma civilizada de responder «¿ya propagó?»: no, le quedan 85 minutos al yogurt de Google.
Correo que llega: SPF, DKIM y DMARC
La mitad del diagnóstico DNS moderno es correo que cae en spam. El correo electrónico nació sin autenticación — cualquiera puede escribir «De: gerencia@ejemplo.cl» en un sobre — así que se le añadieron tres capas, todas publicadas como registros TXT en tu zona:
- SPF es la lista de invitados: qué servidores pueden enviar correo a nombre del dominio.
v=spf1 include:_spf.proveedor.com -allsignifica «estos sí, todo el resto no». - DKIM es la firma notarial: el servidor emisor firma criptográficamente cada mensaje y publica la clave pública en
selector._domainkey.ejemplo.cl. A diferencia de SPF, la firma sobrevive reenvíos, porque viaja con el mensaje. - DMARC es la política: le dice al receptor qué hacer con lo que no pase SPF ni DKIM alineados con el dominio visible — y a qué casilla mandarte reportes (
rua) de quién está enviando en tu nombre.
DMARC se adopta como escalera, no como interruptor:
Empieza en p=none y lee los reportes dos a cuatro semanas: ahí aparecen el CRM, la impresora multifuncional y ese sistema legado que nadie recordaba que enviaba correo. Cuando todos los emisores legítimos pasan SPF o DKIM, subes a quarantine (con pct=25 aplica a 1 de cada 4 correos, para frenar despacio) y al final reject. La herramienta de SPF/DKIM/DMARC consulta y explica los tres registros de un dominio de una pasada. Y no olvides el PTR del paso anterior: muchos servidores rechazan de plano el correo de una IP sin inverso coherente.
include: cuenta, incluyendo los que vienen anidados dentro de los de tu proveedor. Pasarte produce permerror, y muchos receptores lo tratan como SPF inválido: tu correo legítimo empieza a caer en spam justo después de «agregar un servicio más». Cuenta los lookups antes de sumar el include número seis.
Puertos: abierto, cerrado o filtrado
El último eslabón del flujo merece su propia sección, porque los tres estados de un puerto cuentan tres historias distintas. Imagínate tocando una puerta:
- Abierto: te abren. El SYN recibió su SYN/ACK — hay un servicio escuchando y el firewall deja pasar. Si la aplicación igual falla, el problema está más arriba (TLS, credenciales, la aplicación misma).
- Cerrado: alguien grita «¡no hay nadie!». Llegó un RST inmediato — la red y el firewall funcionan, pero ningún servicio escucha en ese puerto. Servicio caído o puerto equivocado. En términos de firewall: comportamiento REJECT.
- Filtrado: silencio absoluto. El paquete murió en el camino sin respuesta — la firma de un firewall en modo DROP. Para el diagnóstico es oro: te dice que hay una regla de por medio, y que el ticket va al dueño del firewall, no al del servidor.
Un detalle que ahorra confusiones: el probador de puertos mira tu host desde internet. Un puerto puede estar abierto en la LAN y filtrado desde afuera (NAT o firewall perimetral), y eso no es un error: es exactamente la diferencia que quieres medir. Por lo mismo, cuando reportes un bloqueo por origen, incluye tu IP pública — Mi IP te la da con ASN y organización incluidos.
La próxima vez que griten «se cayó internet», respira y corre las cuatro preguntas: nombre, IP, puerto, dueño. Diez minutos y cuatro pestañas — DNS, ping, puertos y RDAP — te dejan con un diagnóstico defendible en vez de un «parece que es el proveedor». Y si el problema es correo, misma receta con SPF/DKIM/DMARC: primero evidencia, después política.