Secuestro de DNS del enrutador, servidores DHCP no autorizados y recuperación de DNS cifrado (DoH/DoT)¶

Cada vez que escribes la dirección de un sitio web como chase.com, google.com, o apple.com en su navegador, su dispositivo solicita un Sistema de nombres de dominio (DNS) resolver para traducir ese nombre legible por humanos en una dirección IP numérica (142.250.190.46). Si un atacante cambia silenciosamente la configuración del servidor DNS primario y secundario dentro del enrutador Wi-Fi de su hogar u oficina, activa un servidor DHCP fraudulento en su red local, modifica el ** oculto de su computadorahosts file**, o intercepta tus consultas en la red de un hotel o aeropuerto, controla la agenda de tu internet. Incluso cuando escribe la URL exacta y correctamente escrita de su banco, proveedor de correo electrónico o servidor de actualización de software en la barra de direcciones, un servidor DNS secuestrado (DNSChanger, ghostDNS, ZuoRAT, o un local dnsmasq spoofer) puede enrutar su conexión a un servidor similar malicioso, impedir que su software antivirus descargue definiciones de amenazas o mostrar una ventana emergente falsa de "Actualización del firmware del enrutador/Actualización crítica de Chrome" que instala un troyano ladrón de información.

No ignores lo repentino NET::ERR_CERT_AUTHORITY_INVALID advertencias, ventanas emergentes inesperadas del portal cautivo "Iniciar sesión en la red Wi-Fi" en la red Wi-Fi de su hogar o redireccionamientos del navegador al visitar sitios web importantes. Comparando lo que devuelve su servidor DNS actualmente asignado con un solucionador cifrado confiable (1.1.1.1, 8.8.8.8, o 9.9.9.9), auditar la configuración WAN y DHCP de su enrutador, eliminar las cachés DNS del sistema operativo y del navegador contaminadas y habilitar DNS sobre HTTPS (DoH) o DNS sobre TLS (DoT), puedes erradicar el secuestro de DNS en menos de 10 minutos.

Haz esto ahora¶

1. NUNCA haga clic Advanced -> Proceed to [website] (unsafe) si su navegador muestra repentinamente un NET::ERR_CERT_AUTHORITY_INVALID o MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT advertencia en un banco importante, correo electrónico o sitio web en la nube. HTTPS moderno (TLS 1.3) y seguridad de transporte estricta HTTP (HSTS) son su última línea de defensa cuando su DNS es secuestrado: el servidor DNS secuestrado dirigió su navegador a la dirección IP del atacante, y su navegador captó la mentira porque el servidor del atacante no posee la clave privada criptográfica genuina de Google o Chase. Al hacer clic en "Continuar de todos modos", sus contraseñas y cookies de sesión se entregan directamente al atacante.
2. NUNCA descargue ni ejecute un "Browser Update.exe / .dmg" o escriba su contraseña de Wi-Fi WPA2/WPA3 en una ventana emergente que aparece de repente en la red Wi-Fi de su hogar u oficina. Cuando el malware secuestra el enrutador (ghostDNS, Roaming Mantis) cambia los servidores DNS WAN/DHCP de su enrutador a una dirección IP criminal, su táctica número uno es redirigir cada carga de página HTTP a una página falsa "El firmware de su enrutador/Safari/Google está desactualizado" o un portal de inicio de sesión de ISP falso.
3. ** Ejecuta 10 segundos nslookup o dig Haga una prueba de comparación en su terminal ahora mismo para ver si su servidor DNS actual le está mintiendo.** Abra el símbolo del sistema o la terminal y compare nslookup google.com (que utiliza su enrutador/servidor DNS del sistema operativo actualmente asignado) contra nslookup google.com 1.1.1.1 (que consulta a Cloudflare directamente). Si su servidor DNS predeterminado es una dirección IP pública extraña ubicada en otro país que nunca configuró, o devuelve IP falsas completamente diferentes para dominios bancarios/antivirus, su DNS está secuestrado.
4. Anule temporalmente la configuración de DNS de su dispositivo a DNS cifrado (DoH / DoT en 1.1.1.1, 9.9.9.9, o 8.8.8.8) ANTES de iniciar sesión en su enrutador o restablecer contraseñas. Porque DNS-over-HTTPS (DoH) envía todas las búsquedas de dominio dentro de un formato cifrado TLS Port 443 Haga un túnel directamente a Cloudflare, Quad9 o Google, al activar DoH dentro de su navegador o sistema operativo, inmediatamente ciega un enrutador secuestrado o un solucionador de ISP no autorizado para que pueda acceder de manera segura a sitios web reales y limpiar su red.
5. Inicie sesión en el enrutador de su hogar/oficina mediante un cable Ethernet (192.168.1.1 o 192.168.0.1), inspeccione tanto el WAN / Internet DNS Y LAN DHCP Server DNS campos y, si alguno de ellos contiene direcciones IP públicas desconocidas, realice una verificación de hardware. 30-second Pin-Hole Factory Reset inmediatamente. El malware que cambia la configuración DNS del enrutador casi siempre ingresa a través de un Remote Web Management (WAN Admin) puerto, un UPnP (Universal Plug and Play) regla de reenvío de puertos o una regla predeterminada admin/admin contraseña (ver Proteger enrutadores domésticos y dispositivos IoT).
6. Comprueba el local de tu computadora hosts configuración de archivos y Proxy/PAC (C:\Windows\System32\drivers\etc\hosts en Windows o /etc/hosts en macOS/Linux) y vacíe la caché DNS de su sistema operativo. Incluso si su enrutador está 100 por ciento limpio, el adware local o los troyanos en una sola PC o Mac pueden anular la resolución DNS localmente al inyectar redirecciones IP en el hosts archivo o configurar un ** Configuración de proxy automática (PAC) URL** en Opciones de Internet de Windows.

flowchart TD
    A["Sospecha de secuestro de DNS: advertencias de certificados, ventanas emergentes de actualización falsas o carga de sitios incorrectos"] --> B["1. Habilite DNS cifrado (DoH) en el navegador/sistema operativo inmediatamente para evitar el solucionador envenenado"]
    B --> C["2. Ejecute el diagnóstico de terminal: compare 'nslookup example.com' con 'nslookup example.com 1.1.1.1'"]
    C --> D{"¿Están afectados TODOS los dispositivos conectados a Wi-Fi o solo UNA computadora/teléfono específico?"}
    D -->|"Todos los dispositivos con Wi-Fi afectados"| E["Secuestro de WAN/DHCP del enrutador o servidor DHCP no autorizado en LAN"]
    E --> F["Verifique la puerta de enlace predeterminada y la IP del servidor DHCP ('ipconfig /all'). Si no está familiarizado con MAC/IP -> Aislar dispositivo no autorizado"]
    E --> G["Restablecimiento de fábrica del hardware del enrutador -> Actualizar firmware -> Deshabilitar administrador WAN y UPnP -> Configurar el DNS del enrutador en 1.1.1.1 / 9.9.9.9"]
    D -->|"Solo UNA computadora o teléfono afectado"| H["Secuestro de dispositivo local: inspeccionar el DNS estático del adaptador de red, el archivo de hosts, el script Proxy/PAC y las extensiones del navegador"]
    H --> I["Limpie '/etc/hosts' o 'C:\\Windows\\System32\\drivers\\etc\\hosts', elimine los certificados raíz no autorizados y vacíe la caché de DNS"]

Matriz de diagnóstico: las 5 capas donde se secuestran el DNS y el enrutamiento de la red¶

Cuando un nombre de dominio se resuelve en el servidor incorrecto, el secuestro se produce en una de las cinco capas técnicas distintas de la cadena de resolución. Utilice esta tabla para identificar qué capa está comprometida:

Fase 1: Auditoría forense de DNS y DHCP de línea de comandos de 60 segundos¶

Antes de restablecer cualquier cosa, abra una terminal en su computadora y ejecute estos comandos exactos de solo lectura para capturar la evidencia de qué servidores DNS y servidor DHCP está usando actualmente su máquina.

1. Windows 10 y Windows 11 (Command Prompt o PowerShell)¶

# 1. Inspect your active Default Gateway, DHCP Server IP, and configured DNS Servers:
ipconfig /all

# 2. Check if any non-commented IP redirect lines exist in your local Windows hosts file:
findstr /V "^#" "%SystemRoot%\System32\drivers\etc\hosts" | findstr /V "^$"

# 3. Check if a rogue Proxy Server or Automatic Configuration Script (PAC) is hijacking browser traffic:
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL

# 4. Compare what your current default DNS server returns vs. Quad9 (9.9.9.9) and Cloudflare (1.1.1.1):
nslookup www.microsoft.com
nslookup www.microsoft.com 9.9.9.9

• Cómo leer el resultado del Paso 1 (ipconfig /all):
• Mira DNS Servers. Normalmente, esto muestra la IP de LAN privada de su enrutador doméstico (192.168.1.1, 192.168.0.1, 10.0.0.1), un solucionador público conocido que usted configuró deliberadamente (1.1.1.1, 1.0.0.1, 8.8.8.8, 8.8.4.4, 9.9.9.9, 208.67.222.222), o los servidores DNS regionales de su ISP de banda ancha genuino (verifique cualquier IP desconocida en https://bgp.he.net o whois: si la IP pertenece a un proveedor de alojamiento VPS a prueba de balas en otro país en lugar de su ISP, su DNS está envenenado).
• Mira DHCP Server contra Default Gateway. En el 99 por ciento de las redes domésticas, el DHCP Server La propiedad intelectual y la Default Gateway La IP debe ser idéntica (por ejemplo, ambas 192.168.1.1). Si son diferentes (y usted no creó personalmente un controlador de dominio Pi-hole o Windows Server), tiene un servidor DHCP no autorizado en su red local.

2. MacOS y Linux (Terminal)¶

# 1. On macOS: Display all active DNS resolvers, search domains, and interface bindings:
scutil --dns | grep -E "nameserver|domain|interface"

#    On Linux (systemd-resolved / NetworkManager):
resolvectl status

# 2. Inspect the local /etc/hosts file for unauthorized redirects (anything other than 127.0.0.1 localhost / ::1):
grep -v '^#' /etc/hosts | grep -v '^$'

# 3. On macOS: Check if a malicious Web Proxy or PAC Auto-Config script is enabled on Wi-Fi:
networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getautoproxyurl Wi-Fi

# 4. Compare DNS answers and check DNSSEC authentication (ad flag) using dig:
dig www.google.com
dig @1.1.1.1 www.google.com +dnssec

3. Buscar y aislar un servidor DHCP no autorizado en su red local¶

¿Qué pasa si ipconfig /all (o ip route / networksetup -getinfo Wi-Fi) revela que su computadora recibió su arrendamiento de IP y configuración de DNS de una dirección IP local desconocida como 192.168.1.142 en lugar de su enrutador real (192.168.1.1)? 1. Identifique inmediatamente el hardware Dirección MAC (Physical Address) y fabricante del dispositivo no autorizado (192.168.1.142) inspeccionando su tabla ARP:

# On Windows, macOS, or Linux, display the hardware MAC address mapped to the rogue DHCP IP:
arp -a

Fase 2: Erradicación paso a paso del secuestro de WAN/DHCP del enrutador¶

Si su auditoría en la Fase 1 demostró que su enrutador Wi-Fi está entregando direcciones DNS maliciosas (o que el DNS WAN interno de su enrutador fue modificado), simplemente inicie sesión en el enrutador y escriba 1.1.1.1 volver a la caja no es suficiente. En primer lugar, debes cerrar la vulnerabilidad que permitió que el atacante ingresara a tu enrutador:

Paso 1: realice un restablecimiento de fábrica del hardware de 30 segundos en el enrutador¶

¿Por qué realizar un restablecimiento completo de fábrica en lugar de simplemente editar el campo DNS? Porque el malware del enrutador (ZuoRAT, VPNFilter, Cyclops Blink, Mirai variantes) frecuentemente agrega información oculta iptables Reglas de redireccionamiento NAT (REDIRECT --to-ports 53), instala un trabajo cron persistente en /tmp o NVRAM, o habilita cuentas de administración SSH/Telnet remotas ocultas. 1. Desconecta el cable Ethernet WAN/Internet del router (el cable que viene de tu ONT de fibra o módem por cable) para que el atacante no pueda volver a conectarse mientras lo configuras. 2. Con el enrutador encendido, presione y mantenga presionado el botón de reinicio empotrado en la parte posterior del enrutador con un clip durante 15 a 30 segundos completos hasta que todos los LED del panel frontal parpadeen simultáneamente. 3. Espere 3 minutos para que el enrutador se reinicie en su estado limpio de fábrica, luego conecte una computadora limpia mediante un cable Ethernet (o las credenciales de la etiqueta Wi-Fi de fábrica) e inicie sesión 192.168.1.1 (o 192.168.0.1).

Paso 2: Bloquee las cinco configuraciones del enrutador que los atacantes aprovechan para secuestrar DNS¶

Antes de volver a enchufar el cable WAN/Internet, configure estas cinco configuraciones obligatorias dentro de la consola de administración de su enrutador (consulte nuestra guía completa sobre Proteger enrutadores domésticos y dispositivos IoT para endurecimiento profundo): 1. Establezca una contraseña de administrador de enrutador única de más de 16 caracteres (NO es la misma que su contraseña de Wi-Fi): Nunca deje el inicio de sesión de administración del enrutador como admin / admin o admin / password. Cada kit de explotación de secuestro de DNS CSRF en la web adivina automáticamente las credenciales predeterminadas cuando carga un anuncio publicitario malicioso en su navegador. 2. Verificar Remote Management / WAN Administration es estrictamente DISABLED: Mira debajo Advanced -> Administration -> Remote Management y asegúrese de que nadie en la Internet pública pueda acceder a la página de inicio de sesión de su enrutador o a los puertos SSH/Telnet desde el lado WAN. 3. Desactivar UPnP (Plug and Play universal): Bajo Advanced -> UPnP (o NAT Forwarding -> UPnP), desactive UPnP. El malware en cualquier dispositivo dentro de su casa utiliza UPnP (IGD Solicitudes SOAP) para ordenar silenciosamente a su enrutador que abra puertos o modifique las reglas de reenvío WAN sin una contraseña. 4. Codifique servidores DNS confiables y que bloqueen malware (IPv4 E IPv6) en el enrutador: Vaya a Configuración de Internet/WAN -> Servidor DNS (y LAN -> Servidor DHCP) y cambie de Obtener automáticamente del ISP a Usar estos servidores DNS: * ** Llamarada en la nube (1.1.1.1 for Families - Malware Blocking):** IPv4 principal: 1.1.1.2 | IPv4 secundario: 1.0.0.2 (o estándar sin filtrar 1.1.1.1 / 1.0.0.1). IPv6: 2606:4700:4700::1112 y 2606:4700:4700::1002. * Cuad9 (Malware & Phishing Blocking + DNSSEC): IPv4 principal: 9.9.9.9 | IPv4 secundario: 149.112.112.112. IPv6: 2620:fe::fe y 2620:fe::9. * DNS público de Google: IPv4 principal: 8.8.8.8 | IPv4 secundario: 8.8.4.4. IPv6: 2001:4860:4860::8888 y 2001:4860:4860::8844. 5. Vuelva a conectar el cable WAN e instale inmediatamente la última actualización de firmware del enrutador: Si el modelo de su enrutador ya superó el fabricante Fin de vida útil (EoL) fecha y ya no recibe parches de seguridad (ver Parches de emergencia para exploits de día cero y aislamiento de dispositivos al final de su vida útil), reemplace el hardware del enrutador inmediatamente para que los CVE sin parches no puedan volver a explotarse mañana.

Fase 3: Limpieza de una computadora local envenenada (Hosts Archivo, DNS del adaptador y vaciado de caché)¶

Después de proteger su enrutador (o si solo una computadora fue secuestrada), ejecute estos comandos exactos para restablecer la pila de red de su computadora local y eliminar todos los registros DNS envenenados en caché:

1. Restablecimiento completo de DNS, hosts, Winsock y caché del navegador de Windows 10/11¶

Abra Símbolo del sistema como administrador (Win + X -> Terminal (Admin) / Command Prompt (Admin)) y ejecuta:

:: 1. Reset all network adapters back to automatic DHCP DNS (removes static Trojan DNS overrides):
powershell -Command "Get-NetAdapter | Where-Object {$_.Status -eq 'Up'} | Set-DnsClientServerAddress -ResetServerAddresses"

:: 2. Disable any rogue Windows Registry Proxy or PAC AutoConfig script:
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable /t REG_DWORD /d 0 /f
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL /f 2>nul

:: 3. Flush the Windows OS DNS Resolver Cache, Winsock Catalog, and NetBIOS table:
ipconfig /flushdns
nbtstat -R
netsh winsock reset
netsh int ip reset

• Si tu C:\Windows\System32\drivers\etc\hosts el archivo contenía líneas de redireccionamiento no autorizadas: Abra Bloc de notas como administrador, abra C:\Windows\System32\drivers\etc\hosts, elimine todas las líneas no comentadas (una ventana predeterminada limpia hosts El archivo tiene cero líneas activas sin comentar y cada línea de comentario comienza con #), guarde el archivo y ejecute ipconfig /flushdns.
• Compruebe si hay certificados raíz no autorizados (certmgr.msc): Si un atacante o malware local también instaló una autoridad de certificación raíz falsa (CA) en su computadora para que puedan interceptar el tráfico HTTPS sin activar advertencias del navegador, presione Win + R, escriba certmgr.msc, expanda Autoridades de certificación raíz de confianza -> Certificados, ordene por Issued By o Expiration Datey elimine cualquier certificado raíz autofirmado desconocido que no reconozca.

2. macOS y Linux completan el restablecimiento de DNS y la limpieza de caché¶

# On macOS: Clear any static DNS overrides on Wi-Fi (reverts to DHCP) and flush mDNSResponder cache:
sudo networksetup -setdnsservers Wi-Fi Empty
sudo networksetup -setautoproxystate Wi-Fi off
sudo networksetup -setwebproxystate Wi-Fi off
sudo networksetup -setsecurewebproxystate Wi-Fi off
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# On Linux (Ubuntu / Debian / Fedora with systemd-resolved):
sudo resolvectl flush-caches

3. Vacíe el socket interno y la caché DNS de su navegador web (Chrome, Edge, Brave, Firefox)¶

Trampa crítica: Los navegadores web modernos mantienen su propio caché DNS interno separado y un grupo de sockets TCP abierto completamente independiente de ipconfig /flushdns. Incluso después de reparar su enrutador y ejecutar ipconfig /flushdns, Chrome o Edge pueden seguir enviándote a la IP del atacante durante otros 15 minutos hasta que borre el caché interno del navegador: 1. En Chrome, Edge o Brave: * Tipo chrome://net-internals/#dns (o edge://net-internals/#dns) en la barra de direcciones y haga clic en Clear host cache. * Haga clic inmediatamente Sockets en la barra lateral izquierda (chrome://net-internals/#sockets) y haga clic en Flush socket pools (esto elimina cualquier conexión HTTP/2 o QUIC persistente activa que aún esté abierta a la IP del atacante). 2. En Mozilla Firefox: * Tipo about:networking#dns en la barra de direcciones y haga clic en Clear DNS Cache. 3. En Apple Safari (macOS e iOS): * En macOS, abra Safari -> Configuración -> Avanzado, marque Show features for web developers y haga clic en Develop -> Empty Caches (Opt + Cmd + E), luego salga y reinicie Safari. * En iPhone o iPad, active Modo avión durante 5 segundos y vuelva a desactivarlo, lo que obliga a iOS mDNSResponder para purgar todo su caché DNS volátil inmediatamente sin eliminar los inicios de sesión guardados en el sitio web.

Fase 4: Habilitación de DNS cifrado (DoH / DoT) para que ningún enrutador, hotel o ISP pueda volver a secuestrar su DNS¶

¿Por qué el DNS tradicional (UDP Port 53) ¿Es tan fácil para un enrutador doméstico, Wi-Fi de una cafetería o ISP comprometido espiar y secuestrar? Debido a que el DNS estándar fue diseñado en 1983 (RFC 882) con cero cifrado y cero autenticación: cada consulta viaja a través del cable en texto sin formato, y cualquier dispositivo en el camino puede falsificar una respuesta UDP falsa en menos de un milisegundo (DNS Spoofing).

Al habilitar DNS sobre HTTPS (DoH, RFC 8484) o DNS sobre TLS (DoT, RFC 7858), su dispositivo envuelve cada consulta de DNS dentro de un archivo verificado criptográficamente TLS 1.3 túnel directamente a un solucionador confiable (Cloudflare 1.1.1.1, Quad9 9.9.9.9, Google 8.8.8.8, o NextDNS). Si un enrutador fraudulento o la red Wi-Fi de un hotel intenta alterar la respuesta, la firma TLS falla y su dispositivo rechaza la falsificación inmediatamente.

Cómo habilitar DNS cifrado (DoH / DoT) En todos los dispositivos en 60 segundos¶

Preguntas frecuentes¶

¿Por qué mi navegador mostró? NET::ERR_CERT_AUTHORITY_INVALID en google.com ¿O mi banco cuando el DNS de mi enrutador fue secuestrado?¶

Ese error del navegador en realidad le salvó de que le robaran su cuenta. Cuando un atacante secuestra la configuración DNS de su enrutador, cambia la dirección IP para `www.yourbank.com` por lo que su computadora se conecta al servidor web del atacante en lugar de a su banco real. Sin embargo, cuando su navegador inicia un HTTPS cifrado (`TLS`) apretón de manos con el servidor del atacante, el servidor del atacante no puede producir un certificado TLS digital válido firmado criptográficamente por una autoridad certificadora confiable para `yourbank.com`. Su navegador detiene inmediatamente la conexión y muestra `NET::ERR_CERT_AUTHORITY_INVALID`. Siempre y cuando nunca hagas clic en "Continuar de todos modos" y nunca instales un certificado raíz falso (`CA`) en su dispositivo, el secuestro de DNS por sí solo no puede descifrar ni falsificar un sitio web HTTPS protegido por HSTS.

¿Cómo cambió un pirata informático la configuración de DNS dentro del enrutador Wi-Fi de mi hogar sin conocer mi contraseña de Wi-Fi?¶

Los atacantes no necesitan estar dentro del alcance de Wi-Fi de su casa para cambiar la configuración DNS de su enrutador. Utilizan dos métodos remotos: primero, bots automatizados (`Shodan` / `Censys` escáneres y botnets) escanean cada dirección IP pública en Internet en busca de enrutadores domésticos que tengan **Administración web remota (`WAN Admin`)** o **`UPnP`** dejado abierto con vulnerabilidades de firmware conocidas. En segundo lugar, incluso si WAN Admin está cerrado, si dejó la contraseña de administración interna de su enrutador en la configuración predeterminada de fábrica (`admin / admin` o `admin / password`), hacer clic en un anuncio o sitio web malicioso en su computadora portátil permite que JavaScript oculto en su navegador envíe una **Falsificación de solicitud entre sitios (`CSRF`)** o **Rebinding DNS** solicite directamente desde su computadora portátil a `http://192.168.1.1`, iniciando sesión en su enrutador desde adentro y reescribiendo su configuración de DNS en silencio.

Si habilito DNS cifrado (DoH) en Chrome o Firefox, ¿eso protege las otras aplicaciones en mi computadora?¶

Habilitar DNS seguro (`DoH`) dentro de Chrome, Edge, Brave o Firefox cifra y protege todas las búsquedas de DNS realizadas **dentro de ese navegador web específico**, lo que detiene inmediatamente los redireccionamientos de phishing basados en el navegador y las páginas de actualización falsas. Sin embargo, otras aplicaciones en segundo plano en su computadora (como su cliente de correo electrónico, Slack, juegos o actualizador del sistema operativo) aún usan la resolución de DNS de todo el sistema operativo a menos que también configure DNS cifrado a nivel del sistema operativo (a través de Windows 11 Native DoH, Android Private DNS). `DoT`, o un perfil de DNS cifrado de macOS/iOS firmado) y corrija la configuración de DNS WAN/DHCP de su enrutador.

¿Cuál es la diferencia entre 1.1.1.1 (Cloudflare) y 9.9.9.9 (Quad9), ¿y cuál debo poner en mi router?¶

Ambos son solucionadores de DNS anycast globales rápidos, que respetan la privacidad y no rastrean, operados por organizaciones acreditadas, y cualquiera de los dos lo protegerá del secuestro de ISP o de enrutadores no autorizados. Estándar **`1.1.1.1`** (Cloudflare) y **`8.8.8.8`** (Google) devuelve respuestas DNS puras y sin filtrar para cada dominio de Internet. **`9.9.9.9`** (operado por la Fundación Quad9 sin fines de lucro) y **`1.1.1.2`** (Cloudflare for Families - Bloqueo de malware) verifica automáticamente cada búsqueda de dominio con fuentes de inteligencia de amenazas globales en tiempo real de sitios web de phishing conocidos, comando y control de ransomware (`C2`) servidores y dominios de robo de información, bloqueando la conexión en la capa DNS antes de que se pueda cargar una página maliciosa.

Guías relacionadas¶

• Proteger enrutadores domésticos y dispositivos IoT
• Wi-Fi público, puntos de acceso Evil Twin y defensa contra el USB
• Extensiones de navegador maliciosas, secuestradores del portapapeles y eliminación de adware
• Parches de emergencia para exploits de día cero y aislamiento de dispositivos al final de su vida útil
• Secuestro de nombres de dominio, DNS caducados y apropiación de sitios web
• Números de emergencia globales

Fuentes verificadas¶

• Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) y Agencia de Seguridad Nacional (NSA) (Estados Unidos): Hoja de información de ciberseguridad (Selección de un servicio DNS protector (PDNS) y Uso de DNS cifrado DoH / DoT en entornos empresariales y domésticos).
• Grupo de trabajo de ingeniería de Internet (IETF) (internacional): RFC 7858 (Especificación para DNS sobre seguridad de la capa de transporte DoT), RFC 8484 (Consultas DNS a través de HTTPS DoH) y RFC 9462 (Descubrimiento de solucionadores designados DDR).
• Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN (internacional): Asesoramiento sobre manipulación de la infraestructura del DNS, reconfiguración de la WAN del enrutador y validación de DNSSEC.
• Centro Nacional de Seguridad Cibernética (NCSC) (Reino Unido): arquitectura protectora de DNS y mitigación de ataques de suplantación de identidad de redes locales y DHCP no autorizados.