Glosario del DNS

¿Qué es el UDP (Protocolo de datagramas de usuario)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Puntos claveLos puntos clave se generan con la ayuda de la inteligencia artificial. Dado que los resúmenes automáticos pueden contener en ocasiones errores u omitir contexto importante, consulta siempre la entrada completa del blog para obtener toda la información.

User Datagram Protocol (UDP) is a connectionless transport layer protocol defined in RFC 768 that enables fast, low-overhead delivery of independent messages between applications without requiring connection setup or reliability guarantees at the transport layer. DNS and DHCP depend on UDP for efficient operation—DNS uses UDP port 53 for typical queries and responses to minimize latency and server state, while DHCP requires UDP to allow clients without addresses to broadcast configuration requests. Operationally, UDP failures manifest quietly as timeouts and retries rather than explicit errors, and network issues such as packet loss, firewall blocking, or fragmentation often appear only as slow name resolution or intermittent lookup failures, requiring operators to monitor interface counters and logs for visibility.

  • UDP prepends only an 8-byte header containing source port, destination port, length, and checksum, contrasting sharply with TCP’s minimum 20-byte header overhead and making UDP ideal for single-request-response patterns like DNS queries.
  • DNS originally limited UDP messages to 512 bytes under RFC 1035, and EDNS0 later enabled larger payloads, but responses exceeding the client’s advertised payload size are truncated and must be retried over TCP.
  • Firewall rules that block UDP port 53 while permitting only TCP cause intermittent DNS resolution failures, fragmentation of large UDP datagrams exceeds path MTU limits on many networks, and stateful device timeouts discard slow upstream responses after idle timer expiration, all presenting as silent packet loss with no transport-layer error indication.

UDP de un vistazo

AttributeValue
Full nameUser datagram protocol
CategoryNetwork protocol
Defined inRFC 768
Protocol and portIP protocol number 17; DNS uses port 53; DHCP uses ports 67 and 68
OSI layerLayer 4 (transport)
Primary useLow-overhead, connectionless delivery of short messages such as DNS queries and DHCP exchanges
Related termsTCP, DNS, DHCP, Port 53, EDNS0

Cómo funciona el UDP

UDP envuelve los datos de la aplicación en un pequeño datagrama y se los entrega a IP. No hay establecimiento de conexión, ni acuse de recibo, ni retransmisión en la capa de transporte.

  1. La aplicación crea un mensaje: la aplicación, como un resolutor DNS, crea una solicitud completa que cabe en un datagrama.
  2. UDP añade una cabecera: UDP antepone una cabecera de 8 bytes que contiene el puerto de origen, el puerto de destino, la longitud y la suma de comprobación.
  3. IP entrega el datagrama: el datagrama viaja como un paquete IP. Cada datagrama se enruta de forma independiente y puede perderse, duplicarse o reordenarse.
  4. El receptor pasa los datos a la aplicación: el host receptor utiliza el puerto de destino, por ejemplo el 53 para el DNS, para entregar la carga útil al servicio adecuado.
  5. La aplicación gestiona la pérdida: si no llega ninguna respuesta, la aplicación decide qué hacer, normalmente un tiempo de espera seguido de un nuevo intento, posiblemente a otro servidor.

El UDP no ofrece control de congestión, ordenación ni entrega garantizada. El DNS recurre al TCP cuando una respuesta se trunca o cuando una transferencia, como una transferencia de zona, requiere una entrega fiable. El DHCP utiliza el UDP porque un cliente sin dirección no puede mantener una conexión TCP.

Por qué es importante el UDP en las redes empresariales

UDP es el protocolo de transporte predeterminado para el DNS porque una consulta típica consiste en una pequeña pregunta y una pequeña respuesta. Omitir el protocolo de enlace ahorra un viaje de ida y vuelta y el estado del servidor, lo cual es importante cuando un resolutor gestiona un gran número de consultas. El RFC 1035 limitaba originalmente los mensajes DNS UDP a 512 bytes, y posteriormente EDNS0 permitió cargas útiles más grandes.

El DHCP también depende de UDP. Un cliente sin dirección realiza difusiones desde el puerto 68 a los servidores en el puerto 67, algo que el TCP no puede hacer. Los cortafuegos que bloquean estos puertos impiden silenciosamente la asignación de direcciones.

Desde el punto de vista operativo, el uso de UDP implica que los fallos pasan desapercibidos. Los datagramas descartados se manifiestan como tiempos de espera agotados y reintentos, en lugar de como errores de conexión, por lo que una resolución de nombres lenta suele ser el primer síntoma de pérdida de paquetes o filtrado. Bloquear el UDP 53 mientras solo se permite el TCP, o descartar respuestas UDP fragmentadas, provoca fallos intermitentes. Dado que UDP no verifica al remitente, los atacantes pueden suplantar direcciones de origen, razón por la cual los resolutores abiertos son objeto de abuso para llevar a cabo ataques de reflexión y amplificación. La limitación de la tasa de respuesta, la validación de la dirección de origen y la restricción de la recursión a clientes de confianza reducen ese riesgo.

Comparación de UDP con términos relacionados

UDP frente a TCP

UDP envía datagramas independientes sin conexión, acuse de recibo ni retransmisión, mientras que TCP establece una conexión y garantiza la entrega ordenada y fiable de un flujo de bytes. ¿Qué es TCP?

AttributeUDPTCP
Delivery guaranteeNone at the transport layerAcknowledged and retransmitted
OrderingNot preservedPreserved
Header size8 bytesAt least 20 bytes
Message boundariesPreserved per datagramNot preserved; continuous stream
Typical DNS useMost queries and responsesZone transfers and large or truncated responses

Problemas habituales con UDP

Una regla que solo permite el puerto TCP 53 permite que las transferencias de zona funcionen, mientras que las búsquedas normales agotan el tiempo de espera. Los clientes experimentan fallos intermitentes en la resolución y las capturas de paquetes muestran que las consultas se envían sin obtener respuesta.

Las respuestas que superan el tamaño de la carga útil de UDP que anuncia el cliente se truncan y el cliente debe volver a intentarlo a través de TCP. Si el puerto 53 de TCP está bloqueado, las respuestas de gran tamaño, como los registros firmados con DNSSEC, fallan, mientras que las de menor tamaño se procesan correctamente.

Los datagramas UDP de gran tamaño que superan la MTU de la ruta se fragmentan, y muchos cortafuegos y dispositivos intermedios descartan los fragmentos. El síntoma es que solo algunas consultas agotan el tiempo de espera, a menudo aquellas con respuestas de gran tamaño.

Los cortafuegos y los dispositivos NAT realizan un seguimiento de los flujos UDP con temporizadores de inactividad cortos. Una respuesta lenta del servidor puede llegar después de que caduque la asignación y ser descartada, por lo que el cliente detecta un tiempo de espera agotado.

UDP no proporciona información sobre la entrega, por lo que la congestión o una cola de interfaz llena solo se manifiestan a través de los reintentos de la aplicación y la latencia. Los ingenieros deben comprobar los contadores de paquetes perdidos de la interfaz y los registros del servidor, en lugar de esperar que se produzcan errores de transporte.

Descubre cómo el DDI unificado simplifica las operaciones de red

Gestiona el DNS, el DHCP y las direcciones IP desde una única plataforma con automatización, visibilidad y control integrados.

Preguntas frecuentes sobre UDP

Términos relacionados

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

Establecimiento de modelos de flujo de trabajo y aprobación de IPAM regulados y preparados para auditorías para las redes de la organización

Descubre soluciones de gestión de direcciones IP para flujos de trabajo de IPAM regulados y preparados para auditorías. Habilita aprobaciones por ámbitos…

Read more
Content Hub

Comprender el modelo OSI: dónde encajan el DNS y el direccionamiento IP dentro de las 7 capas

Comprende las siete capas del modelo OSI y cómo encajan en ellas el DNS y el direccionamiento IP. Aprende los fundamentos de la arquitectura de redes con…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

Escalabilidad del DNS y la gestión de direcciones IP (IPAM) para redes empresariales IPv6 y de doble pila

Amplíe el DNS y el IPAM para redes empresariales de doble pila. Descubra cómo Micetro ayuda a los equipos a gestionar las migraciones a IPv6 con sistemas…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

Integración de DNS, DHCP e IPAM en flujos de trabajo de infraestructura como código basados en Ansible y Git

La integración de DNS, DHCP e IPAM en los flujos de trabajo de IaC basados en Ansible y Git con Micetro convierte los cambios de direcciones y registros en…

Read more
Podcast

Podcast: Cómo la IA está cambiando el desarrollo de software empresarial

La IA transforma la automatización de redes, pero una implementación segura requiere sólidas prácticas de software, pruebas y experiencia en el ámbito…

Read more
Podcast

Podcast: Por qué las plataformas abiertas son importantes en las operaciones de red

Las plataformas abiertas y la arquitectura «API-first» permiten operaciones de red inteligentes, automatización y flujos de trabajo impulsados por IA en…

Read more
Network engineer reviewing LiveNX flow and telemetry data visualized across server racks in a hybrid multicloud environment

Obtenga respuestas a partir de los datos de LiveNX que ya tiene con LiveAssist

Descubre cómo LiveAssist, el complemento basado en IA para LiveNX, convierte tus datos de red en respuestas rápidas y guiadas, con un valor que podrás…

Read more
LiveWire GEN3 device offerings overview with descriptions of deep packet visibility and deployment options

Oferta de dispositivos LiveWire GEN3

BlueCat LiveWire es una plataforma de captura de paquetes y análisis forense de redes que ofrece una visibilidad profunda a nivel de paquetes en entornos…

Read more

Artículos relacionados