回答:
@構文を使用して、特定のサーバーからドメインを検索できます。DNSサーバーがそのドメインに対して権限がある場合、応答はキャッシュされた結果ではありません。
dig @ns1.example.com example.com
NSドメインのレコードを要求することにより、権限のあるサーバーを見つけることができます。
dig example.com NS
+norecurse推奨されます。+recurseデフォルトでオンにすると、DNSサーバーが質問を完全に解釈する方法が変更される場合があります。
+traceが、キャッシングには注意してください。Andrew Bは、ネームサーバーが変更されるのを待つとき、キャッシュがどのようにあなたをだますことができるかについての良い説明を書きました。
dig @8.8.8.8 example.com。記録はより速く表示されます。
DNSプロトコルには、キャッシュを使用せずにネームサーバーに強制的に応答させるメカニズムはありません。Dig自体はネームサーバーではなく、標準のDNS要求を使用して、設定したネームサーバーにクエリを渡す単なるツールです。DNSには、再帰を使用しないようにサーバーに指示する方法が含まれていますが、これは望みではありません。これは、権限のあるネームサーバーに直接クエリする場合にのみ役立ちます。
ネームサーバーのキャッシュからの応答を停止したい場合は、ネームサーバーの構成を変更することによってのみ行うことができますが、ネームサーバーを制御しない場合、これは不可能です。
ただし、設定されたネームサーバーをバイパスして掘り下げて、ルートサーバーに戻る独自の再帰要求を実行できます。これを行うには、+traceオプションを使用します。
dig example.com +trace
実際には、これはローカルキャッシュリゾルバではなく権限のあるサーバーにのみクエリを実行するため、それらのサーバーが内部キャッシュを使用していても、結果は古くなりません。を使用+traceすることの追加の利点は、パスに沿って行われた個別のリクエストをすべて表示できることです。
+norecurseすると、ネームサーバーが持っている情報（キャッシュされている情報がある場合はそれも含む）を返すように指示するだけなので、それは正しくありません。+trace信頼できるサーバーまで再帰チェーンをたどるので動作します。
+norecurse問題を混乱させるため、この回答を修正して推奨事項を削除していることに注意してください。
ここで注意すべき重要なことは、多くの人が話して+traceいるときに含めないことに気づくのは、使用+traceすると、config（/etc/resolv.conf）で指定されたDNSサーバーではなく、digクライアントがトレースを行うことです。つまり、言い換えれば、あなたの掘り出しクライアントは、もしあなたが尋ねれば、再帰的なDNSサーバーのように動作します。しかし、重要なことは、キャッシュがありません。
詳細-したがって、すでに/etc/resolv.confが8.8.8.8 mxを使用dig -t mx example.comしてレコードを要求している場合、ゾーンのTTL内で何かを行うと、キャッシュされた結果が返されます。ある意味で、自分のゾーンについて何かを探しているのであれば、Googleがそれをどのように見ているのか、ゾーンのTTLについてDNSの結果をGoogleで汚染しているのです。TTLが短い場合は悪くありませんが、1時間ある場合は多少ゴミになります。
したがって、+trace最初にGoogleに問い合わせていて、エントリがキャッシュされていなかった場合に、どのような+trace結果が表示されるかを確認するのに役立ちますが、Googleがすべてのユーザーに結果と同じことを伝えるという誤った考えを与える可能性がありますTTLが期限切れになるまでキャッシュからサービスを提供するので、以前に尋ねてTTLが長い場合は表示されません。その後、+trace公開したものと同じサービスが提供されます。
IMOの詳細が多すぎることはありません。
dig mydomain.com +traceresolvdからのスタブ結果を返すだけです127.0.0.53。参照してくださいgithub.com/systemd/systemd/issues/5897
+trace掘ることは始まります（それはあなたが設定したものだ場合例えば、8.8.8.8）最初のルックアップ（ルートゾーン）に指定したネームサーバを使用してトレースを、それの後にそれがさらにクエリの返されたネームサーバを使用しています。したがって、設定されたネームサーバーが機能していない場合、またはルートネームサーバーのクエリに適切に応答しない場合、問題が発生する可能性があります（上記のコメントのように）。
このbashは、最初にリストされたネームサーバーからexample.comのDNSエントリを掘ります：
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
これは、.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私の専門ではありません-改善を歓迎します:-)