
Tengo un servidor DNS ejecutándose dentro de nuestra red privada en IP 10.10.0.10. Los servidores DNS resuelven URL en IP privadas también dentro de nuestra red. SSL para todas las URL se maneja mediante un certificado comodín para un dominio .BIZ. Pero recientemente Chrome y Firefox comenzaron a habilitar DNS sobre HTTPS durante las actualizaciones recientes. Dado que nuestro servidor DNS no cumple con DOH, los usuarios no pueden navegar a nuestras URL a menos que desactiven la función DOH dentro de su navegador.
Idealmente, me gustaría que nuestros usuarios mantuvieran DOH habilitado dentro de sus navegadores y aún confiaran en el servidor DNS local para resolver las URL de nuestras IP privadas. En un intento de lograr esto miréproxy-doh. Encendí una máquina virtual Centos-7 en IP 10.10.0.20, instalé doh-proxy y abrí el puerto 443. Luego ejecuté:
/usr/local/bin/doh-proxy --upstream-resolver=10.10.0.10 --certfile=/etc/pki/public/mycompany.bundle.biz.crt --keyfile=/etc/pki/private/mycompany.biz.pem
Usando netstat verifiqué que el puerto 443 estaba escuchando. Luego modifiqué mi configuración de VPN para cambiar la configuración de DNS de 10.10.0.10 a 10.10.0.20 (el nuevo servidor proxy doh). Sin embargo, todavía no pude navegar a nuestras URL con DOH habilitado en el navegador.
¿Estoy entendiendo mal la intención detrás de doh-proxy?
Respuesta1
No creo que malinterpretes la intención detrás de doh-proxy
, parece ser una interfaz DoH para un servidor de resolución DNS normal, creando una forma para que los clientes DoH consulten dicho servidor de resolución.
Existen varias otras soluciones de proxy de este tipo, si esta implementación en particular resulta no ser adecuada por cualquier motivo.
Sin embargo, lo que creo que puede haber entendido mal/pasado por alto es que para configurar DoH, el cliente necesita conocer la URL del servidor DoH (por ejemplo https://dns.quad9.net/dns-query
, https://dns.google/dns-query
, etc.), tener solo una dirección IP no hace nada para configurar DoH.
Y, para complicar las cosas, el Departamento de Salud actualmente no cuenta con un mecanismo de descubrimiento adecuado. (Que es la causa fundamental detrás de gran parte de la controversia en torno al DoH, especialmente con el enfoque de Mozilla).
Ejemplos de cómo funciona "DoH habilitado de forma predeterminada" en este punto:
- Firefox está configurado para saber qué servidor DoH utilizar (Mozilla elige un servicio DoH en nombre de sus usuarios, sin tener en cuenta la configuración del sistema operativo).
- Chrome actualiza selectivamente de DNS simple a DoH basándose en una tabla de mapeo con direcciones IP conocidas de servicios DNS como clave, por ejemplo
8.8.8.8 -> https://dns.google/dns-query
(Google mantiene una tabla de mapeo para servicios DNS conocidos y la actualización de DoH solo ocurre cuando la tabla de mapeo facilita consultando el mismo servicio DNS que la configuración del sistema operativo indica para DNS simple).
En definitiva, es bastante fácil ejecutar su propio servicio DoH, pero no necesariamente es fácil hacer que los clientes lo utilicen.
Lo que debe hacer es decirle de alguna manera a los clientes que utilicen https://dns.example.com/dns-query
(si asumimos que esta es la URL adecuada para su proxy) como su punto final DoH, lo que en su forma más simple probablemente signifique una configuración manual en los clientes (por aplicación, nada menos). .
Ciertamente se pueden encontrar formas de automatizar la configuración de un conjunto de aplicaciones conocidas, pero en este punto no existe ningún método de descubrimiento establecido comparable a cómo, por ejemplo, DHCP puede entregar las direcciones para DNS simple.