Menú Cerrar

DNS Flag Day 2020: El tamaño de los mensajes en el DNS

Por Hugo Salgado, ingeniero de investigación y desarrollo en NIC Chile

Acuerdo técnico y operacional para el DNS

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 la ubicuidad del DNS lo hacen atractivo para mucho más que preguntar por direcciones IP. En efecto, en el DNS también se guardan 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 caché, etc.

Este incremento en el uso del protocolo DNS y las expectativas de modernización en su funcionamiento obligan a la industria a realizar esfuerzos conjuntos para ir empujando cambios que permitan su crecimiento. Como 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 acatan los protocolos. Pero sí existe el acuerdo técnico y operacional de ir respetando y adecuándose a los estándares.

Dado que el origen del DNS se remonta a los comienzos de Internet, es difícil realizar cambios coordinados a escala global. Además, por tratarse de un sistema crítico y fundamental, se debe tener muchísimo cuidado. Por lo tanto, cualquier despliegue de nuevos 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 asegurar la compatibilidad con centenares de implementaciones e infraestructuras.

Desde 2019, se ha organizado un consorcio entre las organizaciones más importantes que desarrollan software y dan servicio DNS, que ha acordado ciertos pasos para, finalmente, ir dando de baja comportamientos fuera del estándar con el propósito de hacer un frente unido que permita castigar a los que hacen las cosas de forma incorrecta. Entre estas organizaciones, se incluye la empresa ISC (creador del software BIND, el más utilizado en Internet), Infoblox, Bluecat, PowerDNS; y proveedores como Google DNS, Quad9, etc.

Primera campaña del DNS Flag Day

Esta agrupación realizó la primera campaña “DNS Flag Day” el 1 de febrero de 2019. En aquella ocasión, se atacaron 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 las extensiones al DNS (EDNS). 

Los creadores de software para el DNS siempre se encuentran en la disyuntiva de saber hasta dónde se puede ser permisivo con ciertas desviaciones de los estándares porque entienden que al ser muy estrictos, también pueden afectar la universalidad y adecuación a distintas realidades operacionales. Además, deben tener en cuenta la creación de incentivos perversos: basta con que una implementación popular 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. Por esto, el DNS Flag Day 2019 fue un acuerdo conjunto para 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.

DNS Flag Day 2020

El DNS Flag Day 2020 trata sobre el tamaño de los mensajes en el DNS. En un comienzo, los mensajes debían caber dentro de 512 bytes, lo que era suficiente para esos tiempos. No obstante, actualmente este tamaño se está quedando corto. Desde hace más de 15 años, existe un mecanismo de negociación en el DNS que permite hacer crecer los mensajes a tamaños muchísimos más grandes (en teoría, hasta 65.536 bytes) y así logra llevar 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 utilizada para separar un mensaje en “fragmentos” −un mecanismo que siempre ha estado disponible para la comunicación en Internet− no está funcionando adecuadamente e incluso supone riesgos de seguridad importantes. Por ello, se ha acordado que el DNS Flag Day 2020 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 prohibirá la fragmentación de estos paquetes en el caso de que se detecten problemas en el camino. Si existe la necesidad de mandar más datos que los que defina esta negociación, se deberá 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 se realizará el 1 de octubre de este año y tendrá 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 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 empiecen a instalar y actualizar los servicios DNS, este comportamiento se propagará a toda la red.

¿Qué deben tener en cuenta los operadores de servicios DNS?

En primer lugar, los operadores de servicios DNS deben mantener actualizado su software. Esto es muy importante no 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 este sentido, se debe 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. Esta creencia, en realidad, fue un malentendido histórico porque el protocolo, desde sus inicios, permitió el uso de ambos transportes. En cualquier caso, se han actualizado los estándares para hacer más claro este comportamiento 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 resolutores que permiten la navegación de los clientes. Es importante que revisen sus infraestructuras y que, en caso de tener que adecuarse, se realicen los ajustes en un tiempo prudente. Mantener un funcionamiento inadecuado ocasionará cada vez más problemas en el largo plazo y podrá llegar incluso a la interrupción de la comunicación en un futuro cercano.

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

Hugo Salgado
Investigación y desarrollo, NIC Chile