DNS — An Underrated Part of Your Digital Identity

La mayoría de los usuarios perciben el DNS como un detalle técnico que se ejecuta en segundo plano. Internet se abre, las páginas web cargan... eso significa que todo está configurado correctamente. Por eso, muchos configuran Google Public DNS (8.8.8.8) o Cloudflare (1.1.1.1) una sola vez, o incluso dejan la configuración automática de su proveedor y no vuelven a preocuparse por ello. Este enfoque es perfectamente adecuado para el uso normal de Internet. Pero cuando se trata de proxies, navegadores anti-detección, automatización, web scraping o investigación de seguridad informática, el DNS deja de ser una configuración secundaria. Se convierte en parte de tu identidad en línea.

Es importante recordar que el DNS es uno de los mecanismos más antiguos de internet. Sus bases se establecieron a principios de la década de 1980 (los RFC 1034 y 1035, fundamentales en este ámbito, datan de 1987), cuando la privacidad y la lucha contra el fraude eran conceptos desconocidos. Una solicitud DNS clásica se envía en texto plano a través de UDP al puerto 53, visible tanto para el proveedor de servicios de internet como para cualquier nodo intermedio. Este legado dio origen a problemas actuales e intentos de solucionarlos, como el DNS cifrado. Comprender este contexto nos ayuda a entender por qué elegir un resolvedor es más que una simple cuestión estética.

DNS es más que una guía telefónica.

A menudo se describe el DNS como la guía telefónica de internet: un nombre de dominio se convierte en una dirección IP, tras lo cual el navegador se conecta al servidor correcto. Esta explicación es correcta, pero demasiado simplificada. Hoy en día, el DNS se utiliza para el balanceo de carga, la selección del nodo CDN más cercano, el enrutamiento, la garantía de la tolerancia a fallos y la creación de un perfil estadístico de usuario. El geo-DNS y el enrutamiento basado en latencia son buenos ejemplos. Un mismo dominio puede devolver diferentes direcciones IP según quién realice la solicitud y desde dónde. Un sitio web grande alojado en una CDN devolverá un servidor perimetral cuando se solicite a través de un resolvedor alemán y otro a través de uno estadounidense. Servicios como AWS Route 53 o Cloudflare Load Balancing hacen esto de forma predeterminada: establecen un TTL muy corto (a veces de 30 a 60 segundos) en los registros para cambiar rápidamente el tráfico y mantener la tolerancia a fallos. El mismo mecanismo que hace que un dominio sea "resiliente" convierte el DNS en una señal en tiempo real sobre dónde cree la red que se encuentra el cliente.

La subred de cliente EDNS (ECS, RFC 7871) merece una mención aparte. Se trata de una extensión en la que el resolvedor pasa una porción truncada de la subred del cliente al servidor autoritativo para que la CDN pueda encontrar un nodo más cercano. Aunque suene puramente técnico, su significado es sencillo: el resolvedor puede comunicar la geografía aproximada de la conexión a servidores externos incluso antes de que se establezca la conexión principal. El comportamiento de los distintos resolvedores varía; volveremos sobre este tema más adelante.

Por eso, los sistemas antifraude modernos analizan no solo las direcciones IP, sino también cómo se realizó la resolución de nombres. La idea central de la protección moderna es simple: el sistema casi nunca toma una decisión basándose en un solo indicador. Evalúa una combinación de señales y genera una puntuación de riesgo. Un registro DNS inusual por sí solo no demuestra nada. Pero cuando se suman las discrepancias de zona horaria (por ejemplo, el sistema informa Europa/Berlín, pero el idioma del navegador es en-US), la geografía de la IP, la huella digital del dispositivo (Canvas, WebGL, conjunto de fuentes) y las características de la red, el perfil comienza a parecer menos natural. Cada indicador por sí solo es débil; su combinación tiene peso.

Por qué el DNS público no siempre es la mejor opción

Google Public DNS y Cloudflare son servicios excelentes. Son rápidos, estables y compatibles con protocolos modernos: DNSSEC, DNS sobre HTTPS y DNS sobre TLS. Cloudflare, por ejemplo, funciona como una red anycast en cientos de ciudades, y pruebas independientes sitúan sistemáticamente a su servidor DNS entre los más rápidos del mundo. El problema no radica en su calidad, sino en el contexto de uso.

Un matiz revelador reside precisamente en el comportamiento con ECS. Google Public DNS envía una subred de cliente truncada a los servidores autoritativos (al poner a cero los bits menos significativos de la dirección) para seleccionar con mayor precisión un nodo CDN. Cloudflare, en 1.1.1.1, no envía ECS en absoluto por motivos de privacidad. Ninguno de los dos es "bueno" ni "malo" en sí mismo, pero son situaciones distintas. Con Google, el servidor autoritativo obtiene una idea aproximada de tu ubicación geográfica; con Cloudflare, no, pero el enrutamiento a la CDN puede ser menos preciso. El usuario promedio no lo notará. Para alguien que crea un perfil de red consistente, este es otro parámetro que coincide o contradice el resto de la información.

Existe un argumento más sencillo. La mayoría de los usuarios domésticos no modifican su DNS y utilizan los servidores de su proveedor de internet, que se asignan automáticamente mediante DHCP. Por lo tanto, si el objetivo es parecer un usuario habitual de una red específica, el DNS del proveedor suele ser una opción más natural que un servidor DNS público. En este sentido, los servidores DNS públicos 8.8.8.8 o 1.1.1.1 indican una configuración deliberada: los eligen entusiastas, administradores y redes corporativas, pero no el usuario promedio de una operadora móvil. Esto no significa que un DNS público sea "malo". Simplemente ofrece una perspectiva ligeramente diferente sobre la conexión.

La constancia es más importante que la velocidad.

El término «consistencia» se utiliza cada vez más en el ámbito profesional. Significa que todos los elementos de un perfil de red son consistentes. Si una dirección IP pertenece a un operador móvil alemán, es razonable esperar una zona horaria alemana (Europa/Berlín), una configuración regional del sistema en alemán o inglés, y la resolución DNS a través de una infraestructura conectada de forma lógica a esa red, en lugar de a través de un nodo anycast que enruta físicamente la solicitud a otro continente.

Imaginemos una discrepancia típica: la dirección IP pertenece a un operador móvil alemán, la zona horaria del navegador es Europa/Berlín, pero las solicitudes DNS se envían a 8.8.8.8 y, en realidad, acceden a la red a través del servidor de Google en Estados Unidos, y el idioma de la interfaz está configurado en inglés estadounidense (en-US). Ninguno de estos datos es alarmante por sí solo. Sin embargo, en conjunto, crean una situación difícil de explicar con el comportamiento habitual de un usuario real. Cada desviación individualmente no es crítica, pero cada nueva discrepancia aumenta la probabilidad de que el perfil parezca inusual. La velocidad del servidor DNS es prácticamente irrelevante en este caso: una ganancia de 10 a 20 milisegundos no compensa la pérdida de consistencia.

Un enfoque práctico

La selección de DNS no debería comenzar con la pregunta "¿qué servidor es el más rápido?", sino más bien con la pregunta "¿cómo debería presentarse este sistema al usuario?". La decisión, por lo general, se desglosa según el tipo de proxy.

Para proxies móviles y residenciales (de proveedores de servicios de Internet), lo más natural es que la resolución de nombres se produzca a través de la infraestructura del proveedor correspondiente, o al menos a través de un servidor DNS accesible al otro lado del túnel, no desde su propio equipo. El principio fundamental es que la resolución DNS debe realizarse a través del proxy, no de forma indirecta. De este modo, tanto la ubicación geográfica de la solicitud como la sugerencia ECS (si se transmite) coincidirán con la dirección IP de la fuente de tráfico principal.

Para los servidores de centros de datos, la coherencia interna de toda la configuración es más importante que intentar imitar una conexión a internet doméstica. No sorprenderá a nadie que un centro de datos utilice, por ejemplo, Cloudflare o su propio servidor de resolución de nombres; pero si todo el conjunto de nodos se comporta de forma uniforme, predecible y sin fugas, ya se trata de una situación estable o, en el buen sentido, "normal". No existe una solución universal: la respuesta correcta no viene determinada por la velocidad, sino por la leyenda que el sistema debe admitir.

Fugas de DNS y navegadores modernos

Una fuga de DNS se produce cuando las solicitudes DNS toman una ruta diferente a la del tráfico principal. Por ejemplo, HTTP pasa por un proxy, mientras que DNS continúa enviándose directamente a través del ISP local. Esto genera inconsistencias adicionales: el sitio web "ve" una IP en la conexión, mientras que el servidor DNS autoritativo ve una fuente de solicitud completamente diferente. Una fuente clásica de estas fugas es la ubicación de la resolución de nombres al trabajar con SOCKS5. La diferencia es perceptible incluso a nivel de curl: el esquema socks5:// obliga al cliente a resolver el dominio localmente (y la solicitud omite el proxy), mientras que socks5h:// pasa el nombre al servidor proxy, que lo resuelve en su lado. La lógica es la misma en los navegadores: en Firefox, esto se controla mediante el parámetro network.proxy.socks_remote_dns. Si está deshabilitado, los dominios se resuelven localmente, lo que resulta en una fuga incluso con un proxy configurado formalmente. Este pequeño detalle de configuración cambia por completo el origen de la fuga de DNS.

La situación se complica por el hecho de que los navegadores modernos utilizan cada vez más DNS sobre HTTPS. Firefox fue el primer navegador en habilitar DoH por defecto en 2020 para usuarios estadounidenses; Chrome añadió el modo DNS seguro ese mismo año. Chrome es cuidadoso en este sentido: no cambia el proveedor de DNS, sino que solo actualiza el resolvedor existente a una versión cifrada si admite DoH. Sin embargo, esto tiene una desventaja para quienes trabajan a través de un proxy: si el navegador cambia automáticamente al punto final DoH de Cloudflare sobre la conexión real, el DNS puede filtrarse eludiendo el túnel, incluso cuando HTTP se envía a través del proxy. Por último, los navegadores no son los únicos con sus propios mecanismos de resolución de nombres: Android 9 y versiones posteriores admiten DNS privado (DNS sobre TLS), Windows 11 admite DoH a nivel del sistema, y ​​las aplicaciones individuales implementan la resolución a su manera. Por lo tanto, hoy en día, no basta con revisar la configuración del sistema operativo; es importante comprender cómo se comporta cada aplicación individualmente. También es importante no confundir las fugas de DNS con las fugas de WebRTC: estas últimas no revelan nombres, sino direcciones IP locales y públicas a través de STUN, un canal independiente que también debería cerrarse.

La conclusión principal

La lucha contra el fraude ha experimentado cambios significativos en los últimos años. Anteriormente, el enfoque principal se centraba en la dirección IP y su reputación. Hoy en día, se analiza la identidad digital completa del usuario: navegador, dispositivo, idioma, zona horaria, enrutamiento, comportamiento del servidor DNS, fugas de DNS y decenas de otras señales. En esencia, se trata de un modelo probabilístico que combina características débiles en una única evaluación, y la introducción de una discrepancia adicional casi siempre resulta más costosa que los milisegundos que se ahorran con un servidor DNS rápido.

Esto elimina la necesidad de buscar el DNS perfecto. Es mucho más útil considerar el sistema en su conjunto. Además, una configuración estéril y excesivamente limpia puede resultar más sospechosa que una estándar: los usuarios reales no son perfectos. Una buena configuración no tiene por qué ser invisible; debe parecer lógica y natural, y sus elementos no deben contradecirse entre sí. Este enfoque —la coherencia en lugar de la búsqueda de parámetros individuales "óptimos"— suele ser el más sostenible a largo plazo: la reputación se construye con el tiempo, y un perfil coherente envejece mejor.