Hace solo unos meses hubo mucha expectación porque IETF en un marco de tiempo acelerado (aproximadamente un año) aceptó DNS sobre HTTPS (DoH) como estándar (
RFC-8484 ). Las discusiones sobre eso aún continúan debido a su controversia. Mi opinión personal es que DoH es bueno para la privacidad personal (si sabe cómo usarlo y confía en su proveedor de DNS), pero es un riesgo de seguridad para las empresas. DNS sobre TLS (
DoT ) es una mejor alternativa para los clientes empresariales solo porque utiliza un puerto TCP bien definido, pero para la privacidad personal no es bueno por la misma razón (fácil de bloquear).
A pesar de las diferencias, DoH y DoT básicamente resuelven el mismo problema: asegurar las comunicaciones DNS. Por lo tanto, un actor malintencionado no puede espiar el tráfico DNS sin cifrar y usarlo para identificar un enlace débil y para un ataque. Esto se discutió mucho, pero parece que un tema se olvidó por completo o no se cubrió ampliamente: la transferencia de Zonas de Política de Respuesta (RPZ).
RPZ / DNS Firewall es una característica de seguridad que es compatible con varios servidores DNS: ISC Bind, PowerDNS, KnotDNS y productos basados en ellos. RPZ es fácil de implementar, admite y es muy escalable con un impacto mínimo en el rendimiento, por lo que un servidor DNS se puede incluir en la seguridad de la organización como una capa adicional. Las zonas de política de respuesta se pueden mantener localmente o descargar desde proveedores externos como Infoblox, SURBL, Farsight, etc. El protocolo de transferencia de zona DNS estándar se utiliza para entregar feeds RPZ. Por lo general, las zonas DNS se transmiten a través de TCP y se firman con la clave TSIG, por lo que el contenido no puede modificarse fácilmente, pero no está encriptado y esto puede conducir a problemas peores. Si un actor malintencionado intercepta este tráfico, los indicadores bloqueados (dominios, IP) quedan expuestos y es posible evitar la capa de seguridad DNS. DNS RPS (Response Policy Service) es una nueva característica de enlace de ISC que probablemente resolverá el problema, pero en este momento está mal documentada y no es compatible con otros servidores DNS.
Los RFC DoT y DoH no limitan los tipos de solicitudes y las respuestas pueden transferirse a través de un canal cifrado, por lo que es posible aprovechar estos estándares para las transferencias de zona DNS, incluidas las alimentaciones RPZ.
Con esta publicación de
blog, me complace anunciar que
ioc2rpz de forma nativa (no se requiere proxy ni software adicional) es compatible con DoT, por lo que las fuentes RPZ se pueden distribuir de forma segura a través de canales inseguros / Internet. Esta es la primera versión (con DoT), por lo que existen algunas limitaciones: solo se admiten solicitudes por sesión y solo TLS 1.2, DNS Notify y TLS PIN no son compatibles.
ioc2rpz.gui (una interfaz web) en este momento no es compatible con la configuración de DoT (está en la hoja de ruta) pero la configuración es realmente simple. Un servidor verifica una configuración e inicia escuchas TLS si la configuración contiene un certificado (y una clave privada).
ACTUALIZACIÓN
Puede probar las fuentes de RPZ / DNS Firewall en
ioc2rpz.net El servicio funciona con ioc2rpz.