AdGuard DNS ahora es compatible con Structured DNS Errors. Descubre qué significa esto

El lanzamiento de AdGuard DNS v2.10 puede compararse con la implementación de DNS-over-QUIC: una vez más, AdGuard DNS se ha convertido en el primer resolvedor de DNS público en implementar una nueva funcionalidad antes de que se convierta en el estándar oficial. Esta vez, estamos hablando de los Structured DNS Errors.

A continuación, entraremos en detalles sobre qué es esta funcionalidad y por qué es importante. Sin embargo, si no tienes mucho tiempo para esto, aquí tienes un resumen:

• Cuando un sitio web está bloqueado a nivel de DNS, los usuarios pueden ver un error como “Este sitio no se puede acceder” o “Sin conexión a Internet”, lo cual no explica la razón del bloqueo.

• Para aclarar esto, los servidores DNS podrían redirigir a los usuarios a una página propia con una explicación. Sin embargo, los sitios HTTPS (que son la mayoría de los sitios web) requerirían un certificado separado.

• Existe una solución más simple: los Structured DNS Errors (SDE). Esto permite que información adicional (como el motivo del bloqueo, la entidad responsable e información de contacto) sea enviada en la respuesta DNS para que el navegador pueda leerla y transmitirla al usuario, mejorando considerablemente la transparencia de la comunicación.

• Para que este sistema funcione, los navegadores deben ser compatibles con SDE. Eso es lo que queremos para el futuro.

¿Qué son los Structured DNS Errors? Un análisis detallado

El filtrado a nivel DNS es ampliamente utilizado. Solo AdGuard DNS tiene más de 100 millones de usuarios. Las personas usan el filtro DNS para bloquear anuncios y rastreadores o para proteger a sus hijos. Incluso si el usuario no ha configurado el DNS manualmente, aún podría encontrarse con un filtro DNS debido a las políticas de su país o empresa. Es seguro asumir que casi todos los usuarios de Internet se han encontrado con un bloqueo de DNS.

El bloqueo a nivel de DNS impide el acceso a un dominio completo. El usuario intenta visitar https://ejemplo.com, el navegador hace una solicitud DNS, y el servidor DNS responde que el dominio ejemplo.com está bloqueado, lo que provoca que el navegador muestre “Este sitio no se puede acceder” o “Sin conexión a Internet”.

Si el usuario no ha bloqueado manualmente este dominio, podría no entender por qué no puede abrir la página. Puede preguntarse:

• ¿Algo está mal? ¿Debería recargar la página?

• Esto no funcionó. ¿Se cayó la conexión a Internet?

• La conexión a Internet está funcionando. ¿Se bloqueó la página? ¿Por qué?

• Tal vez mi servicio de DNS esté caído. ¿Debería reportarlo?

Esta falta de comunicación entre el servicio de DNS y el usuario es un problema. Los servicios de DNS pueden y quieren resolver esto, por ejemplo, redirigiendo al usuario a una página con una explicación más detallada para que sepa qué ocurrió y a quién contactar. ¿Por qué no hacerlo?

Aquí está el problema:

• Si el sitio es HTTP, es decir, la conexión no está cifrada, el servidor DNS puede redirigir al usuario con seguridad a una página no cifrada.
• Si es un sitio HTTPS, el navegador realiza la autenticación del certificado y espera ver un certificado válido para https://ejemplo.com. Si AdGuard DNS redirige a su propia página, el navegador mostrará un error de validación de certificado.

Una solución sería instalar un certificado especial en el dispositivo del usuario. Sin embargo, esto no siempre es posible ni seguro. Hay una manera mucho más sencilla: enviar más información en la respuesta DNS.

Para esto, se introdujo el estándar de Errores DNS Extendidos en 2020, lo que permite que las respuestas DNS incluyan un código de error junto con un campo EXTRA-TEXT para detalles adicionales. La idea de los Structured DNS Errors también propone la adición de archivos I-JSON (un perfil restringido de JSON) en el campo EXTRA-TEXT, los cuales los navegadores pueden leer fácilmente y mostrar de manera amigable para el usuario.

¿Qué contendrían estos archivos I-JSON?

• Motivo del bloqueo

• Información de contacto para aclaraciones, en caso de que la página haya sido bloqueada por error

• Organización responsable del filtro DNS en este caso (opcional)

• Otras informaciones opcionales

Esto es realmente conveniente. Un sistema como este mejora la transparencia entre los servicios de DNS y los usuarios y mantiene a los usuarios seguros. Si entienden el motivo del bloqueo de un sitio, es menos probable que abandonen un servidor DNS seguro por uno no cifrado.

¿Qué se necesita para implementar los Extended DNS Errors y los Structured DNS Errors?

Los navegadores deben ser compatibles, ya que son ellos quienes determinan qué información verá el usuario. Si es solo un error de conexión o una explicación detallada sobre el motivo del bloqueo del sitio y qué hacer a continuación.

Por eso, pedimos a los representantes de los navegadores que agreguen soporte para el RFC8914 y, idealmente, su actualización propuesta. Este cambio ayudará a hacer que Internet sea más transparente y amigable para miles de millones de personas.

¿Cómo funciona esto en AdGuard DNS?

Hemos creado una extensión de demostración que muestra cómo podrían funcionar los Structured DNS Errors en caso de que los navegadores sean compatibles. Con esta extensión, si intentas visitar un sitio bloqueado por AdGuard DNS, leerá la información enviada a través de SDE y mostrará una página de explicación bien presentada. Mucho más fácil de entender que los ejemplos anteriores, ¿verdad?

Puedes instalar la extensión en la Chrome Web Store o en GitHub.

Otras mejoras: una experiencia más personalizada para usuarios y organizaciones

Nuestro público incluye tanto individuos configurando el DNS para sus hogares como grandes organizaciones. Tienen necesidades y experiencias diferentes: algunos necesitan conectar 10 dispositivos y están bien con la configuración manual; otros necesitan conectar 1,000 dispositivos y prefieren la automatización. Para entender mejor las necesidades de cada usuario, agregamos una encuesta de integración para recopilar información sobre los objetivos y el número esperado de dispositivos.

Esto nos ayudará a personalizar el DNS en el futuro, por ejemplo, proporcionando más información sobre opciones de automatización para aquellos que lo necesiten.

Nos encantaría escuchar tu opinión

Como siempre, te invitamos a dejar tus comentarios y compartir tus pensamientos en las redes sociales o en GitHub.