DNSサーバーがレコードを検索して欠落している場合、このレコードが欠落しているという事実をしばしば「ネガティブキャッシュ」し、しばらくの間再度検索しようとはしません。ネガティブキャッシュのTTLについてRFCには何も記載されていないので、ややarbitrary意的だと思います。現実の世界では、これらのネガティブな記録はどれくらいの期間存続しますか？
回答:
ネガティブキャッシュのTTLは任意ではありません。これは、要求されたレコードが存在する場合、要求されたレコードが属するゾーンの最上部のSOAレコードから取得されます。例えば：
example.org. IN SOA master-ns1.example.org. Hostmaster.example.org. (
2012091201 43200 1800 1209600 86400 )
SOAレコードの最後の値（「86400」）は、クライアントが負の結果をキャッシュするように要求された時間example.org.です。
クライアントがリクエストしたdoesnotexist.example.org.場合、結果を86400秒間キャッシュします。
これは、「ネガティブクエリ」の正確な定義によって異なりますが、いずれの場合も、rfc2308 «DNSクエリのネガティブキャッシング（DNS NCACHE）»に記載されています。
NXDOMAINNXDOMAIN場合、応答にはTTL（従来はフィールドと呼ばれる）SOAを含むレコードが含まれます。 NXDOMAINMINIMUMrfc2308#section-4SERVFAIL解決が成功せず、タイムアウト（ SERVFAIL）になった場合、まったくキャッシュされない可能性があり、すべての状況で5分以上キャッシュされてはなりません（MUST NOT）。 rfc2308#section-7.1
実際には、このような結果を5分間完全にキャッシュすることは、キャッシュサーバーが一時的な接続の問題に直面する場合にクライアントのエクスペリエンスを低下させる素晴らしい方法であり、サービス拒否の増幅に対して簡単に脆弱になります。数秒間のダウンタイムにより、DNSの特定の部分が5分間停止します）。
BIND 9.9.6-S1（2014年にリリース）より前は、明らかにSERVFAILキャッシュされていませんでした。 a878301（2014-09-04）
たとえば、質問の時点で、2014年より前にリリースされたBINDのすべてのバージョンでSERVFAIL、上記のコミットと9.9.6-S1の最初の導入に関するドキュメントが信じられる場合、BIND再帰リゾルバーはまったくキャッシュしませんでした。
最新のBINDでは、デフォルトservfail-ttlは1sであり、設定は30s（RFCによって義務付けられた上限の代わりに）の上限にハードコーディングされています300s。 90174e6（2015-10-17）
さらに、以下はこの問題に関する注目に値する引用です。
SERVFAIL応答のキャッシングの結果には、特にクライアントに表示されるSERVFAILの原因が一時的なものであり、クエリの即時再試行が発生するシナリオから、クライアントエクスペリエンスに有害であると思われるいくつかの状況が含まれています。より適切なアクション。
2番目の戦術は、広く普及しているDNSクライアントがすべてのDNSサーバーに到達できない場合、特に悪を行うと主張することです。この議論の問題は、主張が偽であることです。そのようなクライアントは明らかにバグが多く、市場で生き残ることができません。クライアントのルーターが短時間停止した場合や、クライアントのネットワークが一時的にフラッディングした場合にどうなるかを検討してください。
要約すると、NXDOMAIN応答はSOA該当するゾーンで指定されたとおりにキャッシュされますが、キャッシュされるSERVFAIL可能性は低いか、キャッシュされる場合は最大で2桁の秒数になります。
このトピック専用のRFCがあります：RFC 2308-Negative Caching of DNS Queries（DNS NCACHE）。
読むべき関連セクションは5-否定回答のキャッシュです。
通常の回答と同様に、否定的な回答には有効期間（TTL）があります。このTTLを適用できる回答セクションにはレコードがないため、TTLは別の方法で伝送する必要があります。これは、応答の権限セクションにゾーンからのSOAレコードを含めることによって行われます。権限のあるサーバーがこのレコードを作成すると、そのTTLはSOA.MINIMUMフィールドとSOAのTTLの最小値から取得されます。このTTLは、通常のキャッシュされた回答と同様の方法で減少し、ゼロ（0）に達すると、キャッシュされた否定的な回答が再び使用されてはならないことを示します。
まずSOA.MINIMUM、RFCで説明されているSOA TTLを識別します。TTLは、レコードタイプの前の数字IN（900以下の例では秒）です。最小値はレコードの最後のフィールドです（86400以下の例では秒）。
$ dig serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> serverfault.com soa @ns-1135.awsdns-13.org +noall +answer +multiline
;; global options: +cmd
serverfault.com. 900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. (
1 ; serial
7200 ; refresh (2 hours)
900 ; retry (15 minutes)
1209600 ; expire (2 weeks)
86400 ; minimum (1 day)
)
次に、いくつかの例を見てみましょう。serverfault.comゾーンは、異なるように構成された2つの異なるプロバイダーからの信頼できるサーバーを備えているため、例証です。
serverfault.comゾーンの信頼できるネームサーバーを見つけましょう：
$ host -t ns serverfault.com
serverfault.com name server ns-860.awsdns-43.net.
serverfault.com name server ns-1135.awsdns-13.org.
serverfault.com name server ns-cloud-c1.googledomains.com.
serverfault.com name server ns-cloud-c2.googledomains.com.
次に、awsネームサーバーを使用してSOAレコードを確認します。
$ dig serverfault.com soa @ns-1135.awsdns-13.org | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com. 900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
これから、SOAレコードのTTLは900秒であり、負のTTL値は86400秒であることがわかります。のSOA TTL値900は低いため、この値が使用されることが予想されます。
存在しないドメインの権限のあるサーバーを照会すると、応答なしで、権威セクションにSOAレコードがある応答を取得する必要があります。
$ dig nxdomain.serverfault.com @ns-1135.awsdns-13.org
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-1135.awsdns-13.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51948
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nxdomain.serverfault.com. IN A
;; AUTHORITY SECTION:
serverfault.com. 900 IN SOA ns-1135.awsdns-13.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
;; Query time: 125 msec
;; SERVER: 205.251.196.111#53(205.251.196.111)
;; WHEN: Tue Aug 20 15:49:47 NZST 2019
;; MSG SIZE rcvd: 135
再帰（キャッシング）リゾルバーがこの回答を受け取ると、SOAレコードを解析し、AUTHORITY SECTIONこのレコードのTTLを使用して、否定結果をキャッシュする900時間（この場合は秒）を決定します。
次に、Googleネームサーバーで同じ手順を実行します。
$ dig serverfault.com soa @ns-cloud-c2.googledomains.com | grep 'ANSWER SECTION' -A 1
;; ANSWER SECTION:
serverfault.com. 21600 IN SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
Googleネームサーバーは、SOA TTL値と負のTTL値の両方で異なる値を持っていることがわかります。この場合、負のTTLはの300SOA TTLよりも低くなります21600。したがって、GoogleサーバーはAUTHORITY SECTION、NXDOMAIN応答を返すときにSOAレコードの低い値を使用する必要があります。
$ dig nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
; <<>> DiG 9.11.3-1ubuntu1.8-Ubuntu <<>> nxdomain.serverfault.com @ns-cloud-c2.googledomains.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25920
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;nxdomain.serverfault.com. IN A
;; AUTHORITY SECTION:
serverfault.com. 300 IN SOA ns-cloud-c1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300
;; Query time: 130 msec
;; SERVER: 216.239.34.108#53(216.239.34.108)
;; WHEN: Tue Aug 20 16:05:24 NZST 2019
;; MSG SIZE rcvd: 143
予想どおり、NXDOMAIN応答のSOAレコードのTTL は300秒です。
上記の例は、同じクエリに対して異なる回答を取得することがいかに簡単かを示しています。個々のキャッシングリゾルバが最終的に使用する答えは、権限のあるnamserverが照会されたものまでです。
私のテストでは、いくつかの再帰（キャッシング）リゾルバーがAUTHORITY SECTION、後続のリクエストに対してTTLをデクリメントするSOAレコードを返しませんが、他のリゾルバーは返すことを観察しました。
たとえば、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
注：この回答は、回答の動作に対応していNXDOMAINます。
用語集：