通常のDNSルックアップの場合、Digを使用して、DNSレコードの残りのTTLを含む回答を取得できます。その回答がキャッシュからのものである場合、TTL次の信頼できるクエリまで「カウントダウン」し、そのクエリが表示されるまでの残り時間(この質問に記載されているように: 残りのチェックTTLネームサーバー )。
ネガティブキャッシュされたレコードに対応する「残り時間」を取得するにはどうすればよいですか?答えは、定義上、「NXDOMAIN」または存在しないドメインです。 TTLレコード(可能な最大時間値)を除いて、この回答に関連付けられたSOAはないようです。
[BIND 9]サーバーにも直接アクセスできるので、クエリベースの方法があることを望んでいますが、この情報をキャッシュから直接取得する方法も歓迎します。
サーバーの状態を取得するクエリベースの方法はありません。接着剤、ネガティブキャッシュタイマーなどは、rndc dumpdb
コマンドを使用してメモリからダンプする必要があります。
\-
で始まるレコードタイプはネガティブキャッシュされます。 \-A
、\-AAAA
など。\-ANY
は真のNXDOMAIN
を示します。このエンティティの横または下にレコードはありません。これまでにNODATA
の概念に触れたことがない場合、上記は混乱を招く可能性があります。 ( RFC 2308 )これは、NOERROR
とは対照的に、0の回答でNXDOMAIN
の回答が見られたことを意味します。 NXDOMAIN
は、その名前のレコードがまったく存在しないことを示します。
負のキャッシュエントリの例:
test1.example.com. 442 \-ANY ;-$NXDOMAIN
test2.example.com. 352 \-AAAA ;-$NXRRSET
このファイルを自動的に解析することは、特に繰り返しのためにラベル名が省略されている場合は、気の弱い人向けではありません。
まず、NXDOMAIN
のTTLは、返信のAUTHORITY SECTION
のSOAレコードを介して伝達する必要があります。私の回答を参照してください。 to ネガティブDNSキャッシングは通常どのくらい持続しますか? 詳細については。
後続のクエリでデクリメントTTLを確認することに関する質問について。これはDNSサーバーの実装の詳細だと思います。
私のテストでは、再帰ネームサーバーの中には、後続のリクエストに対してSOAレコードをデクリメントしてTTL)を含むAUTHORITY SECTION
を返さないものもあります。行う。
たとえば、cloudflareリゾルバはそうします(デクリメントTTL値)に注意してください):
$ Dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 674 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.Amazon.com. 1 7200 900 1209600 86400
$ Dig nxdomain.serverfault.com @1.1.1.1 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 668 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.Amazon.com. 1 7200 900 1209600 86400
AWS VPCのデフォルトのリゾルバーは、最初のリクエストでのみ権限セクションで応答します。
$ Dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1
;; AUTHORITY SECTION:
serverfault.com. 300 IN SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
$ Dig nxdomain.serverfault.com @169.254.169.253 | grep 'AUTHORITY SECTION' -A 1 | wc -l
0
権限のあるサーバーは常に完全なTTLを返す必要があります。これは、SOA.MINIMUMフィールドとTTL of SOAレコード自体。再帰(キャッシング)ネームサーバーからの応答では、デクリメントTTLのみが表示されます。
また、再帰サーバーにクエリを実行すると、ロードバランサーがヒットすることが多く、その結果、ヒットしている負荷分散サーバーに応じて異なる回答が得られることにも注意してください。