DNS Flag Day con Adrian Almenar

El próximo 1 de febrero tenemos otra fecha clave para DNS, si en Septiembre hablamos del traspaso de la KSK en la zona raíz hoy vamos a comentar el DNS Flag Day.

La verdad es que el día 1 de Febrero, el próximo Viernes será un día interesante ya que los parches que se han ido añadiendo a los DNSs a lo largo de los años dejarán de funcionar si resultan ser no compatibles con el estándar EDNS que regula los mecanismos de extensión.

Todos sabemos como funciona un DNS, todos sabemos cómo resuelve un DNS, pero quizás no conozcáis la problemática que hay con los mecanismos de extensión de DNS, algo tan importante que hará que algunos dominios dejen de funcionar el 1 de Febrero, es decir, el próximo viernes.

Pero tampoco nos lo tomemos a la tremenda, esos dominios solo estarán sin funcionar hasta que se actualice el servidor de DNS, porque actualizar será lo más sencillo.

También tendremos una serie de dominios que seguirán funcionando aún sin soportar el estándar completo, esto se traducirá en incapacidad para asumir nuevas funcionalidades, posibles problemas a futuro, sobre todo de seguridad, etc.

De todos modos está divertido entrar en dnsflagday.net y comprobar dominios de gente, empresas u organismos que conozcáis y descubriréis que gente que le vaya a fallar hay poca, pero gente con problemas muchísimos, podéis dedicarle un rato a curiosear mientras os cuento un poco el tema.

El problema que subyace a todo esto del DNS Flag Day es un problema de tamaño ya que un datagrama UDP tiene un tamaño máximo de 512 bytes.

Aquí seguramente muchos estaréis extrañados, porque 512 no es el tamaño máximo de un datagrama UDP. Lo que pasa es que 512 bytes es el tamaño que garantiza el reensamblado si son fragmentados en tránsito.

IPv4 especifica que cada host debe poder volver a ensamblar paquetes de 576 bytes o menos. Con un encabezado IPv4 (mínimo de 20 bytes y máximo con opciones de 60 bytes) y un encabezado UDP de 8 bytes, un datagrama DNS con una carga útil de 512 bytes será menor que 576 bytes.

Y también es verdad que DNS puede utilizar TCP para cargas grandes y para transferencias de zona y DNSSEC, pero eso añade una latencia innecesaria debido al desafío en tres vías de TCP. ->syn <-ack <-syn ->ack

Esto de todos modos lo podéis leer en el punto 2.3.4 de la RFC 1035 “DOMAIN NAMES – IMPLEMENTATION AND SPECIFICATION” titulado Size Limits donde pone:

labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less

Pues para poder transmitir más información en el año 1999 Paul Vixie, que trabajaba en ISC, se sacó de la manga un estándar titulado “Extension Mechanisms for DNS (EDNS0)”, lo podéis leer en la RFC 2671, luego vino la 2673 y finalmente la 6891, que oh sorpresa está escrita por Vixie, Graff y nuestro buen amigo Joao Damas ya vino a contarnos el traspaso de la KSK en el capítulo 175.

Al principio el objetivo era permitir respuestas más largas sin perder la compatibilidad con lo ya establecido y luego la cosa se fue completando.

Para que esto funcionara no se podía modificar la cabecera de DNS porque ya estaba llena, así que se utilizaron los registros de tipo OPT y es aquí donde indicamos la cantidad de información a transmitir gracias a las 16 opciones adicionales añadidas.

Esto aunque os parezca una cosa sin importancia es vital para DNSSEC ya que no cabe la información en datagramas de 512 bytes.

Pero hay más extensiones, como la identificación de instancia del servidor NSID, identificar desde qué red viene la consulta con Client-Subnet, controlar los timeouts variables con Keep-alive, el mecanismo de seguridad Cookies. En fin hay y habrá más.

El primer problema surge antes de llegar el datagrama porque muchos firewalls filtraban, algunos aún lo hacen, el tamaño máximo de UDP a 512bytes y claro, todos estos datagramas son o eran descartados, mala cosa.

Al permitir datagramas UDP más grandes para los DNSs en los firewalls al final conseguimos facilitar los famosos ataques de amplificación, en los que hacemos una pregunta muy pequeña para recibir una respuesta muy grande.

Todo esto nos ha llevado a utilizar los DNSs de forma poco óptima por culpa de aquellos que no se han adherido a los estándares.

Actualmente tenemos tres problemas principales:

  • DNS autoritativos que bloquean respuestas
  • Malas implementaciones de DNS que no siguen los estándares. Esto provoca entre otras cosas que algunos resolvers tengan que esperar timeout y reintentar con TCP o sin EDNS y claro … va lento.
  • Firewalls mal configurados que bloquean el tráfico que sigue a los estándares

Pero todo esto se solucionará el 1 de Febrero con las nuevas versiones en paralelo de Bind, PowerDNS, Unbound y Knot que dejarán de funcionar con parches históricos para que pudiera funcionar todo el Mundo, hasta los que no seguían los estándares, pero eso se acabó, no se puede seguir avanzando manteniendo parches para aquellos que no han realizado su trabajo.

Además, el cambio del día 1 tiene una cosa muy interesante, no van a caer inocentes, van a fallar aquellos que no se han adaptado al estándar y por desgracia, estos si que no tienen culpa, sus clientes y usuarios.

Enlaces:

https://www.lacnic.net/innovaportal/file/3207/1/edns-flag-day.pdf

2 comments

  1. Hola
    he estado leyendo la RFC 6891 que entiendo es la implentación estándar para EDNS que se requiere los DNS adopten. Pero tengo una duda.. según he interpretado a partir del 1 de Febrero habrá más DNS que soportarán el estándar EDNS y , por tanto, se ‘promueve’ el uso de UDP en queries grandes de DNS sin la necesidad de recurrir a TCP (que puede provocar más latencias). Si esto es así, ¿ por qué en el test público que hay se hace la prueba siguiente: edns512tcp?? Yo casi entiendo que vamos a tender a que no se hagan consultas por TCP… lo pregunto por conocer el impacto si por razones de seguridad elegimos cerrar con nuestros DNS el puerto 53 sobre TCP.
    gRACIAS.

Responder a Eduardo Collado Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.