El protocolo de mensajes DNS en Internet se compone de paquetes de información que permiten a los clientes recibir respuesta a sus consultas, como por ejemplo, “¿cuál es la dirección IPv6 de www.example.com?” o “¿dónde se reciben los correos enviados a @gmail.com?”.

El éxito y ubicuidad del DNS lo hacen atractivo para mucho más que preguntar por direcciones IP. Es así como también se guarda en el DNS datos de configuración de correo, llaves de conexión ssh, certificados digitales para sitios web, etc. Además existen registros que permiten el funcionamiento interno del DNS como las delegaciones a subdominios, firmas criptográficas, información de cache, etc.

Es este crecimiento en el uso del protocolo DNS y las expectativas de modernización en su funcionamiento las que obligan a realizar esfuerzos conjuntos de la industria para ir empujando cambios que permitan su crecimiento. Como todos sabemos, en Internet todo funciona gracias a acuerdos y consenso. No existe un gobierno de Internet ni una policía que castigue a los que no respetan los protocolos. Pero sí existe el acuerdo técnico y operacional de ir respetando y adecuándose a los estándares.

En el ámbito del DNS, su origen en los comienzos de Internet hacen difícil realizar cambios coordinados a escala global. Además por tratarse de un sistema crítico y fundamental, hay que tener muchísimo cuidado. Es por esto que cualquier despliegue de nuevas componentes en el DNS se mide en años -sino décadas- y los desarrolladores de software DNS deben tener en cuenta muchos casos de borde para ser compatible con centenares de implementaciones e infraestructuras.

Desde el año 2019 se ha organizado un consorcio de las organizaciones más importantes que desarrollan software y dan servicio DNS, que han acordado ciertos pasos que permitan por fin ir dando de baja comportamientos fuera del estándar, de tal forma de hacer un frente unido que permita castigar a los que hacen las cosas de forma incorrecta.

El día 1 de febrero de 2019 se realizó la primera campaña “DNS Flag day” por esta agrupación. Lo primero que se atacó fueron los diversos “parches” que se fueron armando a través del tiempo en los software DNS, para intentar dar respuesta a implementaciones que estaban fuera del estándar de extensiones al DNS (EDNS). Los creadores de software para DNS siempre se encuentran en la disyuntiva de saber hasta dónde se puede ser permisivo con ciertas desviaciones de los estándares, en el entendido que ser muy estricto también atenta con la universalidad y adecuación a distintas realidades operacionales. Además se da el incentivo perverso que basta una implementación popular que se aleje del estándar para que luego las demás se vean en la obligación de seguirla, y no ocasionar comparaciones en el funcionamiento entre distintas herramientas. Es por esto que el DNS Flag Day fue un acuerdo conjunto de dejar de soportar estos parches, y castigar las malas implementaciones con un error de funcionamiento que las obligara por fin a respetar el estándar.

La campaña fue un éxito y distintas mediciones han demostrado que hoy el DNS es un lugar mejor que el que era. Un sistema DNS sin parches es más simple, elegante, fácil de mantener, y permite seguir creciendo.

Es entonces el momento de dar un siguiente paso, y atacar el siguiente problema.

En este caso se trata del tamaño de los mensajes en el DNS. En un comienzo los mensajes debían caber dentro de 512 bytes, lo que era suficiente en esos tiempos, pero que ahora claramente está quedando corto. Desde hace más de 15 años existe un mecanismo de negociación en el DNS que permite crecer a tamaños muchísimos más grandes (en teoría, hasta 65.536 bytes) y es lo que permite ahora llevar en mensajes DNS mucha más información que antes.

Sin embargo, hay ciertas limitantes en la capa de transporte del DNS más utilizada (la capa UDP) que hacen compleja esta negociación del tamaño, y que no dependen de información que tenga ninguno de los dos extremos de la comunicación. Además diversas mediciones han demostrado que la técnica de separar un mensaje en “fragmentos” -un mecanismo que siempre ha estado disponible para la comunicación en Internet- no está funcionando e incluso tiene riesgos de seguridad importantes. Es por esto que se ha acordado para el DNS Flag Day 2020 el definir un tamaño por defecto de funcionamiento de 1.232 bytes en la comunicación -que también puede ser negociable hacia arriba o abajo por ambos extremos- y que se prohíba la fragmentación de estos paquetes en caso de problemas en el camino. Si existe la necesidad de mandar más datos que los que defina esta negociación, se debe cambiar al protocolo de transporte TCP (el mismo utilizado para el web), que pese a ser menos eficiente que el protocolo UDP, no tiene límite en tamaño.

El DNS Flag Day 2020 busca entonces dos objetivos:

  • definir un tamaño de paquete DNS por defecto de 1.232 bytes, que evite su fragmentación; y
  • obligar el cambio a transporte TCP para los casos cuando se necesite enviar más información.

Para esto, el consorcio de desarrolladores de software DNS comenzará a publicar nuevas versiones de sus sistemas que consideren estos dos comportamientos. A medida que todos los actores en Internet comiencen a instalar y actualizar los servicios DNS, este comportamiento se propagará a toda la red.

Entonces, ¿qué es importante a tener en cuenta por los operadores de servicios DNS? Lo primero es a mantener actualizados sus softwares. Esto es muy importante no tan solo por estos cambios, sino porque un software antiguo está afecto a problemas de rendimiento, operación e incluso seguridad.

Además hay que estar seguros de no tener firewalls o dispositivos de filtrado en la red que impidan este nuevo comportamiento. En esto es muy importante volver a destacar la importancia de permitir la comunicación TCP del DNS. Aún existe la idea en algunos administradores de sistemas que el protocolo DNS funciona solo en UDP, y que por seguridad es mejor bloquear TCP. Eso en realidad fue un malentendido histórico, porque el protocolo desde sus inicios permitía el uso de ambos transportes. En cualquier caso, se han actualizado los estándares para hacer más claro este comportamiente, y hacer absolutamente obligatorio el uso de TCP para cualquier participante del sistema DNS.

El mismo consorcio ha creado herramientas que permiten realizar pruebas directas a los servidores DNS tanto autoritativos de nombres de dominio, como a los resultores que permiten la navegación de clientes. Es importante que revisen sus infraestructuras y que en caso de tener que adecuarse, se realice en un tiempo prudente. Mantener un funcionamiento inadecuado ocasionará a la larga cada vez más problemas, llegando incluso a la interrupción de la comunicación en un futuro cercano.

Es tarea de todos mantener la Internet sana, moderna y segura.


Next post: La mala práctica de “localhost” en dominios

Previous post: Cómo Leer un RFC