在过去的几天里，我编写了一个名为dnspeep的小工具，它可以让您查看在您的计算机上进行的DNS查询并查看响应。现在只有250行Rust代码。我讨论了如何尝试它，它能做什么，我为什么要写它，以及我在开发它时遇到的问题。如何试用我构建了一些二进制文件，因此您可以快速试用一下。对于Linux(x86)：wgethttps://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-linux.tar.gztar-xfdnspeep-linux.tar.gzsudo./dnspeep对于Mac:wgethttps://github.com/jvns/dnspeep/releases/download/v0.1.0/dnspeep-macos.tar.gztar-xfdnspeep-macos.tar.gzsudo./dnspeep它需要以超级用户root身份运行因为它需要访问您的计算机发送的所有DNS数据包。这与tcpdump需要作为super运行的原因相同：它使用libpcap，与tcpdump使用的库相同。如果您不想以root身份运行下载的二进制文件，您也可以在https://github.com/jvns/dnspeep查看源代码并自行编译。输出结果如下所示。每行是一个DNS查询和响应：$sudodnspeepquerynameserverIPresponseAfirefox.com192.168.1.1A:44.235.246.155,A:44.236.72.93,A:44.236.48.31AAAAfirefox.com192.168.1.1NOERRORAbolt.dropbox.com192.168.1.1CNAME:bolt.v.dropbox.com,A:162.125.19.131这些查询来自我浏览器中的neopets.com，而bolt.dropbox.com查询是因为我正在运行Dropbox代理，我猜测它不时在后台运行，因为它需要同步。为什么我要开发另一个DNS工具？我这样做是因为我认为当您不太了解DNS时，它看起来真的很神秘！您的浏览器（以及您计算机上的其他软件）一直在进行DNS查找，我认为当您实际看到请求和响应时，似乎更“真实”。我写这个也是作为调试工具。当我想到“这是DNS问题吗？”时，通常很难回答。我的印象是人们在尝试检查问题是否出在DNS上时经常使用反复试验或猜测，而不是仅仅查看计算机收到的DNS响应。您可以看到哪些软件正在“秘密”使用互联网我喜欢这个工具的一件事是它让我可以看到我电脑上的哪些程序正在使用互联网！例如，我发现我电脑上的某些软件不知为何一直在向ping.manjaro.org发送请求，可能是为了检查我是否已连接到Internet。事实上，我的一个朋友使用这个工具发现他的计算机上安装了一些以前工作时忘记卸载的公司监控软件，所以你甚至可能会找到想要删除的东西。如果您不习惯tcpdump，可能会感到困惑当我试图向人们展示他们的计算机正在执行的DNS查询时，我的第一直觉是“好吧，使用tcpdump”！而tcpdump确实可以解析DNS包！例如，这是对incoming.telemetry.mozilla.org的DNS查询结果：11:36:38.973512wlp3s0OutIP192.168.1.181.42281>192.168.1.1.53:56271+A?incoming.telemetry.mozilla.org.(48)11:36:38.996060wlp3s0IP192.168.1.1.53>192.168.1.181.42281:562713/0/0CNAMEtelemetry-incoming.r53-2.services.mozilla。com.,CNAMEprod.data-ingestion.prod.dataops.mozgcp.net.,A35.244.247.133(180)一定要学会读懂，比如我们分解查询：192.168.1.181.42281>192.168.1.1.53：56271+一个？incoming.telemetry.mozilla.org。(48)一个？表示这是Aincoming.telemetry.mozilla.org类型的DNS查询。是被查询的名称56271是DNS查询的ID192.168.1.181.42281是源IP/端口192.168.1.1.53是目的IP/端口(48)是DNS包长度在响应包中，我们可以像这样分解它：562713/0/0CNAMEtelemetry-incoming.r53-2.services。mozilla.com.,CNAMEprod.data-ingestion.prod.dataops.mozgcp.net.,A35.244.247.133(180)3/0/0是响应消息中的记录数：3个回答，0个权威记得records,0additionalrecords我认为tcpdump甚至只是打印出answer响应消息。CNAMEtelemetry-incoming.r53-2.services.mozilla.com、CNAMEprod.data-ingestion.prod.dataops.mozgcp.net.、A35.244.247.133是三个响应记录。56271是响应报文的ID，对应查询报文的ID。这就是您如何知道它是对先前线路请求的响应。在我看来，这种格式最困难的事情（对于只想查看一些DNS流量的人）是您必须手动匹配请求和响应，而且它们并不总是在相邻的行上。这就是计算机擅长的！所以我决定写一个小程序（dnspeep）来做匹配，排除一些我认为多余的信息。我在写这篇文章时遇到的问题我遇到了一些问题：我必须修补pcap包才能在MacOS上与Tokio一起工作（这个改变）。这是花了很多时间才弄清楚的错误之一，只用了一行代码就修复了:smiley:不同的Linux发行版似乎有不同版本的libpcap.so。所以我不能轻易分发动态链接libpcap的二进制文件（你可以在这里看到其他人也有同样的问题）。因此，我决定在Linux上将libpcap静态编译成这个工具。我仍然不太明白如何在Rust中正确地执行此操作，但我通过将libpcap.a文件复制到target/release/deps目录然后直接运行cargobuild来让它工作。我使用的dns_parsercarte不支持所有的DNS查询类型，只支持最常见的。我可能需要切换到不同的工具包来解析DNS数据包，但到目前为止还没有找到合适的工具包。因为pcap接口只提供原始字节（包括以太网帧），所以我需要编写代码来计算从头开始剥离多少字节才能得到数据包的IP标头。我很确定我遗漏了一些案例。我也很难为它想出一个名字，因为那里有太多的DNS工具（dnsspy！dnssnoop！dnssniff！dnswatch！）我基本上只是查找“listen”的每个同义词并选择一个看起来像有趣且尚未被其他DNS工具采用。该程序没有做的一件事是告诉您哪个进程进行了DNS查询，我找到了一个名为dnssnoop的工具来执行此操作。它使用eBPF，看起来很酷，但我还没有尝试过。可能有很多错误我只是在Linux和Mac上简单测试过，我知道至少一个错误（不支持足够多的DNS查询类型），所以如果您遇到问题请告诉我！虽然这个错误是无害的，因为libpcap接口是只读的。所以可能发生的最糟糕的事情是它得到一些它无法解析的输入并最终打印错误或崩溃。编写一个小的教育工具很有趣最近，我对编写一个小型的DNS教育工具产生了浓厚的兴趣。到目前为止我编写的工具：https://dns-lookup.jvns.ca（一种进行DNS查找的简单方法）https://dns-lookup.jvns.ca/trace.html（在发生了什么时向您展示在内部进行DNS查询时）这个工具(dnspeep)以前我尽力解释现有的工具（例如dig或tcpdump）而不是自己编写，但我经常发现这些工具的输出令人困惑，所以我有一个很多人都专注于以更友好的方式查看相同的信息，以便每个人都可以了解他们的计算机正在执行的DNS查询，而不仅仅是依赖tcmdump。
