Por dentro de uma mensagem DNS: flags, seções e formato wire

Toda consulta DNS, de um navegador pedindo um endereço a um resolvedor seguindo uma delegação, é uma curta mensagem binária em um único formato comum. Raramente você vê os bytes, mas ferramentas como o dig exibem os campos do cabeçalho como texto, e saber o que eles significam transforma essa saída de ruído em evidência. O formato é especificado pela RFC 1035 desde 1987, refinando a RFC 883 de 1983, e desde então foi estendido, não substituído.

O cabeçalho de 12 bytes

Toda mensagem começa com os mesmos 12 bytes: um ID de 16 bits, uma palavra de 16 bits com flags e códigos, e quatro contagens de 16 bits.

Depois do cabeçalho vêm as quatro seções, nessa ordem. A seção de pergunta repete o que foi perguntado, a seção de resposta contém os registros que a respondem, a seção de autoridade aponta para os servidores de nomes responsáveis pela zona, e a seção adicional traz registros extras que o servidor espera que o cliente queira em seguida, como os endereços desses servidores de nomes.

Trate o AA com cuidado. Um resolvedor recursivo que responde a partir do seu cache não é uma autoridade para esses dados e não o ativa. No projeto original, um servidor marca uma resposta como autoritativa quando responde a partir de dados de zona que ele mantém, em oposição a dados em cache (Mockapetris e Dunlap, 1988). Ver aa em uma resposta de um dos servidores de nomes da própria zona é o caso normal, exceto no caso de uma referência a uma zona filha, que não o traz nem mesmo de um servidor autoritativo.

Lendo a linha de cabeçalho do dig

O dig imprime o cabeçalho em duas linhas. Uma resposta típica é assim:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6891
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

opcode e status são os campos Opcode e RCODE. A linha flags lista os bits que estão ativados, aqui qr, rd e ra, que juntos significam: uma resposta, a uma consulta que pediu recursão, vinda de um servidor que a oferece. As quatro contagens são os tamanhos das seções. O ADDITIONAL: 1 costuma ser o pseudorregistro EDNS do servidor, devolvido porque o dig inclui um na sua consulta; não é um endereço extra.

O status é a coisa mais rápida de ler. A RFC 1035 define seis códigos de resposta.

Um resultado comum não tem código próprio. Um nome que existe, mas não tem registro do tipo que você pediu, retorna NOERROR sem registros desse tipo na seção de resposta (um CNAME ainda pode aparecer), o que a RFC 2308 chama de NODATA. A diferença importa no diagnóstico; veja NXDOMAIN explicado e Timeout de DNS vs. SERVFAIL para saber o que fazer em cada caso.

Uma consulta, byte a byte

Esta é uma consulta completa pelo registro A de example.com em sua forma clássica, sem EDNS, como um cliente a enviaria com recursão solicitada. Ela tem 29 bytes.

1a 2b 01 00 00 01 00 00 00 00 00 00 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01

Os mesmos bytes viajam dentro de transportes criptografados. No DNS sobre HTTPS (RFC 8484), por exemplo, a mesma mensagem viaja como o corpo bruto de um POST HTTP ou, em uma requisição GET, codificada em base64url em um parâmetro dns, e recomenda-se que os clientes definam o ID como 0; veja DNS sobre HTTPS e DNS sobre TLS explicados.

Nomes, limites e compressão

Um nome é uma sequência de rótulos, cada um precedido pelo seu comprimento, terminando em um byte zero. A RFC 1035 limita um rótulo a 63 octetos e um nome inteiro a 255. Como o byte de comprimento de um rótulo nunca passa de 63, seus dois bits mais significativos são sempre zero, e isso deixou espaço para a compressão: quando os dois bits mais significativos são ambos um, esse byte e o seguinte formam um ponteiro, e os 14 bits restantes dão um deslocamento a partir do início da mensagem. Em uma resposta, o nome da resposta é muito comumente representado pelos dois bytes c0 0c, um ponteiro para o deslocamento 12, onde o nome da pergunta começa logo depois do cabeçalho. Todo programa DNS deve entender ponteiros nas mensagens que recebe, embora possa optar por não os produzir.

Por que 512 bytes importavam e o que os substituiu

A RFC 1035 restringe as mensagens UDP a 512 bytes, sem contar os cabeçalhos IP e UDP. Uma mensagem mais longa é truncada e o bit TC é ativado, o que informa ao cliente que deve tentar de novo por TCP. Os projetistas originais consideraram o limite do datagrama um sucesso, e não um problema: o desempenho era muito melhor do que sobre circuitos TCP e os recursos do sistema operacional não ficavam presos, embora a escolha exigisse estratégias cuidadosas de retransmissão (Mockapetris e Dunlap, 1988).

À medida que as respostas cresceram com o IPv6 e o DNSSEC, o limite ficou apertado. O EDNS(0), definido na RFC 6891, permite que um cliente anuncie um tamanho de payload UDP maior em um pseudorregistro OPT. A RFC sugere 4096 octetos como ponto de partida e, se isso falhar, um recuo para uma faixa de cerca de 1280 a 1410 bytes. Desde a RFC 7766, em 2016, o suporte a TCP é uma parte obrigatória de uma implementação completa de DNS. Respostas UDP maiores também têm um custo de segurança, porque tornam os ataques de reflexão mais lucrativos; Ataques de amplificação de DNS e resolvedores abertos trata disso.

Fontes e leitura complementar

• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• RFC 2535: Domain Name System Security Extensions (Eastlake, 1999)
• RFC 4035: Protocol Modifications for the DNS Security Extensions (Arends et al., 2005)
• RFC 6891: Extension Mechanisms for DNS (EDNS(0)) (Damas, Graff and Vixie, 2013)
• RFC 7766: DNS Transport over TCP - Implementation Requirements (Dickinson et al., 2016)
• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)
• Kevin R. Fall and W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols, 2nd edition (Addison-Wesley, 2011)