Introducción y planteamiento del problema
En el presente documento queremos discutir sobre un draft (borrador de trabajo para convertirse en un estándar) existente en IETF que llamó nuestra atención, es un documento que involucra dos mundos muy interesantes: IPv6 y DNS. Este draft introduce algunas mejores prácticas para el transporte de DNS sobre IPv6.
El draft se titula “DNS over IPv6 Best Practices” y se puede encontrar aquí.
¿De qué trata el documento y qué busca solucionar?
El documento describe un enfoque sobre cómo el Protocolo de Nombres de Dominio (DNS) debería transmitirse sobre IPv6 [RFC8200].
Se han identificado algunos problemas operativos al enviar paquetes de DNS a través de IPv6, el draft busca solucionar estos problemas.
Contexto técnico
El protocolo IPv6 exige un tamaño mínimo de unidad de transmisión (MTU) de 1280 octetos. Según la Sección 5 “Problemas de tamaño de paquete” del RFC8200, se establece que cada enlace en Internet debe tener un MTU de 1280 octetos o más. Si un enlace no puede transmitir un paquete de 1280 octetos en una sola pieza, se debe proporcionar el servicio de fragmentación y reensamblaje específicos del enlace en una capa inferior a IPv6.
Utilizando el Descubrimiento de MTU de Ruta (PMTUD) y la fragmentación en IPv6 (solo en el origen), se pueden enviar paquetes más grandes. Sin embargo, la experiencia operativa indica que enviar grandes paquetes de DNS sobre UDP en IPv6 resulta en altas tasas de pérdida. Algunos estudios -ya de muchos años, pero sirven de contexto- han encontrado que aproximadamente 10% de los routers en IPv6 descartan todos los fragmentos IPv6, y 40% de ellos bloquean los mensajes “Packet Too Big”, que hacen imposible la negociación de los clientes. (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)
La mayoría de los protocolos de transporte modernos, como TCP [TCP] y QUIC [QUIC], incluyen técnicas de segmentación que permiten enviar flujos de datos más grandes sobre IPv6.
Un poco de historia
El Sistema de Nombres de Dominio (DNS) fue definido originalmente en los documentos RFC 1034 y RFC 1035. Está diseñado para funcionar sobre diferentes protocolos de transporte, incluyendo UDP y TCP, y más recientemente se ha extendido para operar sobre QUIC. Estos protocolos de transporte pueden utilizarse tanto en IPv4 como en IPv6.
Al diseñar el DNS, se estableció un límite en el tamaño de los paquetes DNS transmitidos por UDP a 512 bytes. Si un mensaje era más largo, se truncaba y se activaba el bit de Truncamiento (TC) para indicar que la respuesta estaba incompleta, permitiendo que el cliente intentara nuevamente con TCP.
Con este comportamiento original, UDP sobre IPv6 no excedía el MTU (unidad máxima de transmisión) del enlace IPv6, evitando problemas operativos por fragmentación. Sin embargo, con la introducción de las extensiones EDNS0 (RFC6891) se amplió el máximo hasta un teórico de 64KB, con lo que algunas respuestas superaban el límite de 512 bytes para UDP, lo que resultó en tamaños que podrían exceder el Path MTU, ocasionando conexiones TCP y afectó la escalabilidad de los servidores DNS.
Hablemos de DNS sobre IPv6
DNS sobre IPv6 está diseñado para funcionar sobre UDP, así como TCP o QUIC. UDP solo proporciona puertos de origen y destino, un campo de longitud y una suma de verificación simple, y es un protocolo sin conexión. En contraste, TCP y QUIC ofrecen características adicionales como segmentación de paquetes, confiabilidad, corrección de errores y estado de conexión.
El funcionamiento de DNS sobre UDP en IPv6 es adecuado para tamaños de paquete pequeños, pero se vuelve menos confiable con tamaños más grandes, especialmente cuando se requiere fragmentación de datagramas IPv6.
Por otro lado, DNS sobre TCP o QUIC en IPv6 funciona bien con todos los tamaños de paquete. Sin embargo, el uso de un protocolo con estado como TCP o QUIC exige más recursos del servidor DNS (y otros equipos como Firewall, DPIs, IDS, etc), lo que puede afectar la escalabilidad. Esta puede ser una compensación razonable para servidores que necesitan enviar paquetes de respuesta DNS más grandes.
La sugerencia del draft en cuanto a DNS sobre UDP recomienda limitar el tamaño de los paquetes de DNS sobre UDP en IPv6 a 1280 octetos. Esto evita la necesidad de fragmentación IPv6 o el descubrimiento del MTU del camino (Path MTU Discovery), lo que asegura una mayor confiabilidad.
La mayoría de las consultas y respuestas DNS encajarán dentro de este límite de tamaño de paquete y, por lo tanto, se pueden enviar a través de UDP. Los paquetes DNS más grandes no deben enviarse por UDP; en su lugar, deben ser enviados a través de TCP o QUIC, como se menciona en la siguiente sección.
DNS sobre TCP y QUIC
Cuando se necesitan transportar paquetes DNS más grandes, se recomienda utilizar DNS sobre TCP o QUIC. Estos protocolos manejan la segmentación y ajustan de manera confiable su tamaño de segmento para diferentes valores de MTU del enlace y del camino, lo que los hace mucho más fiables que el uso de UDP con fragmentación IPv6.
La sección 4.2.2 del [RFC1035] describe el uso de TCP para transportar mensajes DNS, mientras que el [RFC9250] explica cómo implementar DNS sobre QUIC para proporcionar confidencialidad en el transporte. Además, los requisitos operativos para DNS sobre TCP están descritos en el [RFC9210].
Seguridad
El cambio de UDP a TCP/QUIC para respuestas grandes implica que el servidor DNS debe mantener un estado adicional para cada consulta recibida a través de TCP/QUIC. Esto consumirá recursos adicionales en los servidores y afectará la escalabilidad del sistema DNS. Además, esta situación puede dejar a los servidores vulnerables a ataques de Denegación de Servicio (DoS).
¿Esta es la manera correcta?
A pesar de que sí creemos que esta solución aportará muchos beneficios al ecosistema de IPv6 y DNS, se trata de un parche operativo temporal, pero que no resuelve la solución de raíz.
Creemos que la solución correcta es que la fragmentación en el origen funcione, que PMTUD no se encuentre roto en el camino, y que las cabeceras de fragmentación sean permitidas por los dispositivos de seguridad. Esto requiere de cambios en distintos actores de Internet que puede tomar bastante tiempo, pero no por eso debemos abandonar la educación y los esfuerzos por lograr hacer lo correcto.
