BIND9：DNSが解決されることがある（！）非常に時間がかかる、またはまったく機能しない
ネットワークのRPi3でBIND 9.9.5-9 + deb8u8-Raspbian DNSサーバーを実行しています。それは-私のホームゾーン以外のすべての場合-フォワーダー "{8.8.8.8; 8.8.4.4; 208.67.222.222; 208.67.220.220;};"で「転送のみ」として構成されています。
a）通常の場合
通常、DNS解決は完全に機能します。結果がキャッシュにない場合でも、結果はフォワードサーバーからフェッチされ、多くの場合100ミリ秒以内にクライアントに返送されます。次に例を示します。
client:~ $ time nslookup faz.net
Server: [my_server]
Address: [my_server]#53
Non-authoritative answer:
Name: faz.net
Address: 40.118.6.229
real 0m0.095s […]
これはtcpdumpでトラフィックがどのように見えるかであり、私が見る限りすべてが完璧であり、DNSSEC検証も同様にうまく機能しているようです。
06:48:21.880240 IP [my_client].59563 > [my_server].domain: 614+ A? faz.net. (25)
06:48:21.881246 IP [my_server].28766 > google-public-dns-a.google.com.domain: 30021+% [1au] A? faz.net. (36)
06:48:21.916031 IP google-public-dns-a.google.com.domain > [my_server].28766: 30021 1/0/1 A 40.118.6.229 (52)
06:48:21.917093 IP [my_server].44792 > google-public-dns-a.google.com.domain: 10551+% [1au] DS? faz.net. (36)
06:48:21.952356 IP google-public-dns-a.google.com.domain > [my_server].44792: 10551 0/6/1 (757)
06:48:21.956635 IP [my_server].domain > [my_client].59563: 614 1/0/0 A 40.118.6.229 (41)
b）問題のあるケース
ただし、結果が表示されるまでに最大14秒かかる場合があります。または、まったく取得しません（Dig @ 8.8.4.4ドメインでは約50ミリ秒以内に適切なアドレスが提供されますが）。ここに1つの例を示します。
client:~ $ time nslookup sueddeutsche.net
Server: [my_server]
Address: [my_server]#53
Non-authoritative answer:
Name: sueddeutsche.net
Address: 213.61.179.40
Name: sueddeutsche.net
Address: 213.61.179.41
real 0m4.994s […]
そして、これはtcpdump経由のトラフィックでこれらの4,9秒間続くものです：
06:48:47.608104 IP [my_client].53592 > [my_server].domain: 51417+ A? sueddeutsche.net. (34)
06:48:47.609158 IP [my_server].1507 > google-public-dns-a.google.com.domain: 56678+% [1au] A? sueddeutsche.net. (45)
06:48:48.809517 IP [my_server].27279 > google-public-dns-b.google.com.domain: 22525+% [1au] A? sueddeutsche.net. (45)
06:48:50.009592 IP [my_server].37926 > resolver2.opendns.com.domain: 41597+% [1au] A? sueddeutsche.net. (45)
06:48:50.081468 IP resolver2.opendns.com.domain > [my_server].37926: 41597 2/0/1 A 213.61.179.41, A 213.61.179.40 (77)
06:48:50.082768 IP [my_server].1301 > resolver2.opendns.com.domain: 24793+% [1au] DS? sueddeutsche.net. (45)
06:48:50.233748 IP resolver2.opendns.com.domain > [my_server].1301: 24793 0/1/1 (121)
06:48:50.235373 IP [my_server].57628 > resolver1.opendns.com.domain: 8635+% [1au] DS? sueddeutsche.net. (45)
06:48:50.282862 IP resolver1.opendns.com.domain > [my_server].57628: 8635 0/1/1 (121)
06:48:50.287796 IP [my_server].32127 > google-public-dns-a.google.com.domain: 924+% [1au] DS? sueddeutsche.net. (45)
06:48:51.487853 IP [my_server].61208 > google-public-dns-b.google.com.domain: 39031+% [1au] DS? sueddeutsche.net. (45)
06:48:51.547262 IP google-public-dns-b.google.com.domain > [my_server].61208: 39031 0/6/1 (766)
06:48:51.551509 IP [my_server].52786 > resolver2.opendns.com.domain: 28853+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.589595 IP resolver2.opendns.com.domain > [my_server].52786: 28853 NXDomain 0/1/1 (125)
06:48:51.592942 IP [my_server].30477 > resolver2.opendns.com.domain: 17693+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:51.790903 IP resolver2.opendns.com.domain > [my_server].30477: 17693 NXDomain 0/1/1 (125)
06:48:51.792342 IP [my_server].6503 > resolver1.opendns.com.domain: 17946+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.005244 IP resolver1.opendns.com.domain > [my_server].6503: 17946 NXDomain 0/1/1 (125)
06:48:52.006662 IP [my_server].52356 > google-public-dns-b.google.com.domain: 39821+% [1au] DS? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.334093 IP google-public-dns-b.google.com.domain > [my_server].52356: 39821 NXDomain 0/6/1 (748)
06:48:52.342161 IP [my_server].56473 > resolver1.opendns.com.domain: 17279+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.382211 IP resolver1.opendns.com.domain > [my_server].56473: 17279 NXDomain 0/1/1 (125)
06:48:52.383674 IP [my_server].52741 > google-public-dns-b.google.com.domain: 65018+% [1au] Type32769? sueddeutsche.net.dlv.isc.org. (57)
06:48:52.424757 IP google-public-dns-b.google.com.domain > [my_server].52741: 65018 NXDomain$ 0/6/1 (748)
06:48:52.430544 IP [my_server].domain > [my_client].53592: 51417 2/0/0 A 213.61.179.40, A 213.61.179.41 (66)
今私が理解できることから、06：48：50.081468にmy_serverはresolver2.opendns.comから適切な応答を得たようですが、Googleは何も配信しませんでした。次に、my_serverはresolver2.opendns.comが応答したDNSSEC検証を要求しました。 my_serverが結果をmy_clientに返す時点ではないのでしょうか。なぜこれを行わないのですか？
2番目のケースは、dasoertliche.deで、問題なく機能するドメインです。
23:39:01.569234 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:01.570413 IP [my_server].60368 > resolver2.opendns.com.domain: 39796+% [1au] A? dasoertliche.de. (44)
23:39:01.617721 IP resolver2.opendns.com.domain > [my_server].60368: 39796 1/0/1 A 82.98.79.52 (60)
23:39:01.618712 IP [my_server].41112 > resolver2.opendns.com.domain: 47487+% [1au] DS? dasoertliche.de. (44)
23:39:01.667144 IP resolver2.opendns.com.domain > [my_server].41112: 47487 0/1/1 (100)
23:39:01.668616 IP [my_server].24077 > resolver1.opendns.com.domain: 13310+% [1au] DS? dasoertliche.de. (44)
23:39:01.854327 IP resolver1.opendns.com.domain > [my_server].24077: 13310 0/1/1 (100)
23:39:01.856006 IP [my_server].38412 > google-public-dns-a.google.com.domain: 56597+% [1au] DS? dasoertliche.de. (44)
23:39:03.056263 IP [my_server].35182 > google-public-dns-b.google.com.domain: 45370+% [1au] DS? dasoertliche.de. (44)
23:39:04.256333 IP [my_server].47744 > google-public-dns-a.google.com.domain: 50222+% [1au] DS? dasoertliche.de. (44)
23:39:04.305620 IP google-public-dns-a.google.com.domain > [my_server].47744: 50222| 0/0/1 (44)
23:39:04.306296 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [S], seq 3961861791, win 29200, options [mss 1460,sackOK,TS val 11766745 ecr 0,nop,wscale 7], length 0
23:39:04.345835 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [S.], seq 2448404480, ack 3961861792, win 42408, options [mss 1380,sackOK,TS val 4100658423 ecr 11766745,nop,wscale 7], length 0
23:39:04.345899 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 0
23:39:04.346167 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:47, ack 1, win 229, options [nop,nop,TS val 11766749 ecr 4100658423], length 4662876+% [1au] DS? dasoertliche.de. (44)
23:39:04.385803 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [.], ack 47, win 332, options [nop,nop,TS val 4100658463 ecr 11766749], length 0
23:39:04.394945 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [P.], seq 1:752, ack 47, win 332, options [nop,nop,TS val 4100658472 ecr 11766749], length 75162876 0/6/1 (749)
23:39:04.394975 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 752, win 240, options [nop,nop,TS val 11766753 ecr 4100658472], length 0
23:39:04.398143 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [F.], seq 47, ack 752, win 240, options [nop,nop,TS val 11766754 ecr 4100658472], length 0
23:39:04.401876 IP [my_server].37878 > resolver2.opendns.com.domain: 50849+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:04.437774 IP google-public-dns-a.google.com.domain > [my_server].45040: Flags [F.], seq 752, ack 48, win 332, options [nop,nop,TS val 4100658515 ecr 11766754], length 0
23:39:04.437858 IP [my_server].45040 > google-public-dns-a.google.com.domain: Flags [.], ack 753, win 240, options [nop,nop,TS val 11766758 ecr 4100658515], length 0
23:39:04.456088 IP resolver2.opendns.com.domain > [my_server].37878: 50849 NXDomain 0/1/1 (124)
23:39:04.457411 IP [my_server].38743 > resolver2.opendns.com.domain: 45844+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.658497 IP resolver2.opendns.com.domain > [my_server].38743: 45844 NXDomain 0/1/1 (124)
23:39:04.659855 IP [my_server].39296 > resolver1.opendns.com.domain: 17204+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.708134 IP resolver1.opendns.com.domain > [my_server].39296: 17204 NXDomain 0/1/1 (124)
23:39:04.713195 IP [my_server].55899 > google-public-dns-a.google.com.domain: 5854+% [1au] DS? dasoertliche.de.dlv.isc.org. (56)
23:39:04.780837 IP google-public-dns-a.google.com.domain > [my_server].55899: 5854 NXDomain 0/6/1 (736)
23:39:04.786940 IP [my_server].27908 > resolver1.opendns.com.domain: 4148+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:05.267688 IP resolver1.opendns.com.domain > [my_server].27908: 4148 NXDomain 0/1/1 (124)
23:39:05.269026 IP [my_server].38523 > google-public-dns-a.google.com.domain: 60609+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.469277 IP [my_server].58501 > google-public-dns-b.google.com.domain: 5485+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:06.572296 IP [my_client].52174 > [my_server].domain: 57873+ A? dasoertliche.de. (33)
23:39:07.669762 IP [my_server].52520 > google-public-dns-a.google.com.domain: 43149+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.706440 IP google-public-dns-a.google.com.domain > [my_server].52520: 43149| 0/0/1 (56)
23:39:07.706903 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [S], seq 4227748459, win 29200, options [mss 1460,sackOK,TS val 11767085 ecr 0,nop,wscale 7], length 0
23:39:07.747595 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [S.], seq 719567413, ack 4227748460, win 42408, options [mss 1380,sackOK,TS val 3894129283 ecr 11767085,nop,wscale 7], length 0
23:39:07.747657 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 0
23:39:07.747982 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [P.], seq 1:59, ack 1, win 229, options [nop,nop,TS val 11767089 ecr 3894129283], length 5821405+% [1au] Type32769? dasoertliche.de.dlv.isc.org. (56)
23:39:07.788998 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [.], ack 59, win 332, options [nop,nop,TS val 3894129324 ecr 11767089], length 0
23:39:07.789344 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [P.], seq 1:739, ack 59, win 332, options [nop,nop,TS val 3894129325 ecr 11767089], length 73821405 NXDomain$ 0/6/1 (736)
23:39:07.789372 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.790414 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [F.], seq 59, ack 739, win 240, options [nop,nop,TS val 11767093 ecr 3894129325], length 0
23:39:07.796565 IP [my_server].domain > [my_client].52174: 57873 1/0/0 A 82.98.79.52 (49)
23:39:07.831137 IP google-public-dns-a.google.com.domain > [my_server].59047: Flags [F.], seq 739, ack 60, win 332, options [nop,nop,TS val 3894129366 ecr 11767093], length 0
23:39:07.831221 IP [my_server].59047 > google-public-dns-a.google.com.domain: Flags [.], ack 740, win 240, options [nop,nop,TS val 11767097 ecr 3894129366], length 0
繰り返しになりますが、23：39：01.617721にmy_serverはresolver2.opendns.comから適切な回答を受け取りますが、理由のため、my_serverとgoogle dnsサーバー間の通信の洪水全体を理解できません。
ここで何が起こっているのか、そしてどうすれば状況を改善できるのか？
c）更新
リクエストに従って、ここにfree...の出力があります。
[my_server]:~ $ free
total used free shared buffers cached
Mem: 996448 331696 664752 15752 29808 180668
-/+ buffers/cache: 121220 875228
Swap: 0 0 0
...およびvmstat：
[my_server]:~ $ vmstat
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 664752 29808 180676 0 0 0 1 20 23 0 0 100 0 0
d）更新2：
私の/var/log/syslogには、dasoertliche.deの解決問題（2番目の問題のケース）に関するエントリがあります。それは次のとおりです。
Dec 13 23:39:01 raspi-server named[642]: validating @0x713c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.220.220#53
Dec 13 23:39:01 raspi-server named[642]: validating @0x712c0030: de SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:01 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: success resolving 'dasoertliche.de/DS' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets
Dec 13 23:39:04 raspi-server named[642]: validating @0x711c2040: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: validating @0x73401378: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.220.220#53
Dec 13 23:39:04 raspi-server named[642]: validating @0x713c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:04 raspi-server named[642]: error (no valid RRSIG) resolving 'dasoertliche.de.dlv.isc.org/DS/IN': 208.67.222.222#53
Dec 13 23:39:04 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.220.220#53
Dec 13 23:39:05 raspi-server named[642]: validating @0x712c0030: dlv.isc.org SOA: got insecure response; parent indicates it should be secure
Dec 13 23:39:05 raspi-server named[642]: error (insecurity proof failed) resolving 'dasoertliche.de.dlv.isc.org/DLV/IN': 208.67.222.222#53
Dec 13 23:39:07 raspi-server named[642]: success resolving 'dasoertliche.de.dlv.isc.org/DLV' (in '.'?) after reducing the advertised EDNS UDP packet size to 512 octets
今では、それはすべてより意味のあるものになり始めていると私は信じています。私が想定したこと：OpenDNSはDNSSECをサポートしていないようです。そのため、my_serverがOpenDNSから最初の（正しい）解決を取得し、DNSSECを要求すると、適切なDNSSEC応答がなかったため、応答が安全でないと考えられたはずです。したがって、23：39：01.856006以降、Google DNSから確認を取得しようとしました。しかし、syslogおよびtcpdumpの次の行は、正確にはどういう意味ですか？ googleが応答しなかった秒があるのはなぜですか？応答とgoogleとmy_serverの間の次の情報交換はどういう意味ですか？
さらに調査した結果、問題は次のように思われます。
初期設定には、[〜＃〜] dnssec [〜＃〜]対応の両方のフォワーダー（GoogleDNS 8.8.8.8、8.8.4.4）と一部ではありませんでした（OpenDNS 208.67.222.222、208.67.220.220）。次の構成に従って、DNSSECを完全に有効にしてBIND9を実行しました。
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
a）リクエスト（A？）がGoogleDNSに転送されたときサーバー、my_serverは応答（A）を受け取り、DNSSECクエリ（DS？）を送信し、適切な応答を受け取りました。解決が完了し、署名が確認され、すべてがチャームのように機能し、ケースがクローズしました（上記を参照、通常のケース）。
b）リクエスト（A？）がOpenDNSに転送されたときサーバー、my_serverは応答（A）を受け取り、DNSSECクエリ（DS？）を送信しましたが、OpenDNSはDNSSECをサポートしていないため、正しく応答できませんでした。そのため、BIND9はsyslogにエラーをスローし、それをgot insecure responseで、DNSSEC検証を別の場所で取得しようとしました（上記を参照問題のあるケース）。
そのとき何が起こったのかはまだ完全にはわかりませんが、明らかにしゃっくりが始まったのはそのときです。現在、GoogleDNSサーバーが、対応するA？クエリを最初に提供せずにDS？-answersを提供することを望まなかったかどうかはわかりません。しかし、問題のある両方のケース（sueddeutsche.net、dasoertliche.de）では、エントリも適切に署名されていなかったため、DNSSECが正しい検証を生成しなかったようです。そこでDNSSECルックアサイド検証（DLV）が開始されました（Type32769?）そして再びそれはすべて南に行きました。なぜだかわかりません。
c）解決策：結局、私は次のことを実行しましたが、まだ問題は発生していません（問題が解決したようです）。
まず、フォワーダーを
forwarders { 8.8.8.8; 8.8.4.4; };
dNSSECサポートの混在はなくなりました。次に、コメントアウトしました
//dnssec-lookaside auto;
多数のtcpdumpを調べた後、解決が遅い場合は常に、遅延がGoogleDNSが応答を返すのに時間がかかる（非常にまれに発生する）か、または定期的にDLV中に発生するように見えるためです。とにかくDLVは現在段階的に廃止されているため、エントリは2017年に利用できなくなります
https://www.isc.org/blogs/dlv/
これはセキュリティの観点からは許容できると思います。
もう1つの解決策は、GoogleDNSサーバーを破棄して、フォワーダーとしてOpenDNSのみを使用することです。しかし、OpenDNSはDNSSECをサポートしていないため、上記のすべてのdnssec-entriesをコメントアウトしてDNSSECを完全に無効にする必要があります。これにより、私のDNSクエリが攻撃にさらされたままになるため、dnscrypt（Rui F Ribeiroによる言及）などのセキュリティの代替レイヤーを追加する必要があります。これは価値のあるプロジェクトのように見えますが（dnsトラフィックを完全に暗号化するため、変更されないだけでなく、攻撃者が読み取れないようにするため）、現在の時間予算を少し超えています。
上記の説明が理にかなっているなら、口にしたいDNS専門家はいますか？