Dentro de un mensaje DNS: indicadores, secciones y formato

Toda consulta DNS, desde un navegador que pide una dirección hasta un resolvedor que persigue una delegación, es un mensaje binario corto con un formato común. Rara vez se ven los bytes, pero herramientas como dig imprimen los campos de la cabecera como texto, y saber qué significan convierte esa salida de ruido en evidencia. El formato está especificado por la RFC 1035 desde 1987, que perfeccionó la RFC 883 de 1983, y desde entonces se ha ampliado, no sustituido.

La cabecera de 12 bytes

Todo mensaje empieza con los mismos 12 bytes: un ID de 16 bits, una palabra de 16 bits con indicadores y códigos, y cuatro contadores de 16 bits.

Después de la cabecera vienen las cuatro secciones, en ese orden. La sección de pregunta repite lo que se preguntó, la sección de respuesta contiene los registros que la responden, la sección de autoridad señala los servidores de nombres responsables de la zona y la sección adicional lleva registros extra que el servidor espera que el cliente necesite a continuación, como las direcciones de esos servidores de nombres.

Conviene tratar AA con cuidado. Un resolvedor recursivo que responde desde su caché no es una autoridad para esos datos y no lo activa. En el diseño original, un servidor marca una respuesta como autoritativa cuando responde con datos de zona que posee, a diferencia de los datos en caché (Mockapetris y Dunlap, 1988). Ver aa en una respuesta de uno de los servidores de nombres de la propia zona es lo normal, salvo en una referencia a una zona hija, que no lo lleva ni siquiera cuando procede de un servidor autoritativo.

Cómo leer la línea de cabecera de dig

dig imprime la cabecera en dos líneas. Una respuesta típica tiene este aspecto:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

opcode y status son los campos Opcode y RCODE. La línea flags enumera los bits activados, aquí qr, rd y ra, que juntos significan: una respuesta, a una consulta que pidió recursión, de un servidor que la ofrece. Los cuatro contadores son los tamaños de las secciones. El ADDITIONAL: 1 suele ser el pseudorregistro EDNS del servidor, devuelto porque dig incluye uno en su consulta; no es una dirección adicional.

El estado es lo más rápido de leer. La RFC 1035 define seis códigos de respuesta.

Un resultado frecuente no tiene código propio. Un nombre que existe pero no tiene ningún registro del tipo que pediste devuelve NOERROR sin registros de ese tipo en la sección de respuesta (aun así puede aparecer un CNAME), y la RFC 2308 lo llama NODATA. La diferencia importa al diagnosticar; consulta NXDOMAIN explicado y Timeout de DNS frente a SERVFAIL para saber qué hacer en cada caso.

Una consulta, byte a byte

Esta es una consulta completa del registro A de example.com en su forma clásica, sin EDNS, tal como la enviaría un cliente que pide recursión. Mide 29 bytes.

1a 2b 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01

Los mismos bytes viajan dentro de los transportes cifrados. En DNS sobre HTTPS (RFC 8484), por ejemplo, el mismo mensaje viaja como cuerpo en bruto de un POST HTTP o, en una solicitud GET, codificado en base64url dentro de un parámetro dns, y se aconseja a los clientes poner el ID a 0; consulta DNS sobre HTTPS y DNS sobre TLS explicados.

Nombres, límites y compresión

Un nombre es una secuencia de etiquetas, cada una precedida por su longitud, que termina en un byte cero. La RFC 1035 limita una etiqueta a 63 octetos y un nombre completo a 255. Como el byte de longitud de una etiqueta nunca supera 63, sus dos bits superiores son siempre cero, y eso dejó espacio para la compresión: cuando los dos bits superiores valen uno, ese byte y el siguiente forman un puntero, y los 14 bits restantes indican un desplazamiento desde el inicio del mensaje. En una respuesta, es muy habitual que el nombre de la respuesta sean los dos bytes c0 0c, un puntero al desplazamiento 12, donde el nombre de la pregunta empieza justo después de la cabecera. Todo programa DNS debe entender los punteros en los mensajes que recibe, aunque puede optar por no generarlos.

Por qué importaban los 512 bytes y qué los sustituyó

La RFC 1035 restringe los mensajes UDP a 512 bytes, sin contar las cabeceras IP y UDP. Un mensaje más largo se trunca y se activa el bit TC, que indica al cliente que reintente por TCP. Los diseñadores originales consideraron el límite del datagrama un acierto y no un problema: el rendimiento era mucho mejor que con circuitos TCP y no quedaban atados recursos del sistema operativo, aunque la decisión exigía estrategias cuidadosas de retransmisión (Mockapetris y Dunlap, 1988).

A medida que las respuestas crecieron con IPv6 y DNSSEC, el límite se quedó estrecho. EDNS(0), definido en la RFC 6891, permite que un cliente anuncie un tamaño de carga útil UDP mayor en un pseudorregistro OPT. La RFC sugiere 4096 octetos como punto de partida y, si eso falla, volver a un valor dentro de un intervalo de aproximadamente 1280 a 1410 bytes. Desde la RFC 7766, en 2016, el soporte de TCP es una parte obligatoria de una implementación DNS completa. Las respuestas UDP más grandes también tienen un coste de seguridad, porque hacen más rentables los ataques de reflexión; Ataques de amplificación DNS y resolvedores abiertos lo trata.

Fuentes y lecturas complementarias

• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• RFC 2535: Domain Name System Security Extensions (Eastlake, 1999)
• RFC 4035: Protocol Modifications for the DNS Security Extensions (Arends et al., 2005)
• RFC 6891: Extension Mechanisms for DNS (EDNS(0)) (Damas, Graff and Vixie, 2013)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)
• Kevin R. Fall and W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition (Addison-Wesley, 2011)