我想知道是否有一种方法来查询DNS服务器和绕过caching（ dig ）。 通常我更改DNS服务器上的一个区域，我想检查它是否能正确parsing我的工作站。 但是，由于服务器caching已解决的请求，我经常得到旧的。 重新启动或加载服务器并不是什么好事。
您可以使用@语法从特定服务器查找域。 如果DNS服务器对该域具有权威性，则该响应不会是caching的结果。
dig @ns1.example.com example.com
您可以通过询问某个域的NSlogging来查找权威服务器：
dig example.com NS
没有标准的，可靠的方法来强制域名服务器响应而不使用caching。 挖掘本身不是一个域名服务器，它只是一个工具，使用标准的DNS请求，将您的查询传递给您configuration的任何名称服务器。 有一种方法可以说“不使用recursion”，但这不是你想要的 – 它只是阻止在更广泛的互联网上查找域名。
如果你想停止一个域名服务器响应它的caching，你必须通过改变域名服务器上的configuration来实现这一点，但是如果你不控制域名服务器，你不能这样做。
但是，您可以让dig 绕过configuration的名称服务器，并执行自己的recursion请求，回到根服务器。 为此，请使用+trace选项。
dig example.com +trace
在实践中，因为这只会查询授权服务器而不是本地cachingparsing器，即使这些服务器使用内部caching，结果也不会过时。 使用+trace的附加好处是您可以查看沿path所做的所有单独请求。
这里要注意一些重要的事情，我注意到很多人在讨论+trace时候并没有包含任何内容，使用+trace意味着dig客户端将执行跟踪，而不是configuration中指定的DNS服务器（/etc/resolv.conf ）。 所以，换句话说，你的挖掘客户端将像recursion的DNS服务器那样工作，如果你问的话。 但是 – 重要的是，你没有caching。
更多细节 – 所以如果你已经使用dig -t mx example.com来请求mxlogging，而你的/etc/resolv.conf是8.8.8.8，那么在区域的TTL内部做任何事情都会返回caching的结果。 从某种意义上说，如果您正在寻找关于您自己的区域以及Google如何看待这些区域的信息，那么您已经使用Google针对您的区域的TTL中毒了您的DNS结果。 不错，如果你有一个短的TTL，如果你有一个1小时的有点垃圾。
所以， +trace会帮助你看看如果你第一次问Google，而且没有caching条目，会看到什么，这可能会给你一个错误的想法，即Google会告诉每个人跟你的+trace结果是，如果你以前要求过TTL，那么它就不会，因为它会从caching中提供，直到TTL到期 – 那么它的function与你的+trace显示的一样。
IMO不能有太多的细节。