Захвачено на сервере имен:
21:54:35.391126 IP resolver.7538 > server.domain: 57385% [1au] A? www.domain.de. (42)
Что означает знак процента в 57385%? Насколько я понимаю, 57385 - это порядковый номер клиента, плюс означает установленный бит RD.
Второй вопрос: что делает ARCOUNT в запросе? Насколько я понимаю на странице руководства tcpdump [1au] означает, что tcpdump рассматривает это как аномалию протокола - как и я. Я вижу это во многих запросах.
Прочтите первоисточник Люк :)
Из tcpdump / print-domain.c:
printf("%d%s%s%s", EXTRACT_16BITS(&np->id), ns_ops[DNS_OPCODE(np)],
DNS_RD(np) ? "+" : "",
DNS_CD(np) ? "%" : "");
Итак,% означает "проверка отключена", что, насколько я понимаю, RFC4035 указывает, что распознаватель не обеспечивает аутентификацию записей RR на сервере.
Из 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);
В соответствии с RFC2671 Для резолвера совершенно законно включать дополнительные данные и, таким образом, увеличивать размер пакета UDP выше предела в 512 байт. Итак, предположение Ладададады в этом аспекте верно.
Спасибо за ваше время и извините, что не читал источник раньше ...
Число 57385 на самом деле является идентификатором запроса, а не порядковым номером. Фактически, порядковые номера существуют только в TCP, и это UDP. Идентификатор запроса требуется, чтобы клиент мог отличить два ответа, если два запроса выполняются одновременно.
[1au] в запросах, кажется, идет с OPT UDPsize=4096 что указывает серверу, что клиент может обрабатывать ответы размером до 4096 байт. В своих тестах я всегда находил этих двоих вместе. Без -vv вариант, вы не получите лишнего OPT UDPsize=4096.
Первоначально ответы DNS были бы только 512 байт, и если ответ был длиннее, были отправлены только первые 512 байт и был установлен бит, указывающий, что ответ был усечен. Клиент сделал дополнительный запрос по TCP, чтобы можно было передать весь ответ. Поскольку записи IPv6 теперь намного длиннее записей IPv4, требуются более крупные ответы, чтобы избежать всегда используя TCP, к DNS было добавлено расширение, позволяющее получать более крупные ответы.
Я запускал свой собственный tcpdump, пока не получил % символ в моем выводе. Используя параметры -vv и -n и глядя только на запросы, я получил следующее:
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)
Я получаю SERVFAIL при запросе записей MX для blah.com. Когда я запрашиваю записи NS для blah.com, я получаю четыре домена, которые, как вы видите, имеют % условное обозначение. Предположительно, некоторая клиентская или разрешающая библиотека (возможно, bind9) следует за SERVFAIL запросами на записи NS. Я обнаружил, что это было согласованно при поиске записей MX на blah.com, и я увидел тот же образец для других доменов. Я предполагаю, что % символ указывает, что это подзапрос, не инициированный клиентом, но необходимый для возврата ответа.
Я уверен tcpdump не знает, что связывает за кулисами, поэтому я ожидаю, что в запросе должен быть установлен флаг, вызывающий tcpdump поместить это сюда. Я мог бы взглянуть на -x вариант позже, чтобы посмотреть, смогу ли я узнать, что это такое.