Guía para elegir un resolver DNS público

• Al elegir un resolver DNS público no hay que mirar solo la velocidad: también importan la privacidad, el filtrado, la jurisdicción, el operador y el transporte cifrado. Esta guía compara 30 servicios globales según distintos requisitos.
• La herramienta de selección usa como filtros estrictos DoH·DoT·DoQ·DNSCrypt, validación DNSSEC, IPv6, jurisdicción, tipo de operador y EDNS Client Subnet, y puntúa prioridades según el objetivo.
• La prueba de latencia DoH basada en navegador muestra la velocidad relativa desde la ubicación actual, pero incluye la sobrecarga de TLS/HTTP y no puede medir resolvers exclusivos de DNS sin cifrar.
• El DNS cifrado reduce la interceptación y manipulación por intermediarios, pero el proveedor del resolver elegido puede ver los dominios consultados, por lo que también conviene considerar políticas sin registros y diseños oblivious.
• En una elección práctica hay que evaluar en conjunto DNSSEC, el intercambio velocidad-privacidad de ECS, el rendimiento de DoQ, las características de DNSCrypt, los límites del análisis de tráfico, diferencias de cumplimiento de estándares, jurisdicción y riesgos de centralización.

---

Criterios que compara la herramienta de selección

• Los resolvers DNS públicos se comparan mediante condiciones que el usuario marca como importantes.
• Condiciones usadas como filtros estrictos
  • Transporte cifrado: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
  • Soporte de validación DNSSEC
  • Disponibilidad de direcciones de resolver IPv6
  • Jurisdicción del operador
  • Tipo de operador: sin fines de lucro·comunidad·interés público, comercial, todos
  • EDNS Client Subnet(ECS): no usado, usado, indiferente
• Elementos incluidos en la puntuación de prioridades
  • Máxima privacidad y sin registros o registros mínimos
  • Bloqueo de malware y phishing
  • Bloqueo de anuncios y rastreadores
  • Control parental y bloqueo de contenido para adultos
  • Sin filtrado, devolviendo tal cual las respuestas DNS publicadas
  • Listas de bloqueo y reglas personalizadas mediante una cuenta
  • Baja latencia basada en Anycast global
  • Operador no comercial

Prueba de velocidad DoH según la ubicación actual

• La prueba integrada mide en el navegador el tiempo de ida y vuelta hasta cada resolver compatible con DoH.
• Los resolvers que solo soportan DNS sin cifrar no pueden probarse con este método.
• Los resultados son valores relativos de referencia e incluyen la sobrecarga de TLS y HTTP, por lo que se asume que se ejecutará varias veces.
• Como el navegador consulta directamente a cada resolver, la dirección IP del usuario queda expuesta a ese resolver.
• La implementación de la prueba se inspiró en el DNS Speed Test de código abierto de Silviu Stroe, pero es una implementación independiente y solo se ejecuta cuando la página se sirve por HTTPS.

Diferencias de rendimiento y transporte cifrado

• Los transportes cifrados como DoH y DoT agregan latencia por consulta, pero el tiempo total de carga de página muchas veces se acerca al de DNS sin cifrar, y la sobrecarga de DoH también resulta pequeña en entornos reales.
• En enlaces con pérdida o alta latencia, el Do53 sin cifrar todavía tiene ventaja.
• El rendimiento varía según proveedor y región, así que el resolver más rápido depende de la ubicación del usuario.
• En mediciones de extremo a extremo a gran escala de DNS cifrado, las consultas tuvieron una probabilidad mucho menor de ser interceptadas o modificadas en tránsito que con DNS sin cifrar, y la sobrecarga fue baja.
• Sin embargo, en ese estudio cerca del 25% de los proveedores DoT entregaban certificados TLS inválidos, por lo que es importante elegir un proveedor con buena calidad operativa.

Límites reales de la privacidad

• El DNS cifrado oculta las consultas dentro de la red, pero el proveedor del resolver elegido puede ver todos los dominios consultados.
• Si esto es un problema, conviene elegir un operador sin registros o considerar diseños oblivious como ODoH, donde un proxy separa la identidad de la consulta.
• Cloudflare y Apple son casos de despliegue de ODoH.
• El DNS cifrado por sí solo no oculta por completo los sitios visitados.
  • Incluso usando DoH, el análisis de tráfico puede identificar dominios visitados con alta precisión.
  • El padding EDNS estándar tampoco lo impide por completo.
  • Si este modelo de amenaza aplica, no hay que depender solo del padding; conviene usar también Tor o diseños oblivious.

DNSSEC, ECS y jurisdicción

• Solo los resolvers que realizan validación DNSSEC protegen contra registros falsificados.
• Google, Cloudflare y Quad9 validan DNSSEC y gestionaron el primer rollover de la KSK raíz sin interrupciones para los usuarios.
• Si la integridad es importante, la validación DNSSEC debe considerarse un requisito obligatorio.
• EDNS Client Subnet(ECS) envía parte de la IP a las CDN para lograr un mejor enrutamiento geográfico.
  • Google y OpenDNS envían ECS para un mapeo de CDN más preciso.
  • Cloudflare y el Quad9 estándar desactivan ECS por privacidad.
• La ubicación legal del operador afecta las medidas que pueden imponérsele y los registros.
• Un pequeño número de proveedores procesa una gran proporción del tráfico DNS recursivo mundial.
• La NSA de Estados Unidos advirtió que los resolvers externos pueden evadir el filtrado y la inspección DNS internos, por lo que hay que equilibrar comodidad y control.

DoQ y DNSCrypt

• En mediciones de DoQ de 2022, DNS-over-QUIC superó a DoT y DoH en tiempo de respuesta.
• Sin embargo, debido a la limitación de validación de dirección de QUIC, cerca del 40% de los handshakes se ralentizó.
• Si tanto el cliente como el resolver lo soportan, DoQ es la opción cifrada preferible.
  • Ejemplos de soporte: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, servicios principales de China
• DNSCrypt es una opción de cifrado más antigua que DoH, DoT y DoQ; la versión 2 salió en 2013.
• DNSCrypt cifra desde el primer paquete con la clave pública precompartida del resolver, por lo que no depende de consultas de nombres de host en claro ni de autoridades certificadoras.
• El modo Anonymized DNS de 2019 también oculta la IP del cliente.
• Entre los servicios comparados, los proveedores con DNSCrypt son Quad9, OpenDNS, AdGuard, NextDNS, Control D y Yandex.
• Faltan cifras confiables de uso; mediciones a gran escala como APNIC Labs rastrean DoH y DoT, pero no DNSCrypt.

Calidad de implementación del resolver y datos operativos

• En un estudio de 2023 sobre Extended DNS Errors, los principales resolvers mostraron reportes de errores de diagnóstico inconsistentes en el 94% de los casos de prueba.
• Cloudflare mostró en ese estudio los reportes de errores más precisos.
• Las diferencias en calidad de implementación y cumplimiento de estándares entre resolvers afectan la resolución de problemas y la confiabilidad.
• Datos operativos y comunitarios de referencia
  • ICANN Identifier Technology Health Indicators: seguimiento de la proporción de resolvers con validación DNSSEC y de la concentración de resolvers
  • DNS-OARC workshop talks y past-event archive: presentaciones de operadores e investigadores sobre DNS cifrado, rendimiento de resolvers y mediciones
  • APNIC Labs measurements: tasas de validación DNSSEC por país, uso de resolvers públicos y datos de adopción de DoH·DoT

Resolvers pequeños, comunitarios y regionales

• Fuera de la tabla comparativa también existen resolvers de aficionados, comunitarios y especializados por país; antes de usarlos hay que verificar su estado y políticas actuales.
• Las opciones europeas están recopiladas en European Alternatives.
• Hay que tener más cuidado con resolvers de regiones con fuerte censura o sanciones, porque pueden aplicar reglas locales de contenido u operar para eludir bloqueos geográficos.
• Servicios de ejemplo
  • DNS4all: resolver europeo sin filtrado que prioriza neutralidad y rendimiento
  • BlahDNS: proyecto open source de bloqueo de anuncios, operado como hobby en servidores regionales pequeños, con soporte DoH·DoT·DoQ
  • LibreDNS: resolver comunitario de LibreOps, con bloqueo de anuncios, política sin registros y soporte DoH·DoT
  • Dismail.de: resolver comunitario alemán centrado en privacidad, sin registros, con soporte DoH·DoT
  • IIJ Public DNS: resolver público DoH·DoT de Internet Initiative Japan, con bloqueo de dominios de material de explotación sexual infantil
  • DNS for Family: DoH con filtrado familiar que incluye pornografía, apuestas, malware, anuncios·rastreadores y búsqueda segura
• Se mencionan como servicios heredados o discontinuados que conviene evitar Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu y Norton ConnectSafe.

[GN⁺]

Opiniones de Hacker News

• Cada vez que veo una lista como esta o el anuncio de un servicio nuevo, no me genera mucho entusiasmo, y parece que en Hacker News sorprendentemente hay muchas reacciones parecidas.
  Llevo casi 25 años operando directamente un servicio DNS proxy, y probé tres paquetes de software en seis sistemas operativos; todo lo que aparece en las pestañas de filtros se puede hacer por cuenta propia, y de hecho lo hago.
  Lo interesante de esta lista no son tanto las opciones, sino lo que deja ver. Por ejemplo, todos los elementos marcados como “China” dicen que están “operados bajo regulación china”, pero en 2026 eso no es algo que preocupe solo en los elementos de China, sino también a usuarios de mi continente.
  La frase “operado por 1 persona en Dinamarca” es un dato interesante porque revela el factor bus, pero no se puede asumir que las demás opciones sean mejores solo porque no lo mencionan. Sobre quién está detrás de DNS.Watch hay mucha menos información que sobre Thomas Steen Rasmussen, y parece que en los últimos años se cayó al menos una vez, así que es una preocupación legítima.
  Quad101 parece tener restricciones de regiones disponibles, y también hay muchos factores que no aparecen en esta lista pero que pueden ser importantes para los usuarios, como que Gcore sea una empresa de AI.

  • Lo de “operado por 1 persona en Dinamarca” es más interesante desde el punto de vista de la supervisión organizacional que del factor bus.
    Si varias personas participan en la operación, pueden vigilarse entre sí y plantear problemas si ven algo raro, como que el resolver DNS haga logging selectivo o intervenga en los resultados. Si una sola persona opera todo, no hay nadie que la frene.
    Uno podría pensar “esa persona tiene principios, así que jamás haría algo así”, pero la presión de las agencias de seguridad puede ser fuerte.
  • Hace unos 2 años configuré mi propio resolver y simplemente funciona bien. Nunca tuve ningún problema.

• Si usas el DNS oficial del ISP, puedes obtener la ruta más corta posible desde el punto de handoff del ISP hasta el CDN o el trunk internacional. Es decir, no uses un DNS genérico que no conoce la estructura del ISP.
  ISP: 1 ms hasta Cloudflare
  Cloudflare: 10 ms hasta Cloudflare
  Eso sí, este consejo aplica a países con buenas leyes de privacidad y sin vigilancia estatal. O sea, no a EE. UU.

  • Si necesitas DNS sin censura, ese método no sirve.
  • En la práctica, es probable que usar un DNS que bloquee servidores de anuncios dé mejor rendimiento general.
  • No sé si esos países todavía existen realmente. Y esto no es solo un tema de privacidad: casi todos los países intentan impedir que los usuarios accedan a lugares a los que no quieren que accedan, normalmente con métodos torpes como hacer que el DNS predeterminado del ISP te mande a una página de advertencia en vez del sitio que querías abrir.
    Por eso, cambiar a un DNS como 8.8.8.8, aunque no necesariamente aumente la privacidad, se vuelve un primer gran paso para mejorar la experiencia de navegación.
  • Cloudflare, como es bien sabido, usa anycast, así que las respuestas DNS son las mismas vengas de donde vengas. Es difícil atribuir las cifras que diste al DNS.
    Más bien, Cloudflare puede acortar la recursión para sus propios servicios, lo que puede acelerar la etapa de resolución de nombres; y, si hace falta, también permite enrutamiento basado en ubicación mediante eDNS Client Subnet.
  • Cambiar el DNS casi no tiene efecto sobre la privacidad. Todavía pueden leer las consultas DNS y el SNI.

• Necesito consejos sobre cómo usar un resolver DNS junto con redes Wi-Fi públicas.
  Muchas redes Wi-Fi públicas necesitan que uses su propio DNS para poder redirigirte a la pantalla de aceptación de términos, y a veces piden reautorizar cada 30 a 60 minutos.
  Cuando surge un problema, uno nota que internet se detuvo, hace ping a google.com esperando el timeout, intenta adivinar si es un problema del ISP, se da cuenta de que quizá expiró la sesión de Wi-Fi, cambia el DNS y vacía la caché, entra a un dominio que no sea TLS, aprueba el portal, y luego tiene que volver a cambiar el DNS.
  Claramente debería existir algo que administre todo esto.

  • Si es macOS, quizá se pueda resolver con /etc/resolver.
    sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
    Usé este método cuando un sitio interno de la universidad solo se resolvía con el nameserver de la red. Pensé que también podría aplicarse a la URL que macOS usa para detectar portales cautivos, y la próxima vez que vaya a un café tendré que comprobarlo.
  • En macOS e iOS puedes crear un perfil que especifique los servidores DNS que se usarán siempre. También se aplica a otras redes Wi-Fi y a datos móviles.
    https://doh.lvv.me/
    Llevo años usando esto y nunca tuve problemas en hotspots públicos.
  • Basta con poner una dirección IP en la barra de direcciones. Normalmente interceptan todo el tráfico del puerto 80.
  • Este tipo de cosas debería manejarlas el sistema operativo como parte del soporte para portales cautivos. Sería buena idea contactar al fabricante del sistema operativo y registrar un bug.

• Uso Unbound localmente como servidor DoH. El paquete Unbound de Alpine Linux está compilado con libnghttp2, necesario para el listener DoH integrado, y con eso basta para activar ECH
  Precacheo cada hora con cron todos los dominios que uso con frecuencia. Mi ISP no va a meterse con mis consultas DNS, y sus empleados son más raros que yo. Si empiezo a navegar en el teléfono, voy a montar mi propio servidor DoH público. Toma unos minutos y, cuando tenga que depurar problemas raros, también podré obtener mis logs de consultas
  [1] - https://tls-ech.dev/

  • Desde hace unos 3 años opero DoH, DoT, DoQ, TCP y UDP con mis propias instancias públicas de powerdns, dnsdist y servidores recursivos/autoritativos
    Antes usaba bind, unbound y dnsmasq, así que la configuración me tomó algo de tiempo. Es muy estable, se puede usar en móviles o dispositivos antiguos, y también como resolver para unbound, adguard/dnsproxy o el resolve.conf local
  • Me da curiosidad por qué precacheas. Si es por velocidad, ¿no hablamos de 30 a 50 ms como mucho? También me pregunto si fuerzas a 3600 cuando el TTL del servidor autoritativo es menor a 60 minutos
    También me pregunto si auditas las conexiones de todos los sitios web que visitas para recopilar incluso los dominios que alojan recursos y precachearlos todos, o si solo importan los dominios principales de los sitios, que son los que más afectan la latencia percibida
  • Unbound tiene prefetch, que renueva registros en caché próximos a expirar, y también varias opciones de ajuste relacionadas con la caché y el TTL. serve-expired también parecía funcionar bien
  • Me da curiosidad qué forma tiene eso de “precacheo cada hora con cron todos los dominios que uso con frecuencia”. ¿Es un script de shell que consulta una lista de hostnames? ¿Y cuál es el criterio para definir los “dominios que uso”?
  • Acá también corro Unbound. Me gusta que se puedan usar comodines para bloquear dominios. Uso una lista de bloqueo grande y encima una lista de excepciones permitidas
    También tengo una pequeña herramienta que simplifica entradas como ayt7.ads.acme.com, afi6.ads.acme.com y foi5.ads.acme.com a ads.acme.com
    Además tengo un script que genera variantes de los dominios que uso. Por ejemplo, si el dominio legítimo es mybank.com, bloqueo myb4nk.com, mibank.com, mybank.{todos los demás TLD}, etc.
    Genero cientos de miles de estas variantes y las bloqueo todas en Unbound. Lo armé después de que mi banco me enviara un ejemplo de un sitio de phishing muy convincente
    Llevo años usando esta configuración, y un millón de dominios bloqueados funciona bien incluso en una Pi 3 vieja. En una computadora más potente, Unbound probablemente podría manejar listas de bloqueo de millones, tal vez decenas de millones de dominios. Todavía no me pasé a un enfoque solo con lista de permitidos
    También bloqueo todos los dominios Unicode. No puedo acceder a dominios que usen caracteres Unicode en el nombre, y no me importa

• Uso NextDNS y estoy conforme. Tiene mucha capacidad de configuración, como qué listas de filtros activar, cómo manejar el registro, etc.
  Es estable y rápido casi en cualquier lugar. Eso es más difícil de lograr si operas tu propio resolver en la nube, y de todos modos no quiero darle mantenimiento

  • Yo también uso NextDNS y me va bien. En particular quedé más conforme después de pasar años trasteando con Pi-hole y cansarme del mantenimiento. También se puede usar fácilmente junto con Mullvad VPN cuando hace falta
  • A mí también me resultó bastante bueno

• No sé por qué solo 29
  ¿El autor está diciendo que esa es la cantidad real de resolvers abiertos que hay hoy en Internet?
  Me pregunto cómo se puede considerar la “privacidad” o la “seguridad” del DNS sin considerar también SNI
  SNI permite que un tercero vea a qué nombre de dominio intenta conectarse un usuario en una dirección publicada, y también permite interferir con esa conexión
  DNS solo permite que un tercero vea para qué nombre de dominio un usuario consulta una dirección publicada. Para vincular tráfico que no es DNS con esa consulta, hace falta asumir cómo funciona ese software
  Por eso no sorprende que las empresas de publicidad que dominan los navegadores populares quieran que los usuarios elijan DoH dentro del navegador o en sistemas operativos empresariales. Si se lo llama engañosamente “DNS privado”, terceros pueden correlacionar con mayor eficacia las consultas con el tráfico que no es DNS del software que se ejecuta en el navegador o en el sistema operativo empresarial
  Ese tipo de afirmaciones engañosas podría llevar a demandas. Por ejemplo, los usuarios ya ganaron una demanda por afirmaciones engañosas sobre la “navegación privada”

  • Esos 29 son servicios en los que muchas personas tienen cierto nivel de confianza como para encargarles sus consultas DNS. Además, esos 29 publican información sobre las características del servicio
    Si lees la página completa, también se listan por separado otros resolvers DNS públicos que vale la pena mencionar
    Para la larga cola de resolvers DNS abiertos desconocidos, puedes usar Shodan. Pero no recomendaría confiarle tu uso de Internet a algo que encontraste en Shodan
    SNI es, efectivamente, un problema general de privacidad en Internet, pero no es una propiedad del DNS. Viéndolo por el lado positivo, ECH ya pasó por la IETF y poco a poco se irá ofreciendo también a usuarios comunes
    — autor
  • ECH no está ampliamente disponible para usuarios web comunes, salvo en algunos sitios de “prueba”
    Tampoco queda claro a quién se refiere el “you” de la respuesta del autor
    En mi caso, solo uso DNS remoto cuando obtengo periódicamente datos DNS masivos. Cuando accedo a servidores HTTP, no hago solicitudes DNS remotas. Ya tengo la información de direcciones IP que necesito, y este método es más rápido y estable
    Mantengo datos DNS masivos de varias fuentes cargados en la memoria de un proxy forward TLS local
    Todos los usuarios son distintos y cada quien debe pensar por su cuenta

• Si eres usuario en Canadá, CIRA opera un resolver público mediante IPv4, IPv6, DoH y DoT
  https://www.cira.ca/en/canadian-shield/configure/summary-cir...

  • No sé por qué los canadienses deberían confiar más en CIRA que en otras alternativas. Aun así, probablemente sea mejor que usar el DNS predeterminado del ISP

• DNScryptProxy mantiene una lista enorme de servidores DNS públicos. También indica si admiten DNSSEC, filtrado y registro de logs
  https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

• Estaría bueno que un sitio así ofreciera una prueba comparativa básica de velocidad basada en la red local
  Sería útil poder comparar el tiempo de respuesta P90 y la mediana del tiempo de respuesta para consultas aleatorias

  • Soy el autor; ya lo agregué: https://evilbit.de/dns-resolver-guide2.html#speedtest
    Aunque solo funciona con DoH
  • Si clonas este repositorio y modificas los nombres de dominio y los resolvers como quieras, puedes obtener algo parecido a lo que buscas
    [1] - https://github.com/cleanbrowsing/dnsperftest
  • Para esto estoy corriendo localmente una instancia de smokeping. Hace ping a varios servidores DNS, al DNS del ISP y a algunos sitios web importantes, y según esos resultados actualiza periódicamente los upstreams del servidor DNS local
    En mi entorno, todos los grandes servidores DNS están en el rango de 5 a 6 ms, pero no siempre fue así. El DNS del ISP tiene un promedio similar, pero mucha variación y picos que llegan a 50 ms. Y eso que debería ser la ubicación más rápida

• DNS es un tema muy importante para la privacidad y la seguridad. Creo que, en vez de elegir un DNS público, es mejor alojar infraestructura propia
  No hace falta una instancia pública. Basta con correr ADGUARD, unbound, dnsmasq o dnsdist en modo recursivo en el router o en una máquina
  También puedes configurar restricciones y listas de bloqueo según tus necesidades

  • Aun así, el ISP puede registrar todas las consultas