View on GitHub

DNS flag day 2020

English (US) Le Français Nihongo Español 中文(中国)

¡Gracias!

El DNS flag day 2019 fue un acontecimiento muy exitoso. La comunidad de Internet trabajó en conjunto y corrigió los problemas que causaban demoras en todos los usuarios de Internet. Quisiéramos agradecer a todos los operadores que cooperaron y ayudaron en hacer de Internet un mejor lugar.

Un resumen del “DNS flag day” pasado y de los futuros se puede encontrar en: https://youtu.be/mH_elg9EUWw?t=649.

Contenido

¿Qué viene ahora?

El próximo “DNS flag day” está siendo planificado en estos momentos. Se enfocará en los problemas operacionales y de seguridad en el DNS causados por la fragmentación de los paquetes IP (Internet Protocol).

Por favor suscríbase a la lista de correo dns-announce (en inglés), o siga a @dnsflagday en Twitter para recibir avisos apenas se encuentre disponible más información.

DNS Flag Day 2020

La comunidad DNS ha estado discutiendo persistentemente sobre problemas de interoperabilidad y desempeño del sistema DNS en listas de correo de la industria y en conferencias como el panel de discusión en DNS-OARC 30 (video, diapositivas).

El plan propuesto para el DNS flag day 2020 fue anunciado en RIPE78 por Petr Špaček, CZ.NIC y Ondřej Surý, ISC (video, diapositivas). En esta oportunidad nos enfocaremos en los problemas con la fragmentación IP de los paquetes DNS.

La fragmentación IP es un problema actual en Internet, especialmente cuando se trata de largos mensajes DNS. Pero incluso cuando la fragmentación funciona, puede no ser suficientemente seguro para el DNS.

Estos problemas se solucionan al respetar el tamaño de “buffer” EDNS que no cause fragmentación, y permitiendo que el DNS se traslade desde UDP a TCP cuando no es suficiente con los tamaños grandes de buffer.

Nota: Trabajo en marcha

Este sitio web y algunos aspectos del DNS flag day 2020 son aún un trabajo en progreso.

No obstante, los requisitos técnicos ya son lo suficientemente claros como para que los operadores y desarrolladores puedan comenzar a preparse, haciendo pruebas y corrigiendo sus sistemas.

Si tiene comentarios o sugerencias por favor únase a la discusión en la lista de correo dns-operations.

Acción: Operadores de DNS Autoritativos

En el lado autoritativo, lo que debería hacer para solucionar estos problemas es responder consultas DNS sobre TCP (puerto 53). ¡Recuerde revisar también su(s) cortafuegos (firewalls)!

También debería usar un tamaño de buffer EDNS que no cause fragmentación. El valor recomendado es alrededor de 1220 bytes, pero está aún en discusión.

Y por último, ¡los servidores DNS Autoritativos NO DEBEN enviar respuestas más grandes que el tamaño del buffer EDNS solicitado!

¡NUEVO! Ya puede revisar su dominio ingresándolo acá abajo y presionando “Test!”. Esta herramienta de prueba usa el EDNS Compliance Tester de ISC y revisará que la prueba edns512tcp es exitosa, entre otras pruebas de compatibilidad general.

Pruebe su dominio


Acción: Operadores de DNS Resolutor

En el lado del resolutor (“resolver”), son más o menos los mismos requisitos que para el autoritativo: responder consultas DNS sobre TCP (puerto 53) y usar un tamaño de buffer EDNS que no cause fragmentación (~1220 bytes). ¡Recuerde revisar su(s) cortafuegos (firewalls)!.

Y por último es muy importante que ¡los resolutores DEBEN repetir sus consultas sobre TCP si reciben una respuesta UDP truncada (con el bit TC=1 encendido)!

¡El sitio de pruebas para clientes de un resolutor DNS está en desarrollo!

Acción: Proveedores de software DNS

Como proveedor de software DNS es importante ser compatible con los estándares y usar un tamaño por defecto de buffer EDNS (~1220) que no cause fragmentación.

Los estándares relevantes son principalmente los RFC 7766, RFC 6891 sección 6.2.3. y RFC 6891 sección 6.2.4..

La motivación para el cambio está descrita en el IETF draft intarea-frag-fragile section 6.1 y IETF draft iab-protocol-maintenance.

¿Cómo probar?

Si es titular de un nombre de dominio u operador de un DNS autoritativo, puede usar nuestra herramienta de pruebas basada en web para revisar un dominio. La puede encontrar en la sección Acción: Operadores de DNS Autoritativos.

Estamos trabajando en una herramienta de pruebas basada en web para clientes y operadores de resolutores DNS. Una vez que esté lista la podrán encontrar en esta página.

También puede probar usando los siguientes comandos CLI:

$ dig +tcp @auth_IP yourdomain.example.
$ dig +tcp @resolver_IP yourdomain.example.
$ dig @resolver_IP test.knot-resolver.cz. TXT

Todas las consultas DNS deben ser exitosas, y los comandos con la opción +tcp y sin ella deben retornar lo mismo. Si es un proveedor de servicio también puede probar sus servicios autoritativos y resolutores activando DNS sobre TCP y cambiando la configuración con el tamaño por defecto de buffer EDNS:

La configuración indicada no ocasionará cambios visibles en caso que todo funcione correctamente, pero algunas consultas fallarán en su resolución si el transporte TCP no está disponible.

Flag days anteriores

Esta es una lista de los “flag days” anteriores:

¿Quién está detrás del DNS flag day?

El esfuerzo DNS Flag Day está empujado por la comunidad de proveedores de software y servicios DNS, y es apoyado por El Centro de Operaciones, Análisis e Investigación del DNS (DNS-OARC) del cual la mayoría de la comunidad es miembro.

Si tiene consultas técnicas acerca del DNS flag day, puede unirse a la lista de correo DNS-operations y preguntar ahí (solo en inglés).

Contacto

Para consultas de prensa y medios, por favor utilice el correo media (at) dns-oarc.net y por favor incluya el texto “DNS Flag Day” en el asunto (“subject”) del correo.

Apoyan

FAQ