Qué puerto usa el DNS: el 53, y cuándo no lo es

¿Qué puerto usa el DNS en una consulta normal?

Una consulta normal, del tipo que tu navegador envía decenas de veces por minuto, sale como un único paquete UDP al puerto 53 y vuelve de la misma forma. La RFC 1035 llama al UDP "el método recomendado para consultas estándar en internet" porque no necesita negociación previa: un paquete sale, un paquete vuelve, listo. Por eso también el DNS parece instantáneo cuando funciona, y por eso basta un solo paquete perdido para que parezca roto, ya que el UDP no reintenta automáticamente por ti. El software resolutor de tu dispositivo o router es quien se encarga del reintento, normalmente contra un segundo servidor configurado si el primero se queda en silencio.

¿Cuándo usa TCP el DNS en su lugar?

Hay dos situaciones que empujan un intercambio DNS al puerto TCP 53. La primera es una transferencia de zona, cuando un servidor de nombres secundario obtiene una copia completa de una zona desde el primario. La RFC 1035 es explícita al decir que "UDP no es aceptable para las transferencias de zona" porque la operación necesita un flujo fiable y ordenado, no un único paquete de mejor esfuerzo. La segunda es una respuesta que no cabe en el tamaño de mensaje UDP en uso. Cuando eso ocurre, el servidor devuelve un paquete UDP truncado con el bit TC (truncado) activado, y un resolutor conforme al estándar detecta ese bit y reenvía la misma consulta por TCP para obtener la respuesta completa. Puedes forzar ese comportamiento tú mismo y ver la respuesta completa directamente:

dig +tcp example.com

Las consultas del día a día rara vez necesitan este camino, pero existe precisamente para que el DNS siga funcionando cuando una respuesta crece más de lo que puede contener un solo paquete UDP, algo que ocurre con más frecuencia que antes.

¿Cuál era el límite de 512 bytes, y qué lo cambió?

La RFC 1035 fijó el tamaño del mensaje UDP en 512 bytes, cabecera incluida, sin contar las propias cabeceras de IP o UDP. Ese número era generoso en 1987, cuando una respuesta DNS era un puñado de registros de dirección. Dejó de serlo en cuanto las firmas DNSSEC, los nombres de host más largos y los conjuntos de registros con muchas direcciones IP se volvieron habituales, porque una respuesta firmada con un registro RRSIG suele superar los 512 bytes ella sola.

La RFC 6891, publicada en 2013, corrigió ese techo sin tocar el protocolo de transmisión: EDNS0 añade un pseudorregistro OPT que permite a un resolutor anunciar "la mayor carga útil UDP que puede reensamblarse y entregarse en la pila de red del solicitante", y la RFC sugiere 4096 bytes como punto de partida práctico. Un resolutor y un servidor que admiten ambos EDNS0 pueden intercambiar respuestas varias veces mayores que el antiguo límite de 512 bytes en un solo paquete UDP, y solo recurren a TCP cuando ni siquiera ese margen mayor basta. Prácticamente todos los resolutores en uso hoy, incluido el de tu propio sistema operativo, hablan EDNS0 por defecto, así que esa mejora ya ocurrió sin que tú hicieras nada.

Por qué los cortafuegos que solo permiten UDP 53 causan problemas reales

Una regla de cortafuegos escrita hace años y nunca revisada suele decir "permitir puerto UDP 53, denegar todo lo demás relacionado con DNS". Esa regla bloquea la alternativa TCP que el protocolo necesita, y el fallo que produce es fácil de diagnosticar mal porque la mayoría de las consultas siguen funcionando bien. Solo fallan las que crecen más allá del límite de UDP, y lo hacen de una forma que parece aleatoria: un dominio se resuelve con normalidad la mayor parte del tiempo y luego agota el tiempo de espera, sobre todo en cuanto entra en juego la validación DNSSEC, ya que un resolutor que valida tiene que obtener los registros RRSIG y DNSKEY junto con la respuesta que pidió.

El resultado práctico es que las zonas firmadas con DNSSEC y cualquier conjunto de registros con muchos valores (un dominio con una docena de servidores de correo, por ejemplo) se vuelven poco fiables detrás de un cortafuegos solo de UDP, mientras todo lo demás parece sano. Bloquear el TCP 53 de salida, o bloquearlo solo en una dirección, es una de las caídas de DNS autoinfligidas más comunes, y rara vez aparece en una comprobación básica de conectividad porque esa comprobación suele probar solo UDP.

DNS sobre TLS y DNS sobre HTTPS: puertos distintos, las mismas consultas

Dos transportes más nuevos llevan las mismas consultas y respuestas DNS, pero las sacan por completo del puerto 53. DNS sobre TLS, definido en la RFC 7858, envuelve cada consulta en una sesión TLS por el puerto TCP 853, elegido para que un operador de red todavía pueda ver que está ocurriendo DoT (y bloquearlo) incluso sin descifrarlo, ya que el propio puerto es una señal clara.

DNS sobre HTTPS, definido en la RFC 8484, va más allá. Envía las consultas DNS como peticiones HTTPS ordinarias por el puerto 443, el mismo puerto que cualquier otro sitio web que visitas, y la RFC señala "la capacidad de mezclar tráfico DoH con otro tráfico HTTPS en la misma conexión" como una propiedad deliberada. Ese es precisamente el objetivo de DoH: una red que solo inspecciona o filtra por puerto no puede separar una consulta DNS de cualquier otra petición HTTPS, porque son el mismo protocolo en el mismo puerto. Chrome, Firefox y Edge ya pueden enviar DNS así por defecto, y por eso bloquear "el puerto 53" en una red ya no garantiza que hayas bloqueado el DNS. Garantiza que has bloqueado el transporte clásico; un navegador con DoH activado sigue resolviendo nombres por el 443 de todos modos.

¿Qué es mDNS en el puerto 5353?

El DNS multicast es un protocolo distinto con un nombre parecido. La RFC 6762 lo define como dispositivos "enviando mensajes UDP de consulta y respuesta similares a DNS por IP Multicast al puerto UDP 5353", dirigidos al grupo multicast 224.0.0.251 (o su equivalente en IPv6, FF02::FB) en lugar de a un servidor concreto. No hay ningún servidor de nombres central implicado: cada dispositivo del segmento de red local escucha en el puerto 5353 y responde por su propio nombre. Así es como una impresora o un altavoz inteligente se vuelve accesible como device.local sin que nadie configure un registro DNS para él. Está confinado al enlace local por diseño y no tiene nada que ver con resolver un nombre de dominio público, así que el tráfico mDNS nunca necesita salir de tu router.

Cómo comprobar si el puerto 53 es accesible

Empieza con una consulta directa contra un resolutor de confianza, lo cual te dice si las consultas UDP normales funcionan siquiera:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Si eso funciona pero sospechas que el camino de reserva por TCP está bloqueado, fuerza TCP y compara:

dig +tcp example.com @1.1.1.1

Una consulta UDP que tiene éxito mientras la versión forzada por TCP agota el tiempo es un fuerte indicio de que algo entre tú y el resolutor está descartando específicamente el TCP 53, exactamente el fallo descrito arriba. Probar el alcance real de un puerto desde fuera de tu propia red es donde resulta útil nuestra herramienta de comprobación de puertos: apúntala al puerto 53 de tu resolutor o servidor de nombres y abre una conexión TCP real desde otra red, confirmando si el TCP 53 es accesible. Lee el resultado con una salvedad en mente: un comprobador de puertos prueba TCP, así que un resultado positivo ahí confirma que el camino de reserva está abierto, pero no dice nada sobre el UDP, que no tiene negociación previa que se pueda probar de la misma forma. Para la consulta en sí, incluida la comparación de respuestas de varios resolutores públicos y regiones distintas a la vez, ejecuta la herramienta de consulta DNS.

Preguntas frecuentes

¿Necesito abrir TCP 53 además de UDP 53?

Sí, para el tráfico saliente hacia el resolutor. Un cortafuegos que solo permite UDP 53 gestionará bien la mayoría de las consultas y luego fallará de forma impredecible en respuestas más grandes, normalmente firmadas con DNSSEC, que necesitan la alternativa TCP.

¿Bloquear el puerto 53 detiene todo el tráfico DNS?

Ya no. Bloquea el transporte clásico UDP/TCP. DNS sobre HTTPS se ejecuta por el puerto 443 y parece cualquier otra petición HTTPS, y DNS sobre TLS se ejecuta en su propio puerto 853, así que un navegador o aplicación con cualquiera de los dos activado sigue resolviendo nombres.

¿Es DNS sobre HTTPS el mismo protocolo que el DNS normal?

Las consultas y respuestas son los mismos registros y códigos DNS definidos por la RFC 1035. Solo cambia el transporte: en vez de un paquete UDP o TCP puro por el puerto 53, la misma petición va envuelta dentro de una petición HTTPS por el puerto 443.

¿Por qué usa a veces dig TCP sin que se lo pidan?

Cuando una respuesta UDP vuelve truncada, con el bit TC activado, un cliente conforme al estándar reenvía automáticamente la consulta por TCP para obtener la respuesta completa. Esto se ve más a menudo en dominios con DNSSEC activado o con muchos registros del mismo tipo.

¿Es mDNS en el puerto 5353 el mismo DNS que el de mi proveedor?

No. mDNS solo funciona en tu segmento de red local, no tiene servidor central, y resuelve nombres como device.local para dispositivos del mismo enlace. No tiene ninguna participación en resolver un dominio público como example.com.

¿Cuál es un tamaño normal de carga útil EDNS0 hoy en día?

La RFC 6891 sugiere 4096 bytes como valor práctico por defecto, y la mayoría de los resolutores actuales anuncian algo en ese rango, muy por encima del techo original de 512 bytes, antes de recurrir a TCP solo cuando ni eso basta.