Guia de portas DNS: resolução de nomes na porta 53

Quando um cliente precisa acessar um domínio, ele solicita ao resolvedor registros como A, AAAA, CNAME, MX, TXT, NS ou SRV. O resolvedor pode responder a partir do cache ou percorrer a hierarquia do DNS através de servidores raiz, TLD e autoritativos até encontrar o registro.

A maioria das consultas de clientes usa a porta UDP 53 porque a solicitação e a resposta são pequenas. O DNS pode mudar para TCP quando as respostas são muito grandes, quando ocorre truncamento, quando o DNSSEC aumenta o tamanho da resposta ou quando os servidores realizam transferências de zona e outras operações que exigem um fluxo confiável.

UDP 53 é o caminho comum para resolução diária de DNS. Bloqueá-lo geralmente interrompe as pesquisas normais. O TCP 53 não é opcional para uma implantação completa de DNS: ele suporta respostas grandes, fallback de respostas UDP truncadas, respostas pesadas de DNSSEC e transferências de zona entre servidores autorizados.

Uma regra de firewall que permite UDP 53, mas bloqueia TCP 53, pode criar falhas intermitentes difíceis de diagnosticar. Registros pequenos podem funcionar enquanto respostas maiores relacionadas a DNSSEC, TXT ou email falham.

Um servidor DNS autoritativo publica registros para domínios que você controla. Deve ser acessível pela Internet quando atende zonas públicas, mas deve responder apenas com autoridade para essas zonas e não deve fornecer recursão aberta.

Um resolvedor recursivo realiza pesquisas para clientes. Os resolvedores recursivos públicos devem ser projetados e protegidos para essa função. Os resolvedores internos geralmente devem responder apenas por redes confiáveis, clientes VPN ou ambientes de aplicativos específicos.

Abra a porta 53 para a Internet para servidores DNS autoritativos que hospedam zonas públicas. Tanto o UDP quanto o TCP devem ser considerados. Se o servidor for apenas interno, restrinja o acesso às redes que necessitam de resolução de nomes.

Não exponha um resolvedor recursivo a toda a Internet, a menos que você opere intencionalmente um resolvedor público com limitação de taxa, monitoramento de abuso e planejamento de capacidade. Os resolvedores abertos são comumente usados ​​para ataques de reflexão e amplificação.

Antes de permitir a porta 53, decida se o servidor é autoritativo, recursivo, de encaminhamento, de cache ou de horizonte dividido. Confirme quais clientes devem usá-lo, quais zonas ele atende, se a recursão está habilitada e se as transferências de zona estão restritas a servidores secundários autorizados.

Um verificador de porta pode confirmar que a porta 53 está acessível, mas a correção do DNS requer testes em nível de protocolo. Use logs dig, nslookup, drill ou resolvedor para verificar respostas de registros, política de recursão, fallback de TCP, comportamento de DNSSEC e tempos de resposta.

No Windows Server, a função de servidor DNS pode servir zonas integradas ao Active Directory, registros internos e regras de encaminhamento. Restrinja a recursão e as transferências de zona com cuidado, especialmente se o servidor tiver alguma interface pública.

No Linux, servidores DNS comuns incluem BIND, Unbound, PowerDNS, Knot DNS, CoreDNS e dnsmasq. Configure interfaces de escuta, política de recursão, clientes permitidos, zonas autoritativas, registro em log e regras de firewall para UDP e TCP 53.

Em plataformas de nuvem, o DNS gerenciado costuma ser mais seguro para zonas públicas autorizadas porque o provedor lida com anycast, escalabilidade e resiliência básica de DDoS. O DNS auto-hospedado ainda precisa de instâncias redundantes, monitoramento e políticas de rede claras.

Comece com uma verificação de porta externa para UDP ou TCP 53, dependendo do que você precisa validar. Em seguida, execute dig @server example.com A, dig @server example.com AAAA ou nslookup no resolvedor de destino para confirmar respostas DNS reais.

Teste o TCP explicitamente com dig +tcp @server example.com TXT ou outra resposta grande. Para servidores autoritativos, consulte registros de fora da sua rede e verifique se a recursão foi recusada. Para resolvedores recursivos, consulte redes de origem permitidas e não permitidas.

Se a porta 53 estiver fechada, o serviço DNS pode ser interrompido, escutando na interface errada, bloqueado por um firewall de host ou restrito por um grupo de segurança de nuvem. Se o UDP parecer não confiável, mas o TCP funcionar, inspecione o MTU, a fragmentação, o tamanho da resposta, as configurações de EDNS e o comportamento relacionado ao DNSSEC.

Se a porta estiver aberta, mas as pesquisas falharem, verifique os dados da zona, delegação, registros de colagem, registros SOA e NS, política de recursão, encaminhadores, validação de DNSSEC, estado do cache e logs. As falhas de DNS geralmente vêm da configuração de políticas ou zonas, e não da acessibilidade bruta da porta.

Não execute um resolvedor recursivo aberto por acidente. Limite a recursão a clientes confiáveis, restrinja as transferências de zona para servidores secundários conhecidos, mantenha o software DNS corrigido e monitore taxas de consulta, picos de NXDOMAIN, picos de SERVFAIL e redes de origem incomuns.

Para DNS com autoridade pública, use servidores redundantes, DNSSEC quando apropriado, TTLs curtos o suficiente para flexibilidade operacional e propriedade clara das alterações de zona. Para DNS interno, proteja registros de horizonte dividido porque eles geralmente revelam nomes de infraestrutura e topologia privada.