tcpdump códigos de saída dns

Question

Capturado no servidor de nomes:

21:54:35.391126 IP resolver.7538 > server.domain: 57385% [1au] A? www.domain.de. (42)

O que o sinal de porcentagem em 57385% significa? Tanto quanto eu posso ver 57385 é o número de seqüência de clientes, um plus significaria RD bit set.

Segunda pergunta: o que o ARCOUNT faz na consulta? Pelo que entendi a man page do tcpdump, o [1au] significa que o tcpdump trata isso como uma anomalia de protocolo - como eu veria isso em muitas consultas.

    

Answer 1

Leia a fonte Luke:)

Do tcpdump / print-domain.c:

printf("%d%s%s%s", EXTRACT_16BITS(&np->id), ns_ops[DNS_OPCODE(np)],
    DNS_RD(np) ? "+" : "",
    DNS_CD(np) ? "%" : "");

Portanto,% indica "verificação desabilitada", o que, segundo minha compreensão, de RFC4035 indica que o resolvedor não está impondo autenticação dos RRs no servidor.

De bind / lib / bind / resolv / res_mkquery.c:

int
res_nopt(res_state statp,
     int n0,                /*%< current offset in buffer */
     u_char *buf,           /*%< buffer to put query */
     int buflen,            /*%< size of buffer */
     int anslen)            /*%< UDP answer buffer size */
{
[...]
hp->arcount = htons(ntohs(hp->arcount) + 1);

De acordo com RFC2671 , é perfeitamente legal que um resolvedor inclua dados adicionais e, com isso, aumente o pacote UDP tamanho acima do limite de 512 bytes. Então a suposição de Ladadadada está correta neste aspecto.

Obrigado pelo seu tempo e desculpe por eu não ter lido a fonte antes ...

    

Answer 2

O número 57385 é, na verdade, o ID da consulta, não o número de sequência. Na verdade, os números de sequência só existem no TCP e isso é UDP. O ID da consulta é necessário para que o cliente possa separar duas respostas se duas consultas forem feitas ao mesmo tempo.

[1au] nas consultas parece estar com OPT UDPsize=4096 , o que indica ao servidor que o cliente pode manipular respostas de até 4096 bytes. Nos meus testes eu sempre encontrei esses dois juntos. Sem a opção -vv , você não recebe o OPT UDPsize=4096 extra.

Originalmente, as respostas de DNS seriam de apenas 512 bytes e, se a resposta fosse maior do que isso, somente os primeiros 512 bytes seriam enviados e um bit seria definido para indicar que a resposta havia sido truncada. Uma consulta de acompanhamento foi feita pelo cliente sobre TCP para que toda a resposta pudesse ser transmitida. Com os registros IPv6 sendo agora muito mais longos do que os registros IPv4, são necessárias respostas maiores e para evitar sempre o TCP, uma extensão foi adicionada ao DNS para permitir respostas maiores.

Eu executei meu próprio tcpdump até obter um símbolo % na minha saída. Usando as opções -vv e -n e apenas olhando para consultas, é isso que eu recebi:

    192.168.1.42.60121 > 8.8.4.4.53: [bad udp cksum 92ce!] 57372+ [1au] MX? blah.com. ar: . OPT UDPsize=4096 OK (37)
21:40:37.185712 IP (tos 0x0, ttl 64, id 19492, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.20518 > 8.8.4.4.53: [bad udp cksum d7d9!] 43610+% [1au] A? ns1.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.185867 IP (tos 0x0, ttl 64, id 19493, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.15605 > 8.8.4.4.53: [bad udp cksum e0b2!] 51586+% [1au] AAAA? ns1.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186023 IP (tos 0x0, ttl 64, id 19494, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.34562 > 8.8.4.4.53: [bad udp cksum 4a5d!] 61450+% [1au] A? ns2.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186177 IP (tos 0x0, ttl 64, id 19495, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.56713 > 8.8.4.4.53: [bad udp cksum 5dd1!] 2672+% [1au] AAAA? ns2.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186327 IP (tos 0x0, ttl 64, id 19496, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.14021 > 8.8.4.4.53: [bad udp cksum 60f3!] 43568+% [1au] A? ns3.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186483 IP (tos 0x0, ttl 64, id 19497, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.22412 > 8.8.4.4.53: [bad udp cksum 4bca!] 38782+% [1au] AAAA? ns3.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186639 IP (tos 0x0, ttl 64, id 19498, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.50256 > 8.8.4.4.53: [bad udp cksum 6a0e!] 411+% [1au] A? ns4.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)
21:40:37.186785 IP (tos 0x0, ttl 64, id 19499, offset 0, flags [none], proto UDP (17), length 74)
    192.168.1.42.3213 > 8.8.4.4.53: [bad udp cksum adcb!] 57626+% [1au] AAAA? ns4.acotel.net.br. ar: . OPT UDPsize=4096 OK (46)

Eu recebo um SERVFAIL quando solicito os registros MX de blah.com. Quando eu solicito os registros NS para o blah.com, recebo os quatro domínios que você pode ver que possuem o símbolo % . Presumivelmente, algum cliente ou biblioteca de resolução (provavelmente bind9) segue um SERVFAIL com pedidos para os registros NS. Eu achei isso consistente ao fazer pesquisas para os registros MX do blah.com e vi o mesmo padrão com outros domínios. Meu palpite é que o símbolo % indica que esta é uma subconsulta não iniciada pelo cliente, mas necessária para retornar uma resposta.

Tenho certeza de que tcpdump não sabe o que a ligação está fazendo nos bastidores, então espero que deve haver um sinalizador definido na consulta que faz com que tcpdump coloque isso aqui. Eu posso dar uma olhada na opção -x mais tarde para ver se consigo descobrir o que é.