主页 / server / 问题 / 399911
Accepted
tim
Asked: 2012-06-19 12:25:34 +0800 CST

tcpdump dns 输出代码

  • 772

在名称服务器上捕获：

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

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

第二个问题：ARCOUNT在查询中做了什么？据我了解 tcpdump 手册页，[1au] 意味着 tcpdump 将此视为协议异常 - 我也是如此。我在很多查询中都看到了这一点。

domain-name-system tcpdump

2 个回答

  1. Best Answer

    阅读来源 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 字节限制以上。所以拉达达达达在这方面的假设是正确的。

    感谢您的宝贵时间，抱歉我之前没有阅读源代码...

    • 5

  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选项，看看我是否可以找出它是什么。

    • 3

相关问题