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

#1 楼

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

dig @ns1.example.com example.com


您可以通过查询NS记录来查找权威服务器。域:

dig example.com NS


评论


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

–丹尼尔(Daniel)
2012年3月21日在17:22

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

–安德鲁(Andrew B)
13年1月1日在4:37

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

–kqw
2014年8月5日12:12



@KasperSouren您是在谈论权威服务器上的NS记录,还是父母上的胶水记录?您可以使用+ trace查找父级,但要注意缓存。 Andrew B写了一个很好的解释,说明了在等待名称服务器更改时缓存如何欺骗您。

– Ladadadada
2014年8月7日在6:46

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

–machineaddict
18 Mar 26 '18在10:47

#2 楼

DNS协议中没有机制可以强制名称服务器不使用其缓存进行响应。 Dig本身不是名称服务器,它只是一个使用标准DNS请求将查询传递给已配置的名称服务器的工具。 DNS确实包含一种告诉服务器不要使用递归的方法,但这不是您想要的。这仅在您要直接查询权威名称服务器时有用。

如果要阻止名称服务器从其缓存中响应,则只能通过更改名称服务器上的配置来做到这一点。 ,但是如果您不控制名称服务器,这是不可能的。

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

dig example.com +trace


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

评论


使用+ norecurse只是告诉名称服务器返回其拥有的任何信息(包括高速缓存的信息,如果有的话),所以这是不正确的。 + trace之所以有效,是因为它将一直遵循递归链直到一台权威服务器。

–拉曼
2014年12月5日在21:54

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

–胸腺
17年5月31日在0:01

我无法找到此“挖掘”命令。它似乎不是标准的Windows命令。命令提示符给我一条错误消息。

–David Spector
20年2月7日在13:30

@DavidSpector dig是ISC的BIND附带的软件工具-虽然它在Linux上很常见,但也可以从Bind的网站上正式用于Windows。下载当前稳定的Windows版本的Bind作为zip,解压缩并查找dig.exe-有关Google在Windows上使用dig dns工具的更多说明。不要遵循任何说明,包括将文件复制到/ Windows / System32

–胸腺
20-2-9在22:33



您可以通过Windows上用于Linux的新Windows子系统(WSL)使用它

– Erik Oppedijk
20-3-12在21:06

#3 楼

这里需要注意的重要一点,我注意到许多人在谈论+trace时从来没有包括过,使用+trace意味着dig客户端将进行跟踪,而不是在配置(/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短,那还不错;如果您的TTL是1小时,那还有些垃圾。

因此,虽然+trace可以帮助您了解如果您第一次向Google询问,将会看到什么?没有缓存的条目,这可能会给您带来一个错误的想法,那就是Google会告诉所有人与您的+trace结果相同,如果您之前曾问过并且TTL较长,它将不会告诉您,因为它将为您服务从缓存中直到TTL到期-然后它将与您的+trace所显示的内容相同。

IMO的详细信息不能太多。

评论


dig是否拥有自己的缓存或使用操作系统缓存?

– CMCDragonkai
16 Dec 22 '13:04

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

–胸腺
17年3月18日在13:55

dig mydomain.com + trace仅返回127.0.0.53的resolvd存根结果。见github.com/systemd/systemd/issues/5897

–詹姆斯·鲍里(James Bowery)
17-6-7-23:42



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

–胸腺
17年5月5日在12:01

#4 楼

此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的
名称服务器。
外部挖掘查询example.com的名字服务器。

与.zshrc(可能还有.bashrc)的别名相同:

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


这是/。的输出:

☀  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不是我的专长-
欢迎改进:-)