Cuál es mi DNS

¿Qué es el DNS, realmente?

El DNS (Sistema de Nombres de Dominio) es la guía telefónica que utiliza el internet para traducir nombres de host legibles por humanos como example.com en direcciones IP a las que el software se puede conectar. Fue definido en RFC 1034 y RFC 1035 en 1987, y el protocolo principal prácticamente no ha cambiado, aunque el ecosistema a su alrededor ha crecido enormemente.

La cadena de búsqueda tiene tres actores. Un servidor de nombres autoritativo contiene los datos reales de la zona de un dominio, establecidos por quien controla el dominio. Un resolutor recursivo (también llamado resolutor de servicio completo) realiza el trabajo de consultar a los servidores autoritativos en su nombre, almacena en caché las respuestas y devuelve los resultados a los clientes. Un resolutor stub es el pequeño cliente DNS dentro de su sistema operativo; simplemente reenvía las consultas a un resolutor recursivo y no hace nada más. Cuando escribe una URL, su resolutor stub consulta a su resolutor recursivo configurado, el cual ya tiene la respuesta en caché o recorre el árbol DNS comenzando por los servidores raíz hasta encontrar el servidor autoritativo de ese dominio.

Los tipos de registros más comunes que encontrará son:

• A asocia un nombre a una dirección IPv4. La mayoría de los sitios web publican al menos uno.
• AAAA asocia un nombre a una dirección IPv6. Se publica junto con los registros A en sitios de doble pila.
• CNAME es un alias que apunta un nombre a otro. No puede coexistir con otros registros en el ápice de la zona (el dominio raíz como example.com), por lo que las CDN utilizan extensiones propietarias ALIAS o ANAME para los dominios raíz.
• MX especifica los servidores de correo responsables de un dominio, con valores de prioridad para controlar el orden de respaldo.
• TXT contiene texto arbitrario, comúnmente registros SPF para autenticación de correo electrónico, claves públicas DKIM y pruebas de propiedad del dominio para servicios como Google Search Console.

Cada registro tiene un TTL (Tiempo de Vida) en segundos. Los resolutores recursivos almacenan en caché la respuesta durante esa duración antes de buscar una copia nueva. Un TTL de 300 significa que los resolutores se actualizan cada 5 minutos; un TTL de 86400 significa una vez al día. Esta es la razón por la que la "propagación DNS" tarda tiempo después de un cambio: cada resolutor en internet que almacenó en caché el registro antiguo debe esperar a que expire su TTL antes de ver el nuevo. Reducir su TTL a 300 antes de una migración planificada y volver a subirlo después es una práctica estándar.

Cómo detecta esta página su resolutor DNS

Esta herramienta no detecta su resolutor configurado directamente. En su lugar, envía una consulta DNS desde su navegador a la API DoH de Cloudflare en cloudflare-dns.com/dns-query utilizando el formato application/dns-json y muestra los registros A y AAAA que Cloudflare devuelve para el nombre de host que escriba. El resultado le indica lo que ve el resolutor 1.1.1.1 de Cloudflare, que suele ser la respuesta autoritativa sin ningún filtro local aplicado.

Los cuatro principales resolutores públicos tienen una huella de red y una política distintas. Utilizo Cloudflare aquí porque se encuentra constantemente entre los más rápidos en las pruebas de latencia independientes y publica una política de privacidad clara. Los otros son:

• Google 8.8.8.8 / 8.8.4.4 es el resolutor público más grande por volumen de consultas. Google registra las consultas y las anonimiza después de 24 a 48 horas. No tiene filtrado de malware de forma predeterminada.
• Quad9 9.9.9.9 / 149.112.112.112 bloquea dominios asociados con malware y phishing utilizando inteligencia de amenazas de más de 20 socios. No registra ninguna información de identificación personal y es operado por una organización sin fines de lucro suiza.
• OpenDNS 208.67.222.222 / 208.67.220.220 (ahora Cisco) ofrece categorías de filtrado configurables. Registra las consultas; los planes familiares y empresariales añaden redirecciones a páginas de bloqueo.

Si el resultado de esta herramienta difiere de lo que devuelve dig o nslookup en su máquina, la causa más común es que el resolutor de su sistema operativo esté almacenando en caché una respuesta antigua o esté devolviendo un resultado de horizonte dividido (una IP privada para nombres de host internos).

Cómo encontrar su DNS desde la línea de comandos

Para ver qué resolutor está configurado para usar realmente su sistema operativo, en lugar de lo que una página web puede inferir, necesita una terminal. Estos comandos funcionan en las tres plataformas principales sin instalar nada adicional.

Windows (PowerShell)

# Mostrar direcciones de servidores DNS por adaptador de red
Get-DnsClientServerAddress

# Consultar un resolutor específico para probarlo
nslookup example.com 1.1.1.1

# Vaciar la caché DNS local
ipconfig /flushdns

Get-DnsClientServerAddress enumera los servidores DNS asignados a cada interfaz de red, incluidos el primario y el secundario. Si su VPN está activa, a menudo verá el servidor DNS corporativo en el adaptador VPN y su ISP o enrutador en el adaptador Wi-Fi. Cuál usa Windows primero depende de la métrica de la interfaz.

macOS (Terminal)

# Mostrar todas las configuraciones del resolutor (incluyendo mDNS y VPN)
scutil --dns

# Consultar y mostrar respuesta + tiempo
dig example.com +stats

# Consultar un resolutor específico
dig @9.9.9.9 example.com

# Vaciar la caché DNS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

scutil --dns muestra la lista completa de resolutores que macOS está utilizando, incluidas las anulaciones por dominio establecidas por los perfiles de VPN. A menudo revela múltiples entradas de resolutores que la salida simple de dig oculta. La bandera +stats en dig imprime el tiempo de consulta en milisegundos, lo cual es útil para realizar pruebas de rendimiento de los resolutores.

Linux

# Sistemas con systemd-resolved (Ubuntu 18.04+, Fedora, Arch)
resolvectl status

# Alternativa para sistemas mínimos o sin systemd
cat /etc/resolv.conf

# Consultar con tiempos
dig example.com +stats

# Vaciar la caché en systemd-resolved
sudo resolvectl flush-caches

En los sistemas que utilizan systemd-resolved, /etc/resolv.conf a menudo apunta al stub local en 127.0.0.53 en lugar del resolutor ascendente real. resolvectl status muestra los servidores ascendentes reales por interfaz. En sistemas o contenedores más antiguos, /etc/resolv.conf es la fuente autoritativa.

Cuando su navegador ignora el resolutor de su sistema operativo

Desde aproximadamente 2019, tanto Firefox como Chrome han comenzado a omitir el resolutor configurado en su sistema operativo y a enviar consultas directamente a un servidor DoH de su elección. Esto no es un error; es una función de privacidad intencionada. Sin embargo, causa problemas reales en ciertos entornos.

Firefox tiene los valores predeterminados más agresivos. En EE. UU., habilita DoH a través de Cloudflare de forma predeterminada a menos que detecte una señal corporativa o de control parental. La configuración se encuentra en about:config bajo la clave network.trr.mode:

• 0 — desactivado (usa el resolutor del SO)
• 2 — DoH con alternativa al SO (predeterminado en Firefox en muchas regiones)
• 3 — solo DoH, sin alternativa al SO
• 5 — DoH deshabilitado por completo

Me topé con esto directamente durante la configuración de una herramienta interna. El equipo de seguridad había configurado un servidor DNS corporativo de horizonte dividido a través del adaptador VPN para que los nombres de host internos como jenkins.internal se resolvieran correctamente. Todo funcionaba en Chrome y Safari. Sin embargo, Firefox estaba utilizando DoH a través de Cloudflare, por lo que jenkins.internal devolvía NXDOMAIN en Firefox mientras se resolvía correctamente en cualquier otra aplicación de la misma máquina. La solución fue establecer network.trr.mode = 5 en about:config para los usuarios afectados, pero la mayoría de las personas nunca lo habrían diagnosticado sin saber que DoH estaba activo.

Chrome habilita DoH automáticamente si su servidor DNS configurado lo admite, una característica llamada "HTTPS automático para DNS." Actualiza a DoH utilizando la misma IP del servidor. Si su enrutador apunta a 8.8.8.8, Chrome utiliza el endpoint DoH de Google de forma transparente. Esto se define en el RFC 8484.

iOS Private Relay (iCloud+) y Android Private DNS utilizan DNS sobre TLS (DoT, RFC 7858) para cifrar las consultas a nivel del sistema operativo, por debajo del navegador. Cuando cualquiera de ellos está activo, cada aplicación del dispositivo envía DNS cifrado a Apple o al resolutor elegido, independientemente de lo que anuncie el enrutador.

Por qué realmente importa qué resolutor utilice

La elección del resolutor DNS tiene consecuencias reales en la privacidad, la velocidad, el filtrado y la seguridad.

• Privacidad. Una consulta DNS en el puerto 53 es texto plano. Su ISP, cualquier persona en la misma red y cualquier enrutador en el camino pueden leer cada nombre de host que consulte. Cambiar a un resolutor DoH o DoT cifra esas consultas. Su resolutor todavía las ve, por lo que está intercambiando la visibilidad del ISP por la visibilidad del proveedor del resolutor.
• Velocidad. La latencia de DNS se suma a cada nueva conexión que realiza su navegador. Un resolutor que sea 50 ms más lento que el promedio afectará notablemente los tiempos de carga de las páginas en sitios con muchos nombres de host. La red anycast de Cloudflare sitúa a 1.1.1.1 a milisegundos de un solo dígito de la mayoría de los usuarios; los resolutores de los ISP están geográficamente cerca pero a menudo son más lentos debido a una infraestructura de baja potencia.
• Censura. Algunos ISP bloquean dominios devolviendo respuestas DNS incorrectas para los nombres de host marcados. Cambiar a un resolutor público que no aplique esos filtros evita los bloqueos a nivel de DNS. Tenga en cuenta que los ISP y los gobiernos tienen otros mecanismos de bloqueo (agujeros negros BGP, filtrado SNI) que los cambios de DNS no afectan.
• Fugas de DNS de VPN. Se dice que una VPN que enruta el tráfico a través de un túnel pero deja que las consultas DNS vayan al resolutor de su ISP está filtrando DNS. Su ISP todavía ve cada nombre de host que busca, aunque su IP parezca estar en otro lugar. La herramienta de fugas de VPN comprueba esto específicamente.
• Filtrado. Quad9 bloquea dominios de malware y phishing. OpenDNS ofrece filtrado de categorías configurable. Ambos son usos legítimos: Quad9 para seguridad sin configuración, OpenDNS para filtrado doméstico o escolar.

Problemas comunes de DNS y cómo diagnosticarlos

El sitio se carga en el móvil pero no en la computadora portátil

Casi siempre se trata de un registro en caché obsoleto. Su computadora portátil resolvió el nombre de host antes de un cambio de DNS y almacenó en caché la IP antigua durante toda la duración del TTL. Los datos móviles suelen utilizar un resolutor diferente con una caché separada, por lo que ven el nuevo registro de inmediato. Solución: vacíe la caché de DNS (comandos anteriores) y vuelva a cargar.

El DNS se resuelve en dig pero no en el navegador

Su navegador está utilizando DoH a través de un resolutor diferente al de su sistema operativo. Si se encuentra en una red corporativa con DNS de horizonte dividido (nombres de host internos que solo se resuelven en el resolutor corporativo), el resolutor DoH del navegador devolverá NXDOMAIN para esos nombres mientras que dig, que utiliza el resolutor del SO, tendrá éxito. Deshabilite DoH en el navegador para el entorno afectado.

Las páginas se cargan lentamente a pesar de una conexión rápida

La alta latencia del resolutor puede ser la culpable. Ejecute dig example.com +statsy mire la línea "Query time" en la parte inferior. Cualquier valor superior a 100 ms es significativamente más lento que un resolutor público bien posicionado. Cambie el DNS de su sistema operativo o enrutador a 1.1.1.1 u 8.8.8.8 y compare. En una sesión de navegador nueva donde aún no hay nada almacenado en caché, la latencia del resolutor se suma directamente al tiempo hasta el primer byte en cada dominio nuevo.

Los nombres de host internos fallan solo en Firefox

DoH en Firefox está activo y anulando el resolutor corporativo o VPN. Abra about:config, busque network.trr.mode y establézcalo en 5 para deshabilitar DoH. Alternativamente, su equipo de TI puede desplegar la señal de canary domain (devolviendo un registro específico para use-application-dns.net) para indicarle a Firefox que deshabilite DoH automáticamente en redes gestionadas.

Comparación de resolutores DNS públicos

Elegir un resolutor es un compromiso entre la política de privacidad, el comportamiento de filtrado, la velocidad y la confianza en el operador.

Las cifras de latencia son promedios globales aproximados de DNSPerf. Su latencia real depende en gran medida de su región y del emparejamiento (peering) de su ISP.

Preguntas frecuentes

¿Cuál es mi servidor DNS?

Suele haber tres niveles para esta respuesta. Su enrutador tiene configurado un servidor DNS (a menudo el resolutor de su ISP). Anuncia ese servidor a sus dispositivos a través de DHCP. Su sistema operativo lo almacena como el resolutor configurado y su resolutor stub le reenvía las consultas. Por último, su navegador puede anular todo esto con DoH a un resolutor público. Para ver lo que su sistema operativo está utilizando realmente, ejecute Get-DnsClientServerAddress en Windows, scutil --dns en macOS o resolvectl status en Linux.

¿Por qué mi DNS es diferente al que muestra mi enrutador?

Su enrutador transmite un servidor DNS a través de DHCP, pero su dispositivo puede anularlo. Un cliente VPN comúnmente establece un servidor DNS diferente cuando el túnel se conecta. Un navegador con DoH habilitado ignora el resolutor del SO por completo para sus propias consultas. Los perfiles MDM corporativos en dispositivos gestionados a menudo configuran un resolutor específico que anula la configuración del enrutador. Cualquiera de estas capas puede producir un resolutor diferente al anunciado por su enrutador.

¿Es más seguro cambiar mi DNS a 1.1.1.1?

Para mayor privacidad frente a su ISP, sí. El resolutor de Cloudflare no vende registros de consultas y los purga en 25 horas. El resolutor de su ISP se envía en texto plano a través del puerto 53 y es visible para cualquiera en su red. Cambiar a 1.1.1.1 a través de DoH significa que su ISP no puede leer sus consultas DNS. Para protección contra malware, 1.1.1.1 no filtra de forma predeterminada; use 1.1.1.2 en su lugar. Cambiar el DNS no oculta su dirección IP ni cifra sus conexiones más allá de la propia consulta DNS.

¿Puede mi ISP ver qué sitios web visito si utilizo 1.1.1.1?

No a través de DNS, si utiliza DoH o DoT. Pero el DNS es solo una señal. Su ISP todavía puede ver las direcciones IP de destino de sus conexiones y el campo Server Name Indication (SNI) en el protocolo de enlace TLS, que revela el nombre de host al que se está conectando en los sitios HTTPS. Encrypted Client Hello (ECH) cifra el SNI pero no se despliega de forma universal. Utilizar 1.1.1.1 con DoH cierra la ventana del DNS; no cierra la ventana de la IP o del SNI.

¿Cómo sé si mi DNS se está filtrando?

Una fuga de DNS significa que su dispositivo está enviando consultas DNS fuera del túnel VPN al resolutor de su ISP, a pesar de que la VPN está conectada. Su IP de salida de la VPN es visible en la herramienta de IP, pero sus consultas DNS siguen siendo visibles para su ISP. La herramienta de fugas de VPN lo comprueba comparando su IP pública, su IP WebRTC y el resolutor que responde a sus consultas DNS. Si los tres apuntan al proveedor de VPN, está limpio.

Herramientas relacionadas

El DNS traduce nombres a direcciones IP, pero la propia IP le indica en qué red se encuentra. Consulte ¿Cuál es mi IP? para ver la dirección de donde se originan sus conexiones. La organización detrás de esa IP se encuentra en ¿Cuál es mi ISP?. Si sospecha que su VPN está enrutando el DNS fuera del túnel, la herramienta de fugas de VPN prueba su IP pública, su IP WebRTC y su resolutor DNS en una sola vista. Para conocer la velocidad y latencia de la conexión, consulte la Prueba de velocidad de internet.

Fuentes citadas anteriormente

• RFC 1034: Nombres de dominio — conceptos y facilidades (1987)
• RFC 1035: Nombres de dominio — implementación y especificación (1987)
• RFC 7858: DNS sobre TLS (DoT, 2016)
• RFC 8484: DNS sobre HTTPS (DoH, 2018)
• DNSPerf: pruebas de rendimiento de latencia de resolutores públicos
• Política de privacidad del resolutor público Cloudflare 1.1.1.1

Common questions