DNS mediante TLS

Introducción

Las consultas y respuestas de DNS tradicionales se envían a través de UDP o TCP sin encriptación. Esto es vulnerable a la escucha y la falsificación de identidad (incluido el filtrado de Internet basado en DNS). Las respuestas de los agentes de resolución recurrentes a los clientes son las más vulnerables a los cambios no deseados o maliciosos, mientras que las comunicaciones entre los agentes de resolución recursivos y los servidores de nombres autorizados suelen incorporar protección adicional.

Para solucionar estos problemas, el DNS público de Google ofrece la resolución de DNS a través de conexiones TCP encriptadas con TLS, como se especifica en RFC 7858. DNS-over-TLS mejora la privacidad y seguridad entre clientes y agentes de resolución. Esto complementa las DNSSEC y protege los resultados validados por DNSSEC contra modificaciones o falsificaciones en el camino hacia el cliente.

Funcionamiento

Nota: En esta sección, se proporciona una descripción general de la operación de DNS-over-TLS cuando se habla con el agente de resolución de DNS público de Google (con el nombre dns.google). Si te interesa obtener más detalles, lee la Especificación de DNS sobre seguridad de la capa de transporte y Perfiles de uso de DNS por TLS y DNS por DTLS.

Un sistema cliente puede usar DNS mediante TLS con uno de dos perfiles: privacidad estricta u oportunista. Con el perfil de privacidad estricto, el usuario configura un nombre de servidor DNS (el nombre de dominio de autenticación en RFC 8310) para el servicio de DNS mediante TLS, y el cliente debe poder crear una conexión TLS segura en el puerto 853 al servidor DNS. No establecer una conexión segura es un error grave y no se generará ningún servicio de DNS para el cliente.

Con el perfil de privacidad oportunista, el usuario puede configurar directamente la dirección IP del servidor DNS, o bien obtenerla de la red local (mediante DHCP o algún otro medio). El agente de resolución del cliente intenta establecer una conexión segura en el puerto 853 con el servidor DNS especificado. Si se establece una conexión segura, esto proporciona privacidad para las consultas del usuario desde observadores pasivos en la ruta. Dado que el cliente no verifica la autenticidad del servidor, no está protegido contra un atacante activo. Si el cliente no puede establecer una conexión segura en el puerto 853, recurre a la comunicación con el servidor DNS en el puerto DNS estándar 53 a través de UDP o TCP sin ningún tipo de seguridad ni privacidad. El uso de la privacidad oportunista está diseñado para admitir la implementación incremental de una mayor privacidad con el objetivo de una adopción generalizada del perfil de privacidad estricto.

Cuando se usa un perfil de privacidad estricto, los agentes de resolución de stub establecen una conexión de DNS mediante TLS con los siguientes pasos.

1. El agente de resolución de stub está configurado con el nombre del agente de resolución de DNS-over-TLS: dns.google.
2. El agente de resolución de stub obtiene las direcciones IP de dns.google con el agente de resolución de DNS local.
3. El agente de resolución de stub establece una conexión TCP al puerto 853 en la misma dirección IP.
4. El agente de resolución de stub inicia un protocolo de enlace TLS con el agente de resolución de DNS público de Google.
5. El servidor DNS público de Google muestra su certificado TLS junto con una cadena completa de certificados TLS hasta un certificado raíz de confianza.
6. El agente de resolución de stub verifica la identidad del servidor según los certificados presentados.
   • Si no se puede validar la identidad, la resolución de nombres de DNS falla y el agente de resolución de stub muestra un error.
7. Una vez establecida la conexión TLS, el agente de resolución de stub tiene una ruta de comunicación segura entre un servidor DNS público de Google.
8. Ahora el agente de resolución de stub puede enviar consultas de DNS y recibir respuestas a través de la conexión.

Cuando se usa un perfil de privacidad oportunista, el cliente primero intenta crear una conexión TLS segura con el servidor. Esto se hace de manera similar a lo anterior, con una diferencia importante: el cliente no realiza ninguna validación de certificados. Esto significa que no se puede confiar en la identidad del servidor. Si no se puede establecer una conexión TLS en el puerto 853 al servidor, el agente de resolución de stub vuelve a comunicarse con el servidor DNS en el puerto 53.

Nota: Para evitar ataques de denegación del servicio y el agotamiento de los recursos del servidor, el DNS público de Google puede cerrar las conexiones de DNS mediante TLS que hayan estado inactivas durante demasiado tiempo o cuando se recibió una gran cantidad de consultas en la conexión. La próxima vez que el cliente necesite realizar consultas de DNS, el agente de resolución de stub repetirá los pasos anteriores para restablecer una conexión con el agente de resolución de DNS público de Google.

Privacidad

Nuestra Política de Privacidad se aplica al servicio de DNS-over-TLS.

El 27/06/2019 volvimos a habilitar la subred de cliente EDNS (ECS) para el servicio de DNS-over-TLS. Se inhabilitó ECS cuando se lanzó el servicio.

Asistencia de estándares

El DNS público de Google implementa DNS por TLS en función de RFC 7858. Además, admitimos las siguientes recomendaciones para proporcionar un servicio de DNS de alta calidad y baja latencia.

• TLS 1.3 (RFC 8846)
• TCP Fast Open (RFC 7413)
• Requisitos para la implementación de transporte de DNS a través de TCP (RFC 7766)

Comienza a usarlo

Consulta las instructions para configurarla en un dispositivo con Android 9 (Pie) o versiones posteriores.

DNS-over-TLS también es compatible con el servicio de DNS64 público de Google solo IPv6. Ten en cuenta que no se recomienda configurar DNS64 para un dispositivo móvil que se conecte a varias redes, ya que DNS64 solo funciona cuando IPv6 está disponible.