Google Public DNS ha activado silenciosamente DNS sobre TLS

De repente, sin un anuncio preliminar, DNS sobre TLS comenzó a funcionar en 8.8.8.8 . Anteriormente, Google anunciaba solo soporte para DNS sobre HTTPS.

El solucionador público de CloudFlare con la dirección IP 1.1.1.1 ha admitido DNS sobre TLS desde que comenzó el proyecto.

Porque es necesario

Usando el esquema DNS clásico, los proveedores pueden rastrear sus patas sucias en sus paquetes DNS, explorar qué dominios solicita e intercambiar las respuestas que desee. Los estafadores hacen lo mismo, reemplazando los resolvers en los enrutadores pirateados para dirigir al usuario a un servidor falso.

Con DNS sobre TLS / HTTPS, las solicitudes se envían dentro de un túnel encriptado para que el proveedor no pueda reemplazar o ver la solicitud.

Y con el advenimiento del cifrado de nombres de dominio en certificados X.509 ( ESNI ), será imposible bloquear a través de DPI a través de SNI (Indicación de nombre de servidor, un campo especial en el que el nombre de dominio se transmite en el primer paquete TLS), que ahora son utilizados por algunos grandes proveedores.

Como funciona

Se realiza una conexión TLS a TCP: 853, y el certificado de resolución se verifica utilizando certificados raíz del sistema, al igual que HTTPS en un navegador. Esto elimina la necesidad de agregar claves manualmente. Dentro del túnel, se realiza una consulta DNS normal. Esto crea menos sobrecarga que DNS sobre HTTPS, que agrega encabezados HTTP a la solicitud y respuesta.

Desafortunadamente, actualmente solo el soporte de Android 9 (Pie) para DNS sobre TLS está integrado en el sistema de resolución. Instrucciones de configuración para Android 9 .

Para otros sistemas, se propone utilizar un demonio de terceros y enviar la resolución del sistema a localhost (127.0.0.1).

Configuración en macOS

Analicemos DNS sobre TLS en la última versión de macOS, usando el solucionador de nudos como ejemplo

Instalación

brew install knot-resolver 

Por defecto, el nudo funcionará como un solucionador recursivo normal, como dnsmasq.

Editando la configuración

 nano /usr/local/etc/kresd/config 

Y agregue al final del archivo:

 policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} }))) 

Como resultado, mi configuración se ve así:

Lanzamiento del demonio

 sudo brew services start knot-resolver 

Puede verificar si el demonio se inició correctamente utilizando el comando:

 sudo lsof -i -P -n | grep kresd 

El proceso kresd debería escuchar en el puerto 53 en localhost.

Si algo salió mal, mira el registro de errores:

 cat /usr/local/var/log/kresd.log 

Comprobando la operación de resolución

 dig @127.0.0.1 habr.com 

Verifique que la resolución local responda correctamente.

Instalación como sistema de resolución

Si todo funciona correctamente, puede asignar un sistema de resolución en las propiedades del adaptador de red:



UPD

¿Cuál es la diferencia entre DNSCrypt, DNSSEC, DNS sobre TLS / HTTPS?

DNSCrypt puede funcionar en UDP y TCP. Conexión al puerto 443. Para el cifrado, se utiliza su propio protocolo, que difiere de HTTPS. Se puede resaltar fácilmente con DPI. Es más bien un borrador, que fue probado antes de la introducción de DNS sobre TLS / HTTPS, ya que no tiene RFC, es decir, no es un estándar oficial de Internet. Lo más probable es que, pronto, sea completamente reemplazado por este último.

DNS sobre TLS (DoT) : la conexión TCP se produce en el puerto 853, se transmite una solicitud DNS normal dentro del túnel. El proveedor ve que esta es una consulta DNS pero no puede interferir con ella. En igualdad de condiciones, en DNS sobre TLS debería haber un poco menos de sobrecarga para cada solicitud que sobre HTTPS.

DNS sobre HTTP (DoH) : conexión TCP al puerto 443, similar a HTTPS normal. Dentro hay un formato de solicitud diferente, con encabezados HTTP. Sin embargo, para el proveedor, dicha solicitud se verá como una conexión HTTPS normal. Supongo que este protocolo se inventó en caso de que las consultas DNS a servidores extranjeros se bloqueen para enmascarar bajo el tráfico web normal. Y también, para que los navegadores puedan resolver dominios por sí mismos y no crear tráfico anormal.

De hecho, DNS sobre HTTPS y sobre TLS son lo mismo, con un formato de solicitud ligeramente diferente. Ambos protocolos son aceptados como estándares y tienen un RFC. Lo más probable es que en el futuro cercano veremos la distribución masiva de ambos.

DNSSEC es un protocolo para firmar digitalmente registros DNS. No está relacionado con el cifrado, ya que todas las solicitudes se transmiten en texto claro. Puede funcionar sobre el antiguo protocolo DNS clásico, es decir, UDP / TCP en el puerto 53, y dentro de DNS sobre TLS / HTTPS. El propósito de DNSSEC es autenticar un registro DNS. El propietario de un dominio puede agregar una clave pública a los servidores raíz de su zona de dominio y firmar todas las entradas en el asistente del servidor NS. De hecho, a cada registro DNS, por ejemplo, registro A o registro MX, se agrega otro registro del tipo RRSIG que contiene la firma. El procedimiento de validación DNSSEC en un solucionador recursivo le permite establecer si este registro fue realmente creado por el propietario del dominio.

Una comparación más detallada de todos los protocolos dnscrypt.info/faq (párrafo Otros protocolos)