强制挖掘来解决而不使用缓存

90

我想知道是否有一种查询DNS服务器并绕过缓存（使用dig）的方法。我经常更改DNS服务器上的区域，我想检查它是否可以从我的工作站正确解析。但是由于服务器缓存已解决的请求，所以我经常收到旧请求。重新启动或加载服务器并不是一件好事。

linux domain-name-system dig

— 丹尼尔
source

119

您可以使用@语法从特定服务器中查找域。如果DNS服务器对该域具有权威性，则响应将不是缓存的结果。

dig @ns1.example.com example.com

您可以通过询问NS域的记录来找到权威服务器：

dig example.com NS

— 拉达达达
source

2

哦好的。是的，我熟悉@语法，但是还没有查询权威服务器的想法。谢谢！

— 丹尼尔（Daniel）

3

旁注：如果您尝试查看缓存服务器将获得什么响应，+norecurse建议使用。+recurse默认情况下处于启用状态会偶尔更改DNS服务器完全解释您的问题的方式。

— 安德鲁B

4

如果您正在等待权威服务器的更改怎么办？

— 瓜卡2014年

@KasperSouren您是在谈论权威服务器上的NS记录还是在父服务器上的粘合记录？您可以找到父对象，+trace但要注意缓存。Andrew B很好地解释了缓存如何在等待名称服务器更改时欺骗您。

— Ladadadada 2014年

3

您还可以检查google dns dig @8.8.8.8 example.com。记录在那里出现的快得多。

— machineaddict

25

没有标准，可靠的方法来强制名称服务器在不使用其缓存的情况下进行响应。Dig本身不是名称服务器，它只是一个使用标准DNS请求将查询传递给已配置的名称服务器的工具。这里是一个方式说“不使用递归”，但是这是不是你想要的-它只会防止更广泛的互联网域名的任何查询。

如果要阻止名称服务器从其缓存中响应，则必须通过更改名称服务器上的配置来实现，但是如果您不控制名称服务器，则无法做到这一点。

但是，您可以挖掘以绕过配置的名称服务器，并执行自己的递归请求，该请求将返回到根服务器。为此，请使用该+trace选项。

dig example.com +trace

实际上，由于这只会查询权威服务器，而不是本地缓存解析器，因此即使这些服务器采用内部缓存，结果也不会过时。使用的附加好处+trace是您可以查看路径上的所有单独请求。

— 胸腺
source

10

使用+norecursejust告诉域名服务器返回它所拥有的任何信息（包括缓存的信息，如果有的话），所以这是不正确的。+trace之所以能够工作，是因为它将一直遵循递归链直到权威服务器。

— 拉曼2014年

1

请注意，我修改了此答案以删除+norecurse建议，因为它使问题感到困惑。

— thomasrutter

13

这里要注意的重要一点，我注意到许多人在谈论时从未提到过+trace，那就是使用+tracedig客户端将执行跟踪，而不是在配置（/etc/resolv.conf）中指定的DNS服务器。因此，换句话说，如果您要求，dig客户端将像递归DNS服务器一样工作。但是-重要的是，您没有缓存。

更详细的信息-因此，如果您已经使用要求mx记录，dig -t mx example.com并且/etc/resolv.conf为8.8.8.8，则在区域TTL内执行任何操作都将返回缓存的结果。从某种意义上说，如果您正在寻找有关自己的区域以及Google如何看待它的信息，那么对于Google的区域TTL，您的DNS结果就被毒害了。如果您的TTL短，还不错；如果您的时间是1小时，则有些垃圾。

因此，虽然+trace可以帮助您了解如果您是第一次请求Google并且它没有缓存的条目，那么将会看到什么，但这可能会给您带来一个错误的想法，那就是Google会告诉所有人与您的+trace结果相同的信息，如果您之前曾问过并拥有一个较长的TTL，则不会这样做，因为它将在缓存中提供该服务，直到TTL过期为止-然后，它将与您+trace显示的内容相同。

IMO不能有太多细节。

— c0ntr1but3
source

dig是否拥有自己的缓存或使用OS缓存？

— CMCDragonkai

Dig没有缓存。但是，如果上游域名服务器使用了，它将从中受益。

— thomasrutter

dig mydomain.com +trace刚把我的resolvd存根结果还给我127.0.0.53。参见github.com/systemd/systemd/issues/5897

— James Bowery

使用+tracedig时，将使用指定的名称服务器（例如8.8.8.8，如果您已配置的话）开始跟踪以进行第一次查找（根区域），但之后它将使用返回的名称服务器进行进一步查询。因此，如果您配置的名称服务器不起作用或无法正确响应对根名称服务器的查询，则可能会遇到问题（如以上注释中所述）。

— thomasrutter

2

此bash将从其第一个列出的名称服务器中挖掘example.com的DNS条目：

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer

内部挖掘查询Google的DNS（8.8.8.8）以获取example.com的名称服务器。
外部dig查询example.com的名字服务器。

这与.zshrc（可能还有.bashrc）的别名相同：

# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }

这是/。的输出：

☀  checkdns slashdot.org                                                                                                dev
-->Server DNS Query

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org.       21600   IN  SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org.       86400   IN  NS  ns3.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns4.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns0.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns2.dnsmadeeasy.com.
slashdot.org.       86400   IN  NS  ns1.dnsmadeeasy.com.
slashdot.org.       3600    IN  MX  10 mx.sourceforge.net.
slashdot.org.       3600    IN  TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org.       300 IN  A   216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms

--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms

该解决方案非常复杂，难以记住，但又非常简单，无法解决问题。 dig这不是我的专长-欢迎改进:-)

— 迈克尔·科尔
source