☰

tcpdump dns 输出代码

tag-icon • tag-icon domain-name-system tcpdump
tcpdump dns 输出代码

在名称服务器上捕获：

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

57385% 中的百分号是什么意思？据我所知，57385 是客户端序列号，加号表示设置了 RD 位。

第二个问题：ARCOUNT 在查询中起什么作用？据我了解，tcpdump 手册页中的 [1au] 表示 tcpdump 将此视为协议异常 - 我也这么认为。我在很多查询中都看到过这种情况。

答案1

阅读原文 Luke :)

来自 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 字节的限制。因此 Ladadadada 的假设在这方面是正确的。

感谢您的时间，很抱歉我之前没有阅读过资料来源......

答案2

数字 57385 实际上是查询 ID，而不是序列号。事实上，序列号只存在于 TCP 中，而这是 UDP。查询 ID 是必需的，这样如果同时进行两个查询，客户端就可以区分两个答案。

[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)

当我请求 blah.com 的 MX 记录时，我得到了 SERVFAIL。当我请求 blah.com 的 NS 记录时，我得到了您可以看到的带有符号的四个域%。据推测，某个客户端或解析库（可能是 bind9）在 SERVFAIL 之后请求 NS 记录。我发现在查找 blah.com 的 MX 记录时这是一致的，并且我看到其他域也有相同的模式。我猜想符号表示%这是一个不是由客户端发起但需要返回答案的子查询。

我确信tcpdump我不知道 bind 在幕后做了什么，所以我估计查询中一定设置了一个标志，导致tcpdump将其放在这里。我稍后可能会查看该-x选项，看看是否能找出它是什么。

相关内容