Qual porta o DNS usa? A porta 53, com exceções

Qual porta o DNS usa em uma consulta comum?

Uma consulta normal, do tipo que o seu navegador envia dezenas de vezes por minuto, sai como um único pacote UDP para a porta 53 e volta da mesma forma. A RFC 1035 chama o UDP de "o método recomendado para consultas padrão na Internet" porque ele não precisa de handshake: um pacote sai, um pacote volta, pronto. É também por isso que o DNS parece instantâneo quando funciona e por que um único pacote perdido já é suficiente para parecer quebrado, já que o UDP não tenta de novo sozinho. O software resolvedor no seu dispositivo ou roteador é quem cuida da nova tentativa, geralmente contra um segundo servidor configurado se o primeiro ficar em silêncio.

Quando o DNS usa TCP em vez disso?

Duas situações empurram uma troca de DNS para a porta TCP 53. A primeira é uma transferência de zona, quando um servidor secundário busca uma cópia completa de uma zona a partir do primário. A RFC 1035 é explícita ao dizer que "UDP não é aceitável para transferências de zona", porque a operação precisa de um fluxo confiável e ordenado, não de um único pacote de melhor esforço. A segunda é uma resposta que não cabe no tamanho de mensagem UDP em uso. Quando isso acontece, o servidor devolve um pacote UDP truncado com o bit TC (truncado) marcado, e um resolvedor compatível com o padrão percebe o bit e reenvia a mesma consulta por TCP para obter a resposta completa. Você pode forçar esse comportamento e ver a resposta completa diretamente:

dig +tcp example.com

Consultas do dia a dia raramente precisam desse caminho, mas ele existe justamente para que o DNS continue funcionando quando uma resposta cresce além do que um único pacote UDP comporta, o que acontece com mais frequência do que costumava acontecer.

O que era o limite de 512 bytes, e o que mudou isso?

A RFC 1035 fixou o tamanho da mensagem UDP em 512 bytes, cabeçalho incluído, sem contar os cabeçalhos de IP ou UDP em si. Esse número era generoso em 1987, quando uma resposta de DNS era um punhado de registros de endereço. Deixou de ser generoso quando assinaturas DNSSEC, nomes de host mais longos e conjuntos de registros com muitos endereços IP se tornaram comuns, porque uma resposta assinada com um registro RRSIG costuma ultrapassar os 512 bytes sozinha.

A RFC 6891, publicada em 2013, corrigiu esse teto sem alterar o protocolo de transmissão: o EDNS0 adiciona um pseudo-registro OPT que permite a um resolvedor anunciar "o maior payload UDP que pode ser remontado e entregue na pilha de rede do solicitante", e a RFC sugere 4096 bytes como ponto de partida prático. Um resolvedor e um servidor que suportam EDNS0 podem trocar respostas várias vezes maiores que o antigo limite de 512 bytes em um único pacote UDP, e só recorrem ao TCP quando nem essa margem maior é suficiente. Praticamente todo resolvedor em uso hoje, incluindo o do seu próprio sistema operacional, fala EDNS0 por padrão, então essa atualização já aconteceu sem nenhuma ação da sua parte.

Por que firewalls que só permitem UDP 53 causam problemas reais

Uma regra de firewall escrita anos atrás e nunca revisada costuma dizer "permitir porta UDP 53, negar todo o resto relacionado a DNS". Essa regra bloqueia a alternativa TCP de que o protocolo precisa, e a falha que ela produz é fácil de diagnosticar errado porque a maioria das consultas continua funcionando normalmente. Só falham as que crescem além do limite do UDP, e falham de um jeito que parece aleatório: um domínio resolve normalmente na maior parte do tempo e depois estoura o tempo, principalmente quando a validação DNSSEC entra em jogo, já que um resolvedor que valida precisa buscar os registros RRSIG e DNSKEY junto com a resposta que pediu.

O resultado prático é que zonas assinadas com DNSSEC e qualquer conjunto de registros com muitos valores (um domínio com uma dúzia de servidores de e-mail, por exemplo) ficam pouco confiáveis atrás de um firewall só de UDP, enquanto todo o resto parece saudável. Bloquear TCP 53 de saída, ou bloqueá-lo em apenas uma direção, é uma das falhas de DNS autoinfligidas mais comuns, e raramente aparece em uma checagem básica de conectividade porque essa checagem costuma testar só o UDP.

DNS sobre TLS e DNS sobre HTTPS: portas diferentes, as mesmas consultas

Dois transportes mais novos carregam as mesmas consultas e respostas de DNS, mas tiram tudo isso da porta 53. O DNS sobre TLS, definido na RFC 7858, envolve cada consulta em uma sessão TLS na porta TCP 853, escolhida para que um operador de rede ainda consiga ver que o DoT está acontecendo (e bloqueá-lo) mesmo sem decifrar o tráfego, já que a própria porta já é um sinal claro.

O DNS sobre HTTPS, definido na RFC 8484, vai além. Ele envia consultas de DNS como requisições HTTPS comuns na porta 443, a mesma porta de qualquer outro site que você visita, e a RFC destaca "a capacidade de misturar tráfego DoH com outro tráfego HTTPS na mesma conexão" como uma propriedade deliberada. Esse é todo o objetivo do DoH: uma rede que só inspeciona ou filtra por porta não consegue separar uma consulta de DNS de qualquer outra requisição HTTPS, porque são o mesmo protocolo na mesma porta. Chrome, Firefox e Edge já podem enviar DNS assim por padrão, e é por isso que bloquear "a porta 53" em uma rede não garante mais que você bloqueou o DNS. Garante que você bloqueou o transporte clássico; um navegador com DoH ativado continua resolvendo nomes pela porta 443 do mesmo jeito.

O que é o mDNS na porta 5353?

O DNS multicast é um protocolo diferente usando um nome parecido. A RFC 6762 o define como dispositivos "enviando mensagens UDP de consulta e resposta parecidas com DNS por IP Multicast para a porta UDP 5353", endereçadas ao grupo multicast 224.0.0.251 (ou seu equivalente em IPv6, FF02::FB) em vez de um servidor específico. Não existe nenhum servidor de nomes central envolvido: cada dispositivo no segmento de rede local escuta na porta 5353 e responde pelo próprio nome. É assim que uma impressora ou um alto-falante inteligente fica acessível como device.local sem que ninguém configure um registro de DNS para ele. Por projeto, isso fica confinado ao link local e não tem nada a ver com resolver um nome de domínio público, então o tráfego de mDNS nunca precisa sair do seu roteador.

Como testar se a porta 53 está acessível

Comece com uma consulta direta contra um resolvedor confiável, o que já diz se as consultas UDP comuns funcionam:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Se isso funcionar mas você suspeitar que o caminho de reserva por TCP está bloqueado, force o TCP e compare:

dig +tcp example.com @1.1.1.1

Uma consulta UDP que funciona enquanto a versão forçada por TCP estoura o tempo é um forte indício de que algo entre você e o resolvedor está descartando especificamente o TCP 53, exatamente o modo de falha descrito acima. Testar o alcance bruto de uma porta a partir de fora da sua rede é onde a nossa ferramenta de verificação de portas é útil: aponte-a para a porta 53 no seu resolvedor ou servidor de nomes, e ela abre uma conexão TCP real a partir de outra rede, confirmando se o TCP 53 está acessível. Leia o resultado com uma ressalva em mente: um verificador de portas testa TCP, então um resultado positivo ali confirma que o caminho de reserva está aberto, mas não diz nada sobre o UDP, que não tem handshake para ser testado da mesma forma. Para a consulta em si, incluindo comparar respostas de vários resolvedores públicos e regiões diferentes ao mesmo tempo, rode a ferramenta de consulta DNS.

Perguntas frequentes

Preciso abrir TCP 53 além do UDP 53?

Sim, para o tráfego de saída até o resolvedor. Um firewall que só permite UDP 53 vai lidar bem com a maioria das consultas e depois falhar de forma imprevisível em respostas maiores, tipicamente assinadas com DNSSEC, que precisam da alternativa TCP.

Bloquear a porta 53 interrompe todo o tráfego de DNS?

Não mais. Isso bloqueia o transporte clássico UDP/TCP. O DNS sobre HTTPS roda na porta 443 e parece qualquer outra requisição HTTPS, e o DNS sobre TLS roda na própria porta 853, então um navegador ou aplicativo com qualquer um dos dois ativado continua resolvendo nomes.

O DNS sobre HTTPS é o mesmo protocolo que o DNS comum?

As consultas e respostas são os mesmos registros e códigos de DNS definidos pela RFC 1035. Só o transporte muda: em vez de um pacote UDP ou TCP puro na porta 53, a mesma requisição vai embrulhada dentro de uma requisição HTTPS na porta 443.

Por que o dig às vezes usa TCP sem ser mandado?

Quando uma resposta UDP volta truncada, com o bit TC marcado, um cliente compatível com o padrão reenvia automaticamente a consulta por TCP para obter a resposta completa. Isso aparece com mais frequência em domínios com DNSSEC ativado ou com muitos registros do mesmo tipo.

O mDNS na porta 5353 é o mesmo DNS do meu provedor?

Não. O mDNS só funciona no seu segmento de rede local, não tem servidor central, e resolve nomes como device.local para dispositivos no mesmo link. Ele não tem nenhuma participação na resolução de um domínio público como example.com.

Qual é um tamanho normal de payload EDNS0 hoje?

A RFC 6891 sugere 4096 bytes como padrão prático, e a maioria dos resolvedores atuais anuncia algo nessa faixa, bem acima do teto original de 512 bytes, antes de recorrer ao TCP só quando nem isso é suficiente.