BIND9: DNS チェックが時々(!)長くかかったり、まったく動作しないことがあります。

Question

さらなる調査結果の問題は次のとおりです。

初期設定は2つのリピータで構成されます。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？）が次に転送されるたびにGoogle DNSサーバーmy_serverは応答（A）を受け取り、DNSSECクエリ（DS？）を送信して正解を取得します。解決が完了し、署名が確認され、すべてが順調に進み、イベントが終了します（上記を参照してください。正常な状況）。

雨）リクエスト（A？）が次に転送されるたびにオープンDNSサーバーmy_serverは応答（A）を受け取り、DNSSECクエリ（DS？）を送信しましたが、OpenDNSはDNSSECをサポートしていないため、正しく応答できませんでした。したがって、BIND9はsyslogこれを指摘しgot insecure response、他の場所でDNSSEC検証を受けようとするとエラーが発生します（上記参照、問題のあるケース）。

私はまだ何が起こったのか完全には理解していませんが、しゃっくりはその時から始まったようです。今GoogleDNSサーバーは最初に対応するA？クエリを提供せずにDSに回答を提供するのが好きではないかと思います。ただし、問題がある2つのケース（sueddeutsche.net、dasoertliche.de）でも、エントリが正しく署名されていないように見えるため、DNSSECは正しい検証を生成できません。そのため、DNSSEC代替検証（DLV）が開始されましたが、（Type32769?）すべてが再び中断されました。なぜか分からない。

c) 解決:結局のところ、私は次のことをしましたが、まだ何も起こりませんでした（それで問題が解決したようです）。

まず、リピータを次に切り替えました。

forwarders         { 8.8.8.8; 8.8.4.4; };

これにより、DNSSEC サポートが混乱しなくなります。 2番目にコメントしました。

//dnssec-lookaside   auto;

多くのtcpdumpを調べた後、解析が遅くなるたびにGoogleDNSが応答を返すのに時間がかかり（ほとんど発生しない）、DLV中にかなり頻繁に発生し、遅延が発生するようです。 DLVは現在段階的に廃止されているため、2017年にはもはやアイテムを使用できません。

https://www.isc.org/blogs/dlv/

私はこれがセキュリティの観点から許容できると思います。

もう1つの解決策は、GoogleDNSサーバーを廃棄し、OpenDNSをフォワーダとして使用することです。ただし、上記のすべてのdnssecエントリをコメントアウトしてDNSSECを完全に無効にする必要がありました。 OpenDNSがそれをサポートしていないからです。これにより、私のDNSクエリが脆弱になり、たとえばdnscryptRui F Ribeiroが述べたように、代替セキュリティ層を追加する必要があります。これは貴重なプロジェクトのように見えますが（DNSトラフィックを完全に暗号化してそのままにするだけでなく、攻撃者が読むことができないため）、現在の時間予算からわずかに外れました。

上記の説明が正しい場合は、喜んで参加するDNSの専門家がありますか？

Answer 1