Un servidor DNS es la pieza que traduce el nombre que usted escribe —kharonte.com, outlook.office.com, el nombre de su ERP— a la dirección numérica donde vive realmente ese servicio. Es el sistema más discreto de internet y también el más implacable: cuando falla, el correo deja de llegar, la página no abre y el error que ve el usuario no menciona jamás la palabra DNS. Esta guía explica qué es, cómo resuelve un nombre, qué registros existen, cómo se cambia en cada equipo y cómo se diagnostica cuando algo deja de responder.
Está escrita en dos niveles de lectura. Si usted no es de sistemas, encontrará en lenguaje llano por qué su correo depende de cuatro líneas de texto que nadie mira nunca y qué preguntas conviene hacer antes de mover un dominio. Si usted administra la infraestructura, encontrará la tabla de registros completa, el detalle de SPF, DKIM y DMARC, los comandos de diagnóstico en Windows, macOS y Linux, y los errores de configuración que tumban un servicio en producción.
Qué es un servidor DNS y qué problema resuelve
Las máquinas de una red no se localizan por nombre, sino por número. Toda conexión termina siendo una dirección IP: cuatro cifras separadas por puntos en IPv4, como 190.85.24.10, o una cadena hexadecimal mucho más larga en IPv6. Las personas, en cambio, recordamos nombres. El sistema de nombres de dominio, DNS por sus siglas en inglés, existe para salvar esa distancia.
La comparación de la agenda telefónica se repite mucho y se queda corta. Una agenda es una lista fija que usted consulta; el DNS es una base de datos distribuida por todo el planeta, sin ningún punto que la contenga entera, en la que cada organización publica y modifica su propio trozo. Nadie tiene la lista completa. Lo que hay es un sistema de delegaciones encadenadas que permite averiguar cualquier nombre preguntando a quien manda sobre él.
Ese diseño quedó fijado en 1987 en dos documentos que siguen vigentes, el RFC 1035 y su compañero, el RFC 1034. Casi cuarenta años después, el protocolo sigue funcionando con el mismo puerto —el 53, sobre UDP para las consultas normales y sobre TCP cuando la respuesta es grande— y con la misma idea de jerarquía. Pocas tecnologías de esa edad soportan hoy el tráfico que soporta esta.
Conviene retener una consecuencia práctica desde el principio: el DNS no es solo «para que abran las páginas web». También decide a dónde va el correo de su empresa, qué servidores tienen permiso para enviarlo en su nombre, dónde se valida una licencia, a qué máquina se conecta el punto de venta y qué demuestra que un dominio es suyo. Por eso una línea mal escrita en la zona no produce un fallo pequeño: produce un servicio caído.
Cómo funciona la resolución de un nombre, paso a paso
Cuando usted escribe una dirección en el navegador, antes de que viaje un solo byte de la página ocurre una conversación de milisegundos. Esta es la cadena completa, en el peor de los casos: cuando nadie tiene la respuesta guardada.
| Paso | Quién pregunta | A quién | Qué obtiene |
|---|---|---|---|
| 1 | La aplicación | Al sistema operativo | Consulta su caché local y el archivo hosts. Si está, termina aquí |
| 2 | El sistema operativo | Al resolvedor configurado | Envía la pregunta al servidor DNS que tiene puesto, normalmente el del router o el del proveedor |
| 3 | El resolvedor | A un servidor raíz | No sabe la respuesta, pero sabe quién manda sobre .com |
| 4 | El resolvedor | Al servidor del dominio de primer nivel | Tampoco la sabe, pero indica qué servidores son los autoritativos del dominio |
| 5 | El resolvedor | Al servidor autoritativo | La respuesta real: la dirección IP del nombre consultado |
| 6 | El resolvedor | Al sistema operativo | Devuelve el dato y lo guarda en caché durante el tiempo que marque el TTL |
La primera vez esa cadena puede costar entre 50 y 300 milisegundos. La segunda, y durante todo el tiempo que dure la caché, cuesta prácticamente cero. Esa diferencia explica por qué un sitio «va lento solo al principio» y por qué, cuando un servidor DNS empieza a responder tarde, la sensación del usuario no es que el DNS falle, sino que «internet está lento».
Hay un matiz que se pasa por alto y que da problemas reales: los pasos 3, 4 y 5 los hace el resolvedor, no su computador. Su equipo hace una sola pregunta y espera una sola respuesta. Por eso, cuando alguien cambia el servidor DNS de un portátil para «arreglar internet», no está tocando el sistema de nombres del mundo, sino eligiendo a qué intermediario le pregunta.
Los cuatro papeles que puede tener un servidor DNS
«Servidor DNS» se usa como si designara una sola cosa, y en realidad designa cuatro funciones muy distintas. Distinguirlas evita la mayor parte de las confusiones al diagnosticar.
| Papel | Qué hace | Ejemplo típico | Quién lo administra |
|---|---|---|---|
| Recursivo o resolvedor | Recibe la pregunta del usuario y recorre la cadena hasta encontrar la respuesta. Guarda en caché | El 1.1.1.1, el 8.8.8.8, el del proveedor de internet, el del router de la oficina | El proveedor, el área de TI o un servicio público |
| Raíz | La cúspide de la jerarquía. No conoce ningún dominio concreto: solo indica quién manda sobre cada extensión | Las trece identidades de la A a la M | Doce organizaciones internacionales |
| De dominio de primer nivel | Manda sobre una extensión completa y delega en los servidores de cada dominio | Los de .com, .co, .org, .gov.co | El registro de cada extensión |
| Autoritativo | Contiene la verdad sobre un dominio concreto: sus registros reales | Los que el registrador o el proveedor de DNS asigna a su dominio | Su empresa, su proveedor de DNS o su área de TI |
Por qué los trece servidores DNS raíz no son trece máquinas
Un apunte sobre la raíz, porque circula mal contado: esas trece identidades no son trece máquinas. Gracias al enrutamiento anycast, la misma dirección responde desde centenares de instancias repartidas por el mundo, de modo que su consulta llega siempre a la copia más cercana. La cifra trece es una herencia técnica del tamaño máximo que cabía en una respuesta UDP de los años ochenta, no un límite de capacidad.
La distinción que más ahorra tiempo en soporte es la que separa al recursivo del autoritativo. Si el problema afecta solo a un equipo o a una oficina, mire el recursivo. Si afecta a todo el mundo desde cualquier red, mire el autoritativo: el error está en su zona.
La caché y el TTL: por qué su cambio «todavía no se ve»
Cada respuesta del DNS viaja con un número que indica cuántos segundos puede guardarse antes de volver a preguntar. Ese número es el TTL, del inglés time to live, tiempo de vida. Es el parámetro que más disgustos provoca y el que menos gente ajusta.
El efecto es sencillo de enunciar y difícil de aceptar cuando uno tiene prisa: si un registro tiene un TTL de 24 horas y usted lo cambia, hay resolvedores en el mundo que seguirán devolviendo el valor viejo hasta 24 horas después. No es un error ni una demora del registrador; es el sistema haciendo exactamente lo que se le pidió. A eso se le llama, con poca fortuna, «propagación».
| Situación | TTL recomendado | Motivo |
|---|---|---|
| Registro estable, sin cambios previstos | 3600 a 86400 s (1 a 24 h) | Menos consultas, menos latencia y menos carga sobre el servidor autoritativo |
| Días antes de una migración planificada | 300 s (5 min) | Se baja antes del cambio, nunca durante. Bajarlo el mismo día no sirve de nada |
| Durante la migración y las 24 h siguientes | 300 s | Permite revertir en minutos si algo sale mal |
| Una vez estabilizado | Volver a 3600 s o más | Un TTL bajo permanente multiplica las consultas y hace al servicio más frágil ante un corte |
La regla operativa que conviene interiorizar: el TTL se baja con antelación, no en el momento del cambio. Si el registro tenía 24 horas y usted lo baja a 5 minutos justo antes de migrar, los resolvedores que ya guardaron el valor viejo con 24 horas de vigencia no se enterarán de la rebaja hasta que caduque. Bajarlo 48 horas antes es lo que realmente acorta la ventana.
La caché negativa del DNS, la que nadie recuerda
Hay una segunda caché que la gente olvida: la negativa. Cuando un nombre no existe, esa ausencia también se guarda, y el tiempo lo fija un campo del registro SOA de la zona. Por eso a veces se crea un registro nuevo, se verifica que está bien publicado y aun así un equipo concreto insiste en que no existe.
Registros DNS: la tabla de referencia
Los diez registros DNS que se usan en una empresa
Una zona DNS es, por dentro, una lista de líneas. Cada línea es un registro con un tipo, y el tipo determina qué significa. Esta es la referencia de los que se usan en una empresa; el resto son casos de especialista.
| Tipo | Para qué sirve | Ejemplo de valor | Cuidado con |
|---|---|---|---|
| A | Apunta un nombre a una dirección IPv4 | 190.85.24.10 | Es el registro que se olvida actualizar al cambiar de servidor |
| AAAA | Lo mismo, pero a una dirección IPv6 | 2803:a4c0::10 | Si publica uno y el servicio no responde por IPv6, se generan esperas y fallos intermitentes |
| CNAME | Declara que un nombre es alias de otro nombre | www apunta a kharonte.com | No puede convivir con otros registros en el mismo nombre ni usarse en la raíz del dominio |
| MX | Indica qué servidores reciben el correo del dominio | 10 dominio.mail.protection.outlook.com | El número es la prioridad: gana el más bajo, no el más alto |
| TXT | Texto libre. Es donde viven SPF, DKIM, DMARC y las verificaciones de propiedad | v=spf1 include:spf.protection.outlook.com -all | Solo puede existir un registro SPF por dominio, aunque haya varios TXT |
| NS | Declara qué servidores son autoritativos para la zona | ns1.proveedor.com | Si no coincide con lo registrado en el registrador, los cambios no surten efecto |
| SOA | Datos de control de la zona: servidor principal, serie y tiempos de caché negativa | Una sola línea por zona | El número de serie debe subir en cada cambio o las réplicas no se actualizan |
| SRV | Publica en qué máquina y puerto vive un servicio concreto | _sip._tls, usado por telefonía y por clientes corporativos | Su sintaxis lleva prioridad, peso, puerto y destino, en ese orden |
| PTR | La consulta inversa: de dirección IP a nombre | Se configura en la zona inversa, casi siempre del proveedor | Su ausencia hace que muchos servidores de correo rechacen los envíos |
| CAA | Declara qué autoridades pueden emitir certificados para el dominio | 0 issue "letsencrypt.org" | Si está mal puesto, la renovación del certificado falla sin aviso previo |
Cómo se lee una línea de una zona DNS
Los paneles de los proveedores presentan los registros en formularios, pero por debajo el formato es siempre el mismo y conviene saber leerlo, porque es el que devuelven las herramientas de diagnóstico:
; nombre TTL clase tipo valor
www.ejemplo.com. 3600 IN A 190.85.24.10
ejemplo.com. 3600 IN MX 10 ejemplo-com.mail.protection.outlook.com.
ejemplo.com. 3600 IN TXT "v=spf1 include:spf.protection.outlook.com -all"
ejemplo.com. 86400 IN NS ns1.proveedor.com.Ese punto final detrás de ejemplo.com. no es una errata. Indica que el nombre está completo desde la raíz. Sin él, muchos servidores añaden el dominio de la zona al final y convierten ejemplo.com en ejemplo.com.ejemplo.com, un clásico que produce fallos desconcertantes. En los paneles web esa parte suele estar oculta, pero al editar archivos de zona a mano importa.
A, CNAME y la raíz del dominio: el error más repetido
Hay una regla del protocolo que no admite excepciones y que casi todo el mundo intenta saltarse al menos una vez: en la raíz del dominio no puede haber un CNAME. Es decir, www.ejemplo.com sí puede ser alias de otro nombre, pero ejemplo.com a secas, no.
El motivo es que la raíz obligatoriamente tiene registros SOA y NS, y un CNAME no puede coexistir con ningún otro registro en el mismo nombre. Si el panel se lo permite, o bien no es un CNAME de verdad, o bien está a punto de romper el correo del dominio: la consulta del MX seguirá al alias y dejará de encontrar a los servidores de correo.
La solución que ofrecen los proveedores modernos se llama ALIAS, ANAME o CNAME flattening según la marca. Por fuera se comporta como un alias; por dentro, el servidor autoritativo resuelve el destino y publica un registro A normal. Es la forma correcta de apuntar la raíz de un dominio a un servicio que solo da nombres y no direcciones fijas.
El correo vive en el DNS: MX, SPF, DKIM y DMARC
Si hay un apartado de esta guía que conviene leer aunque no se sea de sistemas, es este. La entregabilidad del correo corporativo —que sus mensajes lleguen a la bandeja de entrada y no a la carpeta de no deseado— depende hoy de tres registros de texto que casi nadie revisa hasta que algo falla.
| Registro | Qué responde | Norma | Si falta |
|---|---|---|---|
| MX | «¿A qué servidor entrego el correo dirigido a este dominio?» | RFC 5321 | El dominio no recibe correo |
| SPF | «¿Qué servidores tienen permiso para enviar en nombre de este dominio?» | RFC 7208 | Cualquiera puede suplantar el dominio con más facilidad y los envíos propios acaban en no deseado |
| DKIM | «¿Este mensaje salió realmente de ahí y llegó sin alterarse?» | RFC 6376 | El mensaje pierde la firma criptográfica que demuestra su origen |
| DMARC | «¿Qué hago con los mensajes que no pasan las comprobaciones anteriores?» | RFC 7489 | Nadie informa de los intentos de suplantación y cada destinatario decide por su cuenta |
Así se ven los tres en una zona real de un dominio cuyo correo está en Microsoft 365:
; SPF: quien puede enviar
ejemplo.com. TXT "v=spf1 include:spf.protection.outlook.com -all"
; DKIM: dos alias que publican las claves de firma
selector1._domainkey CNAME selector1-ejemplo-com._domainkey.ejemplo.onmicrosoft.com.
selector2._domainkey CNAME selector2-ejemplo-com._domainkey.ejemplo.onmicrosoft.com.
; DMARC: que hacer con lo que no pasa, y a donde mandar los informes
_dmarc.ejemplo.com. TXT "v=DMARC1; p=none; rua=mailto:informes@ejemplo.com"Tres advertencias sobre el SPF que salen de incidentes reales
Tres advertencias que salen de incidentes reales y no de la teoría. La primera: el final del SPF importa mucho. -all significa «rechace lo que no esté en la lista» y ~all significa «acéptelo pero márquelo como sospechoso». Poner -all sin haber inventariado antes todo lo que envía correo en nombre del dominio —la facturación, el ERP, la herramienta de mercadeo, la impresora que manda escaneos— deja mensajes legítimos por el camino.
La segunda: solo puede existir un registro SPF por dominio. Publicar dos hace que la comprobación falle por norma, aunque cada uno por separado sea correcto. Cuando entra un servicio nuevo, su include se añade al SPF existente; no se crea otro.
La tercera es un límite técnico que sorprende: la evaluación de un SPF no puede provocar más de diez consultas DNS. Cada include cuenta, y los include anidados de los grandes proveedores gastan varios de golpe. Al superar diez, el resultado es un error permanente y el efecto práctico es el mismo que no tener SPF. Las herramientas de comprobación de SPF muestran ese contador; conviene mirarlo cada vez que se añade un remitente.
Cómo endurecer DMARC sin dejar sin correo a nadie
Sobre DMARC, la recomendación sensata es empezar por p=none, que no bloquea nada y solo pide informes, leer esos informes durante unas semanas para descubrir quién envía de verdad en nombre del dominio, y solo entonces endurecer a p=quarantine y más tarde a p=reject. Saltarse ese recorrido es la forma más rápida de dejar sin correo a un área entera. Si el correo de su organización está en Microsoft 365, la documentación oficial de Microsoft sobre la incorporación de dominios detalla los valores exactos que hay que publicar, que cambian según el inquilino.
DNS interno y DNS público: por qué una empresa necesita los dos
En una casa basta con el resolvedor del proveedor. En una oficina con dominio, servidores propios, impresoras y carpetas compartidas, hace falta algo más: un servidor DNS interno que conozca los nombres que no existen fuera.
| Aspecto | DNS interno | DNS público |
|---|---|---|
| Qué nombres conoce | Los de la red corporativa: servidores, equipos, servicios internos | Los publicados en internet |
| Quién lo consulta | Solo los equipos de la red interna o conectados por VPN | Cualquiera, desde cualquier sitio |
| Dónde suele vivir | El controlador de dominio, el firewall o un servidor con BIND | El proveedor de DNS, el registrador o un servicio gestionado |
| Qué pasa si se cae | La red interna deja de funcionar aunque haya internet: no se encuentran servidores ni recursos compartidos | El dominio desaparece de internet para el mundo |
| Cuántos hacen falta | Dos como mínimo, en máquinas distintas | Dos o más, y a ser posible de infraestructuras separadas |
El error de diseño más frecuente en pequeñas y medianas empresas es tener un único servidor DNS interno, casi siempre el mismo controlador de dominio que además hace de servidor de archivos. El día que esa máquina se reinicia por una actualización, la oficina entera se queda sin nombres: los usuarios no ven las carpetas, el ERP no encuentra su base de datos y el sistema de tiquetes se llena. Duplicar el servicio en una segunda máquina cuesta poco y evita un tipo de caída completo.
El segundo error, más sutil, es el split-brain mal resuelto: publicar el mismo nombre dentro y fuera con valores distintos y olvidarse de uno de los dos. El síntoma es inconfundible y desconcierta a cualquiera: el servicio funciona en la oficina y no funciona desde casa, o al revés. Si lo ve, compare la respuesta del servidor DNS interno con la del público antes de tocar nada más.
Este diseño es parte del trabajo de una red corporativa bien montada, junto con el direccionamiento, la segmentación y el cableado. Si le interesa el panorama completo, la guía sobre qué es una red de área local y cómo se administra cubre las piezas sobre las que se apoya todo lo que aquí se describe.
Qué servidor DNS público elegir
«Servidor DNS preferido» y «alternativo» son las dos casillas que pide cualquier sistema operativo, y la duda sobre qué poner en ellas es una de las consultas más habituales. Estas son las opciones abiertas más usadas, con lo que cada una aporta de verdad.
| Servicio | Preferido | Alternativo | Qué lo distingue |
|---|---|---|---|
| Cloudflare | 1.1.1.1 | 1.0.0.1 | Orientado a latencia baja; no filtra contenido. Tiene variantes con filtrado en otras direcciones |
| Google Public DNS | 8.8.8.8 | 8.8.4.4 | El más conocido y el más usado como prueba de diagnóstico. No filtra |
| Quad9 | 9.9.9.9 | 149.112.112.112 | Bloquea por lista los dominios asociados a actividad maliciosa conocida |
| OpenDNS | 208.67.222.222 | 208.67.220.220 | Permite aplicar categorías de filtrado sobre el tráfico de una red |
Lo que cambiar de servidor DNS no arregla
Conviene desinflar una creencia muy extendida: cambiar el servidor DNS no aumenta la velocidad de su conexión. No toca el ancho de banda ni la descarga. Lo que puede mejorar es el tiempo de la primera consulta de cada nombre, que se mide en decenas de milisegundos y solo se nota en navegación con muchos dominios distintos. Si su internet va lento descargando archivos, el DNS no es la causa.
Lo que sí cambia, y bastante, es el diagnóstico. Poner temporalmente un resolvedor público en un equipo es la forma más rápida de saber si un problema está en el resolvedor de la red o en la zona del dominio. Si con 1.1.1.1 funciona y con el del router no, el problema es del router o del proveedor.
Y una advertencia para entornos corporativos que se olvida siempre: en un equipo unido a un dominio de Windows no se ponen resolvedores públicos. Ese equipo necesita preguntar al servidor DNS interno para encontrar al controlador de dominio; si se le cambia por el 8.8.8.8, el inicio de sesión, las políticas de grupo y los recursos compartidos dejan de funcionar. El resolvedor público se configura, si acaso, como reenviador en el propio servidor interno.
Cómo cambiar el servidor DNS en cada sistema
Windows 11 y Windows 10
Por la interfaz: Configuración → Red e Internet → la conexión activa → Asignación de servidor DNS → Editar → Manual, activar IPv4 y escribir el preferido y el alternativo. Por consola, con permisos de administrador, es más rápido y deja constancia de lo que se hizo:
:: Ver la configuracion actual
ipconfig /all
:: Fijar los servidores en la interfaz llamada "Ethernet"
netsh interface ip set dns name="Ethernet" static 1.1.1.1 primary
netsh interface ip add dns name="Ethernet" 1.0.0.1 index=2
:: Volver a lo que entregue el router por DHCP
netsh interface ip set dns name="Ethernet" dhcpEn PowerShell el equivalente es más legible y funciona igual de bien en servidores:
Get-DnsClientServerAddress
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 1.1.1.1,1.0.0.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ResetServerAddressesmacOS
Ajustes del Sistema → Red → la conexión activa → Detalles → DNS → botón + para añadir cada dirección. Desde la terminal:
networksetup -listallnetworkservices
networksetup -getdnsservers "Wi-Fi"
sudo networksetup -setdnsservers "Wi-Fi" 1.1.1.1 1.0.0.1
sudo networksetup -setdnsservers "Wi-Fi" emptyAndroid, iOS y iPadOS
En Android, los ajustes de cada red Wi-Fi permiten pasar la configuración de IP a Estática y escribir los servidores; además, en Red e Internet existe DNS privado, que aplica a todas las conexiones, también a los datos móviles, mediante un nombre de servidor en lugar de una dirección. Quien use iOS o iPadOS entra por Ajustes → Wi-Fi → el icono de información de la red → Configurar DNS → Manual. El cambio afecta solo a esa red en los dos sistemas, salvo la opción de DNS privado de Android.
El router: la forma que sirve para toda la oficina
Cambiar el servidor DNS equipo por equipo es razonable para una prueba y absurdo como método. Lo que corresponde en una oficina es fijarlo en el router o en el servidor que reparte direcciones por DHCP: a partir de ahí, todos los dispositivos que se conecten lo reciben automáticamente, incluidos los que nadie configura nunca, como teléfonos, impresoras y equipos de visitantes.
Un detalle de orden que ahorra incidentes: apunte el cambio. La mayoría de las averías de DNS que llegan a una mesa de ayuda no son averías, sino configuraciones manuales que alguien dejó puestas en un equipo hace meses «para probar» y nadie revirtió.
Diagnóstico del servidor DNS: los comandos que resuelven casi todo
Diagnosticar el DNS consiste en preguntar a mano lo que el sistema pregunta solo, y comparar respuestas. Con cuatro herramientas se cubre casi todo.
| Herramienta | Dónde está | Para qué es mejor |
|---|---|---|
nslookup | Windows, macOS, Linux | Consulta rápida y disponible en todas partes |
dig | macOS y Linux; instalable en Windows | Ver la respuesta completa, con TTL, códigos y sección de autoridad |
Resolve-DnsName | Windows, en PowerShell | Devolver objetos que se pueden filtrar y comparar; ideal en servidores |
ipconfig /displaydns | Windows | Ver qué tiene guardado el equipo antes de culpar al servidor |
nslookup: preguntar al servidor DNS desde cualquier equipo
Las consultas que más se usan, con su explicación al lado:
:: Resolver un nombre con el servidor DNS que tenga configurado el equipo
nslookup www.ejemplo.com
:: Resolver preguntando a un servidor concreto, para comparar
nslookup www.ejemplo.com 1.1.1.1
:: Consultar un tipo de registro concreto
nslookup -type=MX ejemplo.com
nslookup -type=TXT ejemplo.com
:: Ver y vaciar la cache local de Windows
ipconfig /displaydns
ipconfig /flushdnsdig: la respuesta DNS completa, con el TTL incluido
En macOS y Linux, dig da una respuesta mucho más informativa. La opción +short devuelve solo el valor; sin ella se ve el TTL restante, que es el dato que dice cuánto falta para que caduque una respuesta vieja:
dig ejemplo.com A +short
dig ejemplo.com MX
dig ejemplo.com TXT +short
dig @1.1.1.1 ejemplo.com A
dig ejemplo.com NS +short
dig +trace ejemplo.comDe todas ellas, dig +trace es la que más enseña: recorre la cadena completa desde la raíz hasta el servidor autoritativo, mostrando cada delegación. Cuando un dominio «no resuelve» y nadie sabe por qué, ese recorrido señala el eslabón exacto donde se rompe.
En Windows, el equivalente moderno y documentado por el fabricante es el cmdlet Resolve-DnsName, que además permite saltarse la caché del equipo, cosa que nslookup no hace de forma evidente:
Resolve-DnsName ejemplo.com -Type A
Resolve-DnsName ejemplo.com -Type MX -Server 1.1.1.1
Resolve-DnsName ejemplo.com -Type TXT -DnsOnly
Resolve-DnsName _dmarc.ejemplo.com -Type TXTCómo vaciar la caché DNS en cada sistema
Para vaciar la caché en los otros sistemas, que es el primer paso tras cualquier cambio:
# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Linux con systemd
sudo resolvectl flush-caches
resolvectl statusEstos comandos conviven con el resto del instrumental de red del día a día. Si trabaja sobre todo en Windows, la guía de comandos CMD para redes, reparación y soporte recoge el conjunto completo, y la de comandos básicos de Linux hace lo propio del otro lado.
«El servidor DNS no responde» y otros errores, traducidos
Los mensajes que ve el usuario no dicen casi nada; los códigos que devuelve el protocolo dicen bastante. Esta es la traducción.
| Código o mensaje | Qué significa realmente | Por dónde empezar |
|---|---|---|
| NXDOMAIN | El nombre no existe. La respuesta es válida y llegó bien | Revisar si el registro está creado y bien escrito, y la caché negativa |
| SERVFAIL | El servidor intentó resolver y no pudo. Suele ser un fallo en la zona o en DNSSEC | Probar con otro resolvedor y comparar; revisar la firma y la delegación |
| REFUSED | El servidor entendió la consulta y se niega a atenderla | Casi siempre, preguntar a un servidor autoritativo como si fuera recursivo |
| NOERROR sin datos | El nombre existe, pero no tiene registros de ese tipo | Pedir el tipo correcto: un nombre puede tener MX y no tener A |
| Tiempo de espera agotado | No hubo respuesta. El problema es de red o el servidor está caído | Comprobar conectividad al puerto 53 y probar con otro servidor |
| «El servidor DNS no responde» | Mensaje de Windows para el caso anterior | Probar con 1.1.1.1: si funciona, el fallo es del resolvedor configurado |
Un método que funciona y evita dar palos de ciego: pregunte lo mismo tres veces. Primero al equipo, con su configuración actual. Segundo a un resolvedor público, con nslookup nombre 1.1.1.1. Tercero al servidor autoritativo del dominio, que averigua con dig ejemplo.com NS +short. Las tres respuestas, comparadas, sitúan el fallo sin ambigüedad: si la tercera es correcta y la primera no, el problema está en el camino, no en la zona.
Seguridad del DNS: DNSSEC, DoH y secuestro de dominio
El DNS nació en una internet pequeña donde todos se fiaban de todos. Sus consultas viajan por omisión en claro y sus respuestas, por omisión, no llevan ninguna prueba de autenticidad. De ahí salen tres asuntos que conviene conocer, aunque la decisión de aplicarlos corresponda a cada organización.
DNSSEC: firmas de autenticidad, no cifrado
DNSSEC añade firmas criptográficas a las respuestas, de modo que un resolvedor puede comprobar que lo que recibe es lo que el dueño del dominio publicó y no algo insertado por el camino. Está descrito, con su conjunto de documentos vigente, en el RFC 9364. No cifra nada: solo demuestra origen e integridad. Su contrapartida es operativa, y hay que decirla claro: una firma caducada o una delegación mal hecha convierten el dominio en inaccesible con un SERVFAIL limpio, y es un tipo de caída que asusta porque el registro parece correcto a simple vista.
DoH y DoT: la consulta cifrada, y su efecto secundario
DoH y DoT resuelven el otro problema, el de la confidencialidad. Cifran la consulta entre el equipo y el resolvedor, por HTTPS en el caso de DoH —normalizado en el RFC 8484— o sobre TLS en el de DoT. Los navegadores modernos lo activan en algunos casos por su cuenta, y eso tiene un efecto secundario que sorprende en entornos corporativos: si el navegador cifra sus consultas y las manda a un resolvedor de internet, se salta el servidor DNS interno, con lo que los nombres internos dejan de resolverse y cualquier filtrado por DNS deja de aplicarse. Es una opción que conviene decidir de forma consciente, no descubrirla en un incidente.
La cuenta del registrador, el eslabón que más daño hace
El tercer asunto no es técnico, y es el que más daño hace: el control de la cuenta del registrador. Quien entra en el panel donde vive el dominio puede reescribir la zona entera en un minuto y llevarse el sitio web y el correo a otra parte. Tres medidas elementales evitan casi todos los casos conocidos: activar la verificación en dos pasos en la cuenta del registrador, activar el bloqueo de transferencia del dominio y vigilar la fecha de renovación. Un dominio que caduca por descuido produce exactamente el mismo resultado que un ataque, y es más frecuente.
Conviene añadir una nota de expectativas, porque se vende mucho humo con esto: cambiar a un resolvedor con listas de bloqueo filtra dominios maliciosos ya conocidos y es una capa útil y barata, pero no sustituye a nada. Los correos de suplantación siguen llegando y el usuario sigue siendo quien decide si hace clic. Sobre eso, la guía sobre cómo identificar el phishing y frenarlo en la empresa entra en detalle.
Siete errores de configuración que tumban un servicio
Ninguno de estos es exótico. Todos aparecen una y otra vez, y todos se detectan en menos de cinco minutos si se sabe qué mirar.
| Error | Qué se rompe | Cómo se comprueba |
|---|---|---|
| Cambiar de servidor y olvidar el registro A | El sitio sigue apuntando a una máquina apagada | dig ejemplo.com A +short y comparar con la IP nueva |
| Poner un CNAME en la raíz del dominio | El correo deja de llegar, aunque la web funcione | dig ejemplo.com MX: si no devuelve nada, ahí está |
| Publicar dos registros SPF | Los envíos empiezan a caer en no deseado | dig ejemplo.com TXT +short y contar cuántos empiezan por v=spf1 |
| Superar las diez consultas del SPF | Lo mismo, pero sin ninguna señal visible | Una herramienta de validación de SPF que muestre el contador |
| Cambiar los NS en el panel y no en el registrador | Los cambios no surten efecto y nadie entiende por qué | dig ejemplo.com NS +short contra lo que aparece en el registrador |
| Dejar registros de servicios que ya no se usan | Nombres apuntando a direcciones de terceros que pueden reasignarse | Revisión periódica de la zona, registro por registro |
| Un solo servidor DNS interno | La red corporativa cae entera cuando esa máquina se reinicia | Mirar cuántas direcciones entrega el DHCP a los equipos |
El registro DNS huérfano, el error de peor consecuencia
Merece la pena detenerse en el penúltimo, el de los registros huérfanos, porque es el menos evidente y el de peor consecuencia. Cuando una empresa deja de usar un servicio en la nube pero conserva el subdominio que apuntaba a él, ese nombre queda señalando a un recurso que el proveedor puede volver a asignar a otro cliente. El resultado es un subdominio de su empresa mostrando contenido ajeno. La prevención es aburrida y eficaz: cada vez que se da de baja un servicio, se borra su registro.
Buenas prácticas para administrar el servidor DNS de una empresa
- Documente la zona entera. Una hoja con cada registro, para qué es y quién lo pidió. Sin eso, nadie se atreve a borrar nada y la zona crece indefinidamente.
- Tenga siempre dos servidores, tanto en el interior como en el exterior, y en infraestructuras distintas. El DNS es un servicio de los que no admiten pieza única.
- Baje el TTL con 48 horas de antelación a cualquier migración, y devuélvalo a su valor normal cuando todo esté estable.
- Cambie una cosa cada vez y verifique antes de seguir. Tocar cinco registros a la vez convierte el diagnóstico posterior en adivinanza.
- Revise la zona dos veces al año buscando registros de servicios que ya no existen.
- Proteja la cuenta del registrador con verificación en dos pasos, bloqueo de transferencia y una alerta de renovación que no dependa de la memoria de nadie.
- Vigile la resolución como un servicio más. Un servidor DNS que responde con lentitud degrada todo lo demás y no aparece en ningún panel hasta que alguien lo mide.
- No configure resolvedores públicos en equipos unidos al dominio. El reenvío se define en el servidor interno, no en cada puesto.
Por qué la resolución de nombres se vigila tan poco
El último punto merece un desarrollo. La resolución de nombres es de esos servicios que casi nunca se vigilan porque no tienen una pantalla que mirar, y sin embargo su degradación se percibe en todo lo demás: el correo tarda, la aplicación web «va lenta», la videollamada se corta al empezar. Medir el tiempo de respuesta del resolvedor y la disponibilidad de los autoritativos es barato y adelanta el diagnóstico. En la guía sobre qué medir en un servidor y con qué herramientas está el planteamiento completo.
Preguntas frecuentes sobre el servidor DNS
¿Cuál es el mejor servidor DNS?
No hay uno mejor en abstracto. Para un equipo doméstico o una prueba de diagnóstico, 1.1.1.1 y 8.8.8.8 son rápidos y fiables. Para una oficina con dominio propio, el mejor es el servidor DNS interno de la organización, con un resolvedor público configurado como reenviador. Y si le interesa el filtrado de dominios maliciosos conocidos, 9.9.9.9 lo incluye sin coste.
¿Cuánto tarda en aplicarse un cambio?
Lo que marque el TTL que tenía el registro antes del cambio, no el que tiene ahora. Con un TTL de 300 segundos, minutos; con uno de 86.400, hasta un día entero. El servidor autoritativo lo publica al instante: lo que tarda es la caducidad de las copias guardadas en los resolvedores del mundo.
¿Cambiar el DNS mejora la velocidad de internet?
No mejora el ancho de banda ni la velocidad de descarga. Puede recortar decenas de milisegundos en la primera consulta de cada nombre, lo que se nota algo al navegar entre muchos sitios distintos y nada al descargar un archivo grande o al ver vídeo.
¿Qué pasa si se cae el servidor DNS?
Depende de cuál. Si cae el resolvedor, los equipos afectados dejan de traducir nombres aunque la conexión siga activa: el síntoma es «hay internet pero no abre nada». Cuando caen los autoritativos del dominio, el nombre desaparece de internet para todo el mundo a medida que van caducando las cachés. Y cuando el que falla es el servidor DNS interno, la red corporativa se queda sin encontrar sus propios servidores.
¿El DNS guarda lo que visito?
El resolvedor que usted utilice ve todos los nombres que consulta, y cada operador aplica su propia política de registro y conservación. Por omisión esas consultas viajan sin cifrar, de modo que también son visibles en la red por la que pasan. Eso es precisamente lo que resuelven DoH y DoT, y es la razón por la que la elección del resolvedor no es solo una cuestión de velocidad.
¿Necesito un servidor DNS propio en mi empresa?
Si tiene dominio de Windows, servidores propios o recursos compartidos, sí: sin él, esos nombres no existen para nadie. Si toda su operación vive en servicios en la nube y los equipos no están unidos a un dominio, puede bastarle con el resolvedor del proveedor y una zona pública bien administrada.
Lo que hay que retener
El sistema de nombres es la capa sobre la que se apoya todo lo demás y la que menos atención recibe hasta que falla. Tres ideas resumen lo importante: los cambios tardan lo que diga el TTL viejo, el correo de la empresa depende de cuatro líneas de texto en la zona, y un único servidor DNS es un único punto de fallo con capacidad para detener la operación entera.
Diseñar esa capa, documentarla y administrarla es parte del trabajo de una red corporativa en condiciones, junto con el direccionamiento, la segmentación y el cableado certificado. En KHARONTE eso se hace dentro de redes y conectividad, y la administración de los servicios de directorio y de correo sobre los que se apoya, dentro de gestión de plataformas.
