HTTPS oculta lo que envías a un sitio web, pero antes de que tu Mac pueda siquiera abrir esa conexión, tiene que hacer una pregunta en texto plano: "¿a qué servidor apunta este nombre?" Esa pregunta (una búsqueda de DNS) viaja sin cifrar de forma predeterminada en la mayoría de las redes, lo que significa que su proveedor de Internet, el administrador de red de su oficina o cualquier persona que comparta una red Wi-Fi no segura puede ver todos los dominios que resuelva, incluso si las páginas mismas están completamente cifradas después.
¿Por qué se producen fugas de DNS simples?
El DNS tradicional, estandarizado décadas antes de que HTTPS se convirtiera en el predeterminado de la web, envía consultas a través de UDP o TCP en el puerto 53 sin cifrado y, en la mayoría de las configuraciones de redes domésticas y públicas, tampoco requiere autenticación del solucionador. Un operador de red no necesita romper HTTPS para crear una lista de cada dominio que visita; solo necesita observar su tráfico DNS, que se encuentra claramente al lado. Así es también como funcionan muchos filtros de contenido basados en DNS y algunas formas de vigilancia a nivel de red: no inspeccionando su tráfico cifrado, sino simplemente registrando o bloqueando la búsqueda que debe realizarse antes de que exista ese tráfico.
DoH y DoT: dos formas de cifrar la misma búsqueda
Dos estándares del IETF resuelven esto envolviendo la consulta DNS encriptada. DNS-over-TLS, definido en RFC 7858, envuelve las consultas de DNS en una conexión TLS cifrada dedicada en el puerto 853, distinguiéndola del tráfico ordinario y facilitando que una red la identifique y, en principio, que una red la bloquee por completo si quiere detener específicamente el DNS cifrado. DNS-over-HTTPS, definido en RFC 8484, asigna en cambio una consulta DNS a una solicitud HTTPS estándar en el puerto 443, el mismo puerto utilizado por casi todo el tráfico web ordinario, una elección de diseño que hace que las consultas DoH sean mucho más difíciles de distinguir y, por lo tanto, se bloqueen por separado de la navegación web general.
Soporte nativo de Apple desde macOS 11
Apple incorporó DNS cifrado directamente en su pila de redes en lugar de dejarlo en manos de aplicaciones de terceros, y anunció la función en la WWDC 2020 junto con macOS Big Sur (macOS 11) y la versión equivalente de iOS 14. La sesión presentó dos formas de activarlo: una API NEDNSSettingsManager para que las aplicaciones lo configuren mediante programación y, la opción que la mayoría de la gente realmente usará, un perfil de configuración que lleva la carga útil com.apple.dnsSettings.managed, documentada en la referencia de administración de dispositivos de Apple, que le permite especificar una dirección de resolución DoH o DoT y hacer que todas las aplicaciones en el sistema la usen de forma predeterminada, sin necesidad de software de terceros.
Un perfil de configuración de muestra
Un perfil de configuración es una lista de propiedades XML (un archivo .mobileconfig) que macOS puede instalar a través de Configuración del sistema una vez que hace doble clic en él o lo arrastra al panel Perfiles. El siguiente ejemplo muestra una Mac en el solucionador DNS sobre HTTPS público de Quad9, un servicio ampliamente utilizado que no requiere cuenta y que también bloquea conexiones a dominios conocidos por phishing y otras actividades maliciosas de forma predeterminada. Reemplace el identificador del marcador de posición y los valores UUID antes de usarlo; cada perfil real necesita su propio PayloadUUID único.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadType</key>
<string>com.apple.dnsSettings.managed</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-1</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>PayloadDisplayName</key>
<string>Quad9 Encrypted DNS (DoH)</string>
<key>DNSSettings</key>
<dict>
<key>DNSProtocol</key>
<string>HTTPS</string>
<key>ServerURL</key>
<string>https://dns.quad9.net/dns-query</string>
<key>ServerAddresses</key>
<array>
<string>9.9.9.9</string>
<string>149.112.112.112</string>
<string>2620:fe::fe</string>
<string>2620:fe::9</string>
</array>
</dict>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>Encrypted DNS - Quad9</string>
<key>PayloadIdentifier</key>
<string>com.example.dns.quad9-doh.root</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>REPLACE-WITH-A-UNIQUE-UUID-2</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>Para usar Cloudflare en su lugar, configure ServerURL como https://cloudflare-dns.com/dns-query y ServerAddresses como 1.1.1.1 y 1.0.0.1 (con 2606:4700:4700::1111 y 2606:4700:4700::1001 para IPv6) o, para DNS sobre TLS en lugar de DoH, configure DNSProtocol como TLS y ServerName como one.one.one.one, según la documentación DoT publicada por Cloudflare.
Instalarlo
- Guarde el archivo con una extensión
.mobileconfigy haga doble clic en él, o abra Configuración del sistema, vaya a Privacidad y seguridad, luego Perfiles y arrastre el archivo. - macOS mostrará el contenido de la carga útil, incluido el solucionador que configuró, antes de aprobarlo; revise esto cada vez, ya que un perfil es exactamente cómo un actor malicioso podría redirigir su DNS si instala uno de una fuente que no es de confianza.
- Haga clic en Instalar y autenticar. Un perfil sin firmar como este de muestra se mostrará como estado de verificación "Sin firmar"; Esto es lo que se espera de un perfil creado a mano y no es en sí mismo un signo de manipulación, pero para cualquier cosa que vaya más allá de las pruebas personales, debe firmar el perfil para que se pueda verificar su integridad.
Verificando que funcionó
No confíes sólo en el panel de configuración: compruébalo desde la terminal.
# Show the resolvers macOS is actually configured to use
scutil --dns
# Look for your interface's resolver entry — it should now show
# the DoH/DoT server address you configured, not your router or ISP's resolver
# Confirm a lookup succeeds and see which resolver answered
dig example.com
# Cloudflare's own diagnostic page also reports whether your
# connection is using encrypted DNS when you open it in a browser
open https://1.1.1.1/helpSi scutil --dns todavía incluye la dirección de su enrutador o el solucionador de su ISP como servidor DNS activo, el perfil no tuvo efecto; verifique que lo instaló en Perfiles en lugar de simplemente descargarlo, y que ninguna otra configuración de red (ver a continuación) lo anula.
Errores que hacen que esto deje de funcionar en silencio
- Una aplicación VPN muy comúnmente anula la configuración DNS del sistema mientras está conectada, enrutando las búsquedas a través de su propio solucionador; verifique su configuración DNS nuevamente después de conectarse a una VPN, no solo antes.
- Los portales cautivos en Wi-Fi de hoteles, aeropuertos y cafeterías generalmente no pueden completar su flujo de inicio de sesión a través de DNS cifrado, ya que dependen de la interceptación de una solicitud de DNS simple para redirigirlo a una página de inicio de sesión; es posible que deba eliminar o deshabilitar temporalmente el perfil para conectarse y luego reinstalarlo una vez conectado.
- Algunos navegadores, entre ellos Firefox y Chrome, incluyen su propia configuración DoH separada que puede anular o duplicar la configuración a nivel del sistema; verifique la configuración de red del navegador si su comportamiento no coincide con lo que informa
scutil --dns. - iCloud Private Relay y DNS cifrado resuelven problemas diferentes y superpuestos: Private Relay oculta su IP de los sitios que visita en Safari, mientras que DNS cifrado oculta qué dominios resuelve de su red; usar uno no hace que el otro sea redundante.
Dónde entran FireAI y HisnLabs
FireAI does not provide encrypted DNS today — it is on the roadmap, not in the current release — so a configuration profile like the one above is what actually closes the DNS-leak gap; FireAI’s job is different, watching and controlling which apps get to make a connection at all once that lookup resolves.
FireAI es el producto de HisnLabs: un firewall con IA que corre directamente en tu Mac. Te muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona de manera local, así que tu tráfico nunca se envía a nosotros ni a nadie más. El equipo de investigación en seguridad de HisnLabs es el que mantiene esas decisiones confiables: cataloga qué dominios son simple telemetría y cuáles un servicio real, rastrea el país y la red detrás de cada conexión, y entrena el modelo local (la función Autopilot) con patrones de tráfico reales, sin que nada de eso salga de tu Mac.
Puedes leer las decisiones técnicas detrás de FireAI, o probarlo durante 17 días, en FireAI, de HisnLabs.
