Hispanopedia Wiki
Articulo de referencia

Mecanismos de extensión para DNS

Mecanismos de extensión para DNS ( EDNS ) es una especificación para expandir el tamaño de varios parámetros del protocolo del Sistema de nombres de dominio (DNS) que tenían res...

Hispanopedia WikiContenido en espanolLectura gratuita

Mecanismos de extensión para DNS ( EDNS ) es una especificación para expandir el tamaño de varios parámetros del protocolo del Sistema de nombres de dominio (DNS) que tenían restricciones de tamaño que la comunidad de ingeniería de Internet consideró demasiado limitadas para aumentar la funcionalidad del protocolo. El primer conjunto de extensiones fue publicado en 1999 por el Grupo de Trabajo de Ingeniería de Internet como RFC 2671 , también conocido como EDNS0 . [ 1 ] Fue actualizado en 2013 por RFC 6891 , cambiando ligeramente el acrónimo a EDNS(0) . [ 2 ]  

Motivación

El Sistema de Nombres de Dominio (DNS) se desarrolló por primera vez a principios de la década de 1980. Desde entonces, se ha ido mejorando progresivamente con nuevas funciones, manteniendo la compatibilidad con versiones anteriores del protocolo.

Las restricciones en el tamaño de varios campos de indicadores, códigos de respuesta y tipos de etiquetas disponibles en el protocolo DNS básico impedían la compatibilidad con algunas características deseables. Además, los mensajes DNS transmitidos por UDP estaban restringidos a 512 bytes, sin considerar el Protocolo de Internet (IP) ni las cabeceras de la capa de transporte . [ 3 ] Recurrir a un transporte de circuito virtual , utilizando el Protocolo de Control de Transmisión (TCP), aumentaría considerablemente la sobrecarga. Esto representó un obstáculo importante para agregar nuevas características a DNS. En 1999, Paul Vixie propuso extender DNS para permitir nuevos indicadores y códigos de respuesta, y para brindar soporte para respuestas más largas en un marco que fuera retrocompatible con implementaciones anteriores.

Mecanismo

Dado que no se podían agregar nuevas banderas en el encabezado DNS, EDNS agrega información a los mensajes DNS en forma de pseudo- registros de recursos ("pseudo-RR") incluidos en la sección de "datos adicionales" de un mensaje DNS. Cabe destacar que esta sección está presente tanto en las solicitudes como en las respuestas.

EDNS introduce un único tipo de pseudo-RR: OPT.

Como pseudo-RR, los RR de tipo OPT nunca aparecen en ningún archivo de zona; solo existen en mensajes fabricados por los participantes del DNS.

El mecanismo es retrocompatible, ya que los respondedores DNS más antiguos ignoran cualquier RR de tipo OPT desconocido en una solicitud, y un respondedor DNS más reciente nunca incluye un OPT en una respuesta a menos que haya uno en la solicitud. La presencia del OPT en la solicitud indica que el solicitante es más reciente y sabe qué hacer con un OPT en la respuesta.

El pseudoregistro OPT proporciona espacio para hasta 16 indicadores y amplía el espacio para el código de respuesta. El tamaño total del paquete UDP y el número de versión (actualmente 0) se encuentran en el registro OPT. Un campo de datos de longitud variable permite registrar información adicional en futuras versiones del protocolo. El protocolo DNS original proporcionaba dos tipos de etiquetas, que se definen mediante los dos primeros bits del octeto de longitud de una etiqueta (RFC 1035): 00 (etiqueta estándar) y 11 (etiqueta comprimida). EDNS introduce el tipo de etiqueta 01 como etiqueta extendida . Los 6 bits inferiores del primer byte pueden utilizarse para definir hasta 63 nuevas etiquetas extendidas.

Ejemplo

Un ejemplo de un pseudo-registro OPT, tal como lo muestra el comando dig :

;; PSEUDOSECCIÓN OPT: ; EDNS: versión: 0, indicadores: hacer; udp: 4096

El resultado de "EDNS: versión: 0" indica conformidad total con EDNS0. [ 4 ] El resultado "flags: do" indica que "DNSSEC OK" está configurado. [ 5 ]

Aplicaciones

DNSSEC

EDNS es esencial para la implementación de las Extensiones de Seguridad DNS ( DNSSEC ). [ 6 ]

Relleno EDNS

Existen estándares para el uso de EDNS que establecen la cantidad de relleno que debe haber alrededor de un mensaje DNS. [ 7 ] [ 8 ] El relleno es esencial al cifrar DNS, ya que sin él podría ser posible determinar el nombre de dominio consultado a partir del tamaño cifrado de la consulta.

EDNS Keepalive

EDNS se utiliza para indicar cuánto tiempo debe mantenerse activa una conexión TCP. [ 9 ]

Subred de cliente EDNS (ECS)

EDNS también se utiliza para enviar información general desde los resolvedores a los servidores de nombres sobre la ubicación geográfica de los clientes en forma de la opción EDNS Client Subnet (ECS). [ 10 ]

Asuntos

En la práctica, pueden surgir dificultades cuando EDNS atraviesa cortafuegos, ya que algunos cortafuegos asumen una longitud máxima de mensaje DNS de 512 bytes y bloquean los paquetes DNS más largos.

La introducción de EDNS hizo posible el ataque de amplificación de DNS , un tipo de ataque de denegación de servicio reflejado , ya que EDNS facilita paquetes de respuesta muy grandes en comparación con paquetes de solicitud relativamente pequeños.

Referencias

  1. ↑ RFC 2671 , Mecanismos de extensión para DNS (EDNS0) , P. Vixie, The Internet Society (agosto de 1999) 
  2. ↑ RFC 6891 , Mecanismos de extensión para DNS (EDNS(0)) , J. Damas, M. Graff, P. Vixie, (abril de 2013) 
  3. ↑ RFC 1035, Nombres de dominio: implementación y especificación , P. Mockapetris (noviembre de 1987)
  4. ↑ Grupo de Trabajo de Redes del IETF, agosto de 1999, RFC 2671: Mecanismos de extensión para DNS (EDNS0), página 3, La conformidad total con esta especificación se indica con la versión "0".
  5. ↑ Grupo de Trabajo de Redes del IETF, diciembre de 2001, RFC 3225: Indicación de la compatibilidad del resolvedor con DNSSEC, página 3. El mecanismo elegido para la notificación explícita de la capacidad del cliente para aceptar (si no comprender) los registros de recursos de seguridad DNSSEC utiliza el bit más significativo del campo Z en el encabezado OPT EDNS0 de la consulta. Este bit se denomina bit "DNSSEC OK" (DO).
  6. ↑ RFC 4035, Modificaciones del protocolo para las extensiones de seguridad DNS , R. Arends, Telematica Instituut, 2005. Sección 4.1 Soporte EDNS
  7. ↑ Mayrhofer, Alexander (mayo de 2016). "RFC 7830: La opción de relleno EDNS(0)" . tools.ietf.org . Consultado el 2 de febrero de 2018 .
  8. ↑ Mayrhofer, Alexander (octubre de 2018). "RFC 8467: Políticas de relleno para mecanismos de extensión para DNS (EDNS(0))" . tools.ietf.org . Consultado el 1 de octubre de 2018 .
  9. ↑ Wouters, Paul (abril de 2016). "RFC 7828: La opción EDNS0 edns-tcp-keepalive" . tools.ietf.org . Consultado el 2 de febrero de 2018 .
  10. ↑ Contavalli, Carlo (mayo de 2016). "RFC 7871: Subred del cliente en consultas DNS" . tools.ietf.org . Consultado el 2 de febrero de 2018 .

Véase también