¿Quién opera 1.1.1.1? Comprobar una dirección DNS antes de confiar en ella

Pegó 1.1.1.1 en el campo DNS de la VPN, la página cargó y el tutorial ya parece confirmado. Esa observación es más estrecha de lo que parece: la aplicación se comportó de otra manera, y el cambio todavía no dice nada sobre quién respondió a la consulta ni por qué falló la configuración anterior. Un tutorial copiado suele llamar «el DNS de la VPN» a una dirección pública conocida, lo que es una afirmación sobre la propiedad y no sobre la accesibilidad. Comprobar qué representa la dirección lleva cinco minutos y evita un cambio permanente hecho por el motivo equivocado.

Una configuración que funciona no es una identidad

La dirección de un campo de configuración es un extremo, y un extremo tiene un operador. Son dos hechos separados, y el segundo es el que la gente se salta. Para el par que más se copia, la respuesta es pública: Cloudflare publica 1.1.1.1 y 1.0.0.1 como sus direcciones de resolutor y las enumera en su referencia oficial de direcciones. Por eso el nombre del operador va junto a la dirección y no en un tutorial aparte.

Introducir ese par con un túnel activo no convierte a la empresa de la VPN en su operadora ni hace que el tráfico sea anónimo. La consulta sale de su equipo hacia una empresa que publica el rango de direcciones, y esa empresa puede ser respetable y aun así no ser la parte que el tutorial insinuaba. La etiqueta de las instrucciones y el operador real son afirmaciones distintas. Ninguna de las dos dice quién gestiona la ruta de red intermedia.

Use la referencia publicada del propio resolutor para confirmar un par de direcciones o un extremo cifrado. Una recomendación de otro proveedor puede ser legítima, y «recomendado por», «alcanzado a través de» y «operado por» siguen describiendo tres relaciones diferentes.

Compare las tres cosas que necesita un registro

Un registro listo para revisión separa tres preguntas: quién debe recibir la consulta, si el intercambio es simple o cifrado y qué ruta debe transportarla. El nombre de un proveedor no puede rellenar la segunda ni la tercera, y una etiqueta de país no puede rellenar ninguna de ellas. Anote las tres entradas antes del cambio y compárelas después. Esas entradas no son intercambiables, y tratarlas como una sola es cómo una suposición se convierte en documentación.

La comparación es lo que convierte una configuración que funciona en una decisión documentada. Sin ella, la siguiente persona hereda una dirección sin ningún motivo adjunto. Lea primero la tercera columna de la tabla siguiente, porque es donde de hecho se detienen la mayoría de las explicaciones seguras.

La tabla es deliberadamente corta. Su idea es que cada entrada responde a una pregunta distinta y que ningún campo por sí solo cubre las tres.

Un reenviador local oculta el origen real

Un dispositivo configurado para usar su router como DNS apunta a un reenviador. Esa dirección identifica al siguiente destinatario de la consulta, no al resolutor que finalmente la responde. Un resolutor stub local añade el mismo paso extra, y es fácil confundirlo con el real porque aparece en todas las salidas de estado.

El stub reenvía a orígenes que esa misma salida también enumera, normalmente más abajo. Lea toda la cadena antes de concluir algo sobre el operador, porque la primera línea no es toda la respuesta. Si no, está nombrando a la recepción como la empresa.

resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'

El segundo comando usa el nombre de eco de un resolutor, cuando el operador publica uno, para informar de la dirección de origen que ve. El tercero nombra el servidor que respondió, que a menudo no es la dirección que usted configuró. Compare las tres salidas antes de anotar un operador.

El DNS cifrado cambia qué es visible, no quién lo ve

DNS over HTTPS y DNS over TLS protegen el intercambio entre cliente y resolutor. El resolutor sigue leyendo cada nombre que se le pide, porque responder es su trabajo. Lo que cambia es quién puede observar el intercambio: la red local ve una conexión a un solo extremo en lugar de un flujo de consultas en texto plano.

Lo que no cambia es la relación de confianza, que sigue apuntando a la organización que opera ese extremo. Un navegador con su propia configuración de DNS seguro puede evitar por completo el resolutor del sistema operativo. Trátelos como dos configuraciones que pueden no coincidir, y no como una sola configuración aplicada dos veces.

Los nombres privados necesitan de nuevo su propia decisión. Un túnel de trabajo puede encaminar dominios seleccionados hacia resolutores de la organización, y sustituirlo por un servicio público puede romper las búsquedas internas o revelar nombres internos a la parte equivocada. Revise la política de dominios antes de sustituir la configuración de todo un adaptador.

Mantenga estrecha la observación

Cuando compare, conserve la configuración antigua y cambie una sola opción a la vez. Anote la aplicación, la operación, la política del resolutor y si los nombres públicos y los privados permitidos aún se resuelven tras reconectar. Una comparación con dos cambios no demuestra ninguno de los dos. Escriba el resultado donde lo encuentre la siguiente persona, junto a la propia configuración.

resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.com

Si la aplicación empieza a funcionar, mantenga la afirmación tan pequeña como permitan las pruebas. Ese cambio ayudó a una prueba y no dice nada sobre si el resolutor anterior actuó de mala fe, si el túnel estaba roto o si otro dispositivo necesita el mismo reemplazo. El resultado duradero es una configuración cuya operadora y propósito puede explicar.