Guía de puertos DNS: resolución de nombres en el puerto 53

Cuando un cliente necesita acceder a un dominio, solicita a un solucionador registros como A, AAAA, CNAME, MX, TXT, NS o SRV. El solucionador puede responder desde la memoria caché o recorrer la jerarquía DNS a través de servidores raíz, TLD y autorizados hasta que encuentre el registro.

La mayoría de las consultas de los clientes utilizan el puerto UDP 53 porque la solicitud y la respuesta son pequeñas. DNS puede cambiar a TCP cuando las respuestas son demasiado grandes, cuando se produce un truncamiento, cuando DNSSEC aumenta el tamaño de la respuesta o cuando los servidores realizan transferencias de zona y otras operaciones que requieren una transmisión confiable.

UDP 53 es la ruta común para la resolución DNS diaria. Bloquearlo generalmente interrumpe las búsquedas normales. TCP 53 no es opcional para una implementación de DNS completa: admite respuestas grandes, respaldo de respuestas UDP truncadas, respuestas con alto contenido de DNSSEC y transferencias de zona entre servidores autorizados.

Una regla de firewall que permite UDP 53 pero bloquea TCP 53 puede crear fallas intermitentes que son difíciles de diagnosticar. Los registros pequeños pueden funcionar mientras que las respuestas DNSSEC, TXT o relacionadas con el correo más grandes fallan.

Un servidor DNS autorizado publica registros para los dominios que usted controla. Debería ser accesible a través de Internet cuando presta servicios en zonas públicas, pero solo debe responder con autoridad para esas zonas y no debe proporcionar recursividad abierta.

Un solucionador recursivo realiza búsquedas de clientes. Los solucionadores recursivos públicos deben diseñarse y protegerse para esa función. Los solucionadores internos normalmente deberían responder solo para redes confiables, clientes VPN o entornos de aplicaciones específicos.

Abra el puerto 53 a Internet para servidores DNS autorizados que alojan zonas públicas. Se deben considerar tanto UDP como TCP. Si el servidor es solo interno, restrinja el acceso a las redes que necesitan resolución de nombres.

No exponga un solucionador recursivo a todo Internet a menos que opere intencionalmente un solucionador público con limitación de velocidad, monitoreo de abuso y planificación de capacidad. Los resolutores abiertos suelen ser objeto de abuso para ataques de reflexión y amplificación.

Antes de permitir el puerto 53, decida si el servidor es autoritativo, recursivo, de reenvío, de almacenamiento en caché o de horizonte dividido. Confirme qué clientes deben usarlo, a qué zonas presta servicio, si la recursividad está habilitada y si las transferencias de zona están restringidas a servidores secundarios autorizados.

Un verificador de puertos puede confirmar que se puede acceder al puerto 53, pero la corrección del DNS requiere pruebas a nivel de protocolo. Utilice registros de excavación, nslookup, exploración o resolución para verificar las respuestas de los registros, la política de recursividad, el respaldo de TCP, el comportamiento de DNSSEC y los tiempos de respuesta.

En Windows Server, la función del servidor DNS puede servir zonas integradas en Active Directory, registros internos y reglas de reenvío. Restrinja la recursividad y las transferencias de zona con cuidado, especialmente si el servidor tiene una interfaz pública.

En Linux, los servidores DNS comunes incluyen BIND, Unbound, PowerDNS, Knot DNS, CoreDNS y dnsmasq. Configure interfaces de escucha, política de recursividad, clientes permitidos, zonas autorizadas, registro y reglas de firewall para UDP y TCP 53.

En las plataformas en la nube, el DNS administrado suele ser más seguro para las zonas públicas autorizadas porque el proveedor maneja la resiliencia DDoS de línea base, escalable y de difusión directa. El DNS autohospedado aún necesita instancias redundantes, monitoreo y una política de red clara.

Comience con una verificación del puerto externo para UDP o TCP 53, dependiendo de lo que necesite validar. Luego ejecute dig @server example.com A, dig @server example.com AAAA o nslookup contra el solucionador de destino para confirmar las respuestas DNS reales.

Pruebe TCP explícitamente con dig +tcp @server example.com TXT u otra respuesta grande. Para servidores autorizados, consulte registros desde fuera de su red y verifique que se rechace la recursividad. Para solucionadores recursivos, consulte desde redes de origen permitidas y no permitidas.

Si el puerto 53 está cerrado, el servicio DNS puede estar detenido, escuchando en la interfaz incorrecta, bloqueado por un firewall del host o restringido por un grupo de seguridad en la nube. Si UDP parece no confiable pero TCP funciona, inspeccione MTU, fragmentación, tamaño de respuesta, configuración de EDNS y comportamiento relacionado con DNSSEC.

Si el puerto está abierto pero las búsquedas fallan, verifique los datos de la zona, la delegación, los registros de pegamento, los registros SOA y NS, la política de recursividad, los reenviadores, la validación de DNSSEC, el estado de la caché y los registros. Las fallas de DNS a menudo provienen de la configuración de políticas o zonas en lugar de la accesibilidad sin formato del puerto.

No ejecute un solucionador recursivo abierto por accidente. Limite la recursividad a clientes confiables, restrinja las transferencias de zona a servidores secundarios conocidos, mantenga el software DNS parcheado y supervise las tasas de consultas, los picos de NXDOMAIN, los picos de SERVFAIL y las redes de origen inusuales.

Para DNS público autorizado, utilice servidores redundantes, DNSSEC cuando corresponda, TTL lo suficientemente cortos para lograr flexibilidad operativa y propiedad clara de los cambios de zona. Para DNS interno, proteja los registros de horizonte dividido porque a menudo revelan nombres de infraestructura y topología privada.