Cómo implementar DNS over HTTPS, TLS y QUIC en entornos empresariales

Problema

Muchas organizaciones están obligadas por sus equipos de arquitectura y seguridad a eliminar el tráfico DNS sin cifrar. El DNS tradicional funciona sobre UDP/53 y, aunque es rápido, permite a cualquier punto de la red inspeccionar nombres de dominio, filtrar contenido o incluso lanzar ataques de envenenamiento. Cuando la política exige “encrypted DNS”, los equipos de red deben sustituir la resolución tradicional por alguna variante de DNS over HTTPS (DoH), DNS over TLS (DoT) o DNS over QUIC (DoQ).

El reto no es solo habilitar un nuevo puerto; es garantizar que la solución funcione tanto para usuarios en la oficina como para teletrabajadores, que los dispositivos legacy (impresoras, cámaras IP, teléfonos VoIP) sigan resolviendo nombres, y que la visibilidad operativa (capturas de paquetes, logs de resolución) no desaparezca por completo. Además, la percepción de que “añadir TCP + TLS + HTTPS” incrementa la latencia genera dudas sobre el impacto real en la experiencia del usuario.

Causa

Infraestructura DNS legacy – La mayoría de los campus todavía usan resolvers autoritativos internos y forwarders basados en UDP. Cambiar a DoH/DoT implica reconfigurar cada cliente o introducir un proxy que traduzca el tráfico.
Falta de soporte en endpoints – Sistemas operativos modernos (Windows 10+, macOS 12+, Android 9+, iOS 14+) incluyen stub resolvers para DoH/DoT, pero equipos de red, impresoras y cámaras a menudo sólo aceptan UDP/53.
Distribución de confianza – TLS requiere un certificado válido y, en entornos corporativos, una cadena de confianza que incluya la CA interna. Sin una estrategia de distribución (GPO, MDM, DHCP) los clientes rechazan la conexión.
Política fragmentada – Cuando la oficina usa un resolver interno y los usuarios remotos se conectan a un servicio externo (por ejemplo Cloudflare), la política de filtrado de dominios se vuelve inconsistente.
MTU y UDP‑based QUIC – DoQ usa UDP con multiplexación similar a HTTP/3. En redes con firewalls que limitan fragmentación o con VPNs que reducen la MTU, los paquetes QUIC pueden ser descartados, provocando caídas intermitentes.
Visibilidad y depuración – Herramientas como Wireshark siguen capturando tráfico TLS, pero el contenido está cifrado. Sin registros centralizados, identificar fallos de resolución se vuelve más complejo.

Solución

Una arquitectura reutilizable combina un resolver interno con capacidades DoH/DoT/DoQ y un forwarder hacia un servicio DNS público cifrado. El flujo típico es:

Resolver interno – Deploy de CoreDNS, Knot Resolver o PowerDNS Recursor con plugins para DoH, DoT y DoQ. El resolver mantiene la zona interna, aplica políticas (blocklists, RPZ) y firma respuestas con DNSSEC.
TLS termination – El resolver genera un certificado X.509 firmado por la CA interna. La distribución se hace mediante GPO (Windows), profiles MDM (macOS/iOS/Android) o DHCP option 252 (WPAD) para clientes que no soportan TLS nativamente.
Proxy de fallback – En la misma red se ejecuta un contenedor cloudflared o stubby que actúa como forwarder DoH/DoT a un proveedor externo (Cloudflare, Google, Quad9). Los clientes que no pueden validar el certificado interno pueden apuntar a este proxy mediante DHCP option 6 (DNS).
Split‑horizon – Configura la zona interna en el resolver y define forward zones para dominios externos. De esta forma, los dispositivos legacy siguen usando UDP/53 contra la IP del resolver interno, mientras que los clientes modernos usan DoH/DoT directamente.
Política unificada – Centraliza listas de bloqueo y reglas de seguridad en el resolver interno (por ejemplo, usando coredns policy plugin). Tanto tráfico interno como remoto pasa por el mismo motor de políticas, garantizando consistencia.
Observabilidad – Habilita logging estructurado (JSON) en el resolver y envíalo a un stack ELK o Loki. Complementa con dnsdist o Grafana dashboards para latencia, códigos de respuesta y número de consultas por cliente.

Alternativas prácticas

DoT con systemd‑resolved: En Linux modernos, configura /etc/systemd/resolved.conf con DNS=10.0.0.53 y DNSOverTLS=yes. Ideal para estaciones de trabajo que no requieren DoH.
DoH en Windows 10+: Usa GPO Computer Configuration → Administrative Templates → Network → DNS Client → Enable DNS over HTTPS y especifica la URL del endpoint interno (https://dns.internal.company/dns-query).
DoQ en entornos con alta latencia: Deploy de Knot Resolver con quic listener, asegurando que los firewalls permitan UDP/443. Útil cuando la red tiene alta pérdida de paquetes y TCP retransmisiones son costosas.

Cuándo aplicar esta solución

Requisitos de cumplimiento – Cuando normas internas o regulatorias exigen que todo el tráfico DNS esté cifrado.
Teletrabajo masivo – Si la mayoría de los usuarios se conectan desde redes no controladas, un resolver interno con forwarder externo evita que cada endpoint tenga que configurar un servicio externo.
Política de filtrado centralizada – Cuando se necesita aplicar listas de bloqueo uniformes tanto en la oficina como fuera de ella.

No aplicar si:

La infraestructura está compuesta exclusivamente por dispositivos sin capacidad de TLS y no es viable introducir un proxy de fallback.
La red tiene restricciones de MTU que impiden el paso de paquetes UDP > 1500 y no se pueden ajustar firewalls ni VPNs.
El rendimiento crítico (p.ej., trading de alta frecuencia) no tolera el overhead de TLS; en esos casos se mantiene DNS tradicional con segmentación de red y monitoreo estricto.

Código

# CoreDNS con DoH y DoT (Docker)
docker run -d \
  --name coredns \
  -p 53:53/udp -p 53:53/tcp \
  -p 443:443 \
  -v $(pwd)/Corefile:/etc/coredns/Corefile \
  coredns/coredns:latest

Contenido mínimo de Corefile:

.:53 {
    forward . 1.1.1.1 1.0.0.1 {
        tls_servername cloudflare-dns.com
    }
    cache 30
    errors
    log
    prometheus :9153
    tls /etc/certs/internal.crt /etc/certs/internal.key
    https://0.0.0.0:443 {
        tls /etc/certs/internal.crt /etc/certs/internal.key
        health
    }
    quic 0.0.0.0:443 {
        tls /etc/certs/internal.crt /etc/certs/internal.key
    }
}

Verificación

Comprobación básica – Desde una máquina cliente con dig que soporte DoH:
```
dig @127.0.0.1 +https example.com
```
La respuesta debe incluir ad (Authenticated Data) si DNSSEC está activo.
Latencia – Ejecuta:
```
time dig @127.0.0.1 example.com
```
Comparar contra dig @10.0.0.53 example.com (UDP). La diferencia suele estar entre 5 ms y 15 ms en redes locales.
Captura de tráfico – En el gateway:
```
tcpdump -i eth0 -n port 443 and udp
```
Verifica que los paquetes UDP/443 (DoQ) y TCP/443 (DoH/DoT) llegan al resolver interno.
Logs – Busca en /var/log/coredns.log entradas JSON con client_ip y question. Un aumento de códigos SERVFAIL indica problemas de confianza TLS o de forwarder.

Notas adicionales

Rotación de certificados: Automatiza la renovación con cert-manager o scripts internos; un certificado expirado bloquea todo el tráfico DoH/DoT.
MTU y fragmentación: Si notas pérdidas de paquetes DoQ, reduce la MTU de la interfaz del resolver a 1300 bytes o habilita max_udp_payload_size en el plugin DoQ.
Política de caché: Un TTL demasiado bajo genera tráfico TLS constante; ajusta cache 300 (5 min) para equilibrar frescura y carga.
Fallback transparente: Configura DHCP option 252 (WPAD) apuntando a un proxy HTTP que redirija peticiones DNS a https://dns.internal.company/dns-query para dispositivos que solo soportan HTTP proxy.
Auditoría: Integra los logs del resolver con SIEM para correlacionar consultas sospechosas con eventos de seguridad (phishing, exfiltración).

Con este enfoque modular, la organización puede cumplir con la política de “encrypted DNS” sin sacrificar la operatividad de dispositivos legacy, manteniendo una latencia aceptable y una

Problema#

Causa#

Solución#

Alternativas prácticas#

Cuándo aplicar esta solución#

Código#

Verificación#

Notas adicionales#

Si te interesa esto, también revisa...