Lルートサーバーの実際の効果はどのようなものか興味があります本日DURZを出版そうなるでしょう。nanogメーリングリストでは、誰かが言ったDNSSECを使用していない場合でも、ルートネームサーバーが署名ゾーンを公開することによるシステムへの影響を評価することが重要です。一方、RIPEがKルートサーバーの変更について公開した情報によると、リゾルバがDNSSECを使用していない場合は問題なし誰かこれを解明してくれませんか? DNSSEC は複雑に絡み合った問題のようです。
リゾルバで DNSSEC を有効にしていない場合、ルート サーバーに今後加えられる変更について心配することはありますか?
答え1
あなた5月何かが表示されますが、ある程度は実行している DNS ソフトウェアによって異なります。
特に、BIND は、DODNSSEC レコードを具体的に要求していない場合や DNSSEC 検証を実行していない場合でも、アップストリーム クエリに「DNSSEC OK」(別名 ) ビットを設定します。
このような状況では、ルートサーバーは追加のDNSSECレコードを送り返すことがあります。5月万が一、ネットワーク機器が壊れていたり、パス上のファイアウォールの設定が間違っていたりすると、問題が発生する可能性があります。
これらの問題は主にパケットサイズに関係しています。キットによっては、バグのあるファームウェアやベンダーの誤った推奨設定により、長さが512バイトを超えるDNS UDPパケットを受信できないものがあります。RFC 5625詳細については、 を参照してください。ただし、この RFC で報告している DNSSEC 関連の問題のほとんどは、コンシューマー クラスの機器に関係しており、通常とは異なる構成でのみ発生することに注意してください。
キットが大きな UDP パケットで問題を抱えている場合は、フォールバックとして TCP を使用することに注意してください。ただし、一部の (誤った) セキュリティ担当者はファイアウォールを設定して TCP 経由のアウトバウンド DNS を無効にしているため、フォールバックが機能しなくなります。これDNS over TCP の詳細については、IETF ドラフトを参照してください。
ちなみに、ネットワークの設定にDNSの不具合がないかテストするには、素晴らしい ネットアリザーカリフォルニア大学バークレー校の ICSI の Web サイト。
しかし、はっきり言ってほとんどのDNS専門家はないDNSSEC の導入により重大な問題が発生すると予想されます。いくつかの TLD (.org や .se を含む) はすでに署名されており、これによってインターネットが崩壊することはありませんでした。
DURZ は、DNSSEC が必然的に生成する大規模な応答を段階的に導入し、夏にルートゾーン全体が DNSSEC に移行する前に、ネットワークの問題を抱える稀なサイトで問題を解決できるようにする意図的な試みです。
答え2
命令型プログラミング言語を好む人のために、疑似コードで何が問題になる可能性があるかを説明します :-)
-- 擬似コード（構文はAdaに似ている）で、
-- ルートが署名され、応答が次のようになる場合のDNSリゾルバ
-- より大きいです。
-- 背景情報:
-- https://www.dns-oarc.net/oarc/services/replysizetest
-- RFC 5625
-- SSAC レポート #35 http://www.icann.org/committees/security/sac035.pdf
-- ステファン・ボルツマイヤー
-- 使用される変数:
-- EDNS0: ブール値、リゾルバがEDNS0リクエストを送信するかどうかを示します
-- EDNS0_Size: 正の整数、EDNS0 によってアドバタイズされるバッファ サイズ
-- DO_DNSSEC: ブール値、リゾルバによる DNSSEC サポートを示す DO フラグ
-- Min_Response_Size: 整数、最小値（削除後）
-- 権威あるDNSサーバから送信されるDNS応答の不要なRRサイズ
-- サーバー
-- Clean_path_for_fragments: ブール値、UDPフラグメントを示す
-- 権威ネームサーバからリゾルバまで移動できる
-- Clean_Path_For_EDNS0: ブール値、EDNS0応答を示す
-- （512バイトを超える場合もあります）は、
-- リゾルバへの権威あるネームサーバ
-- Can_TCP: ブール値、リゾルバがTCP経由で問い合わせることができるかどうかを示す
-- （クリーンなTCPパッチと権威あるネームサーバを意味します）
-- TCP を受け入れる)
-- コードは1回のリクエストに対して複数回実行される可能性があります。
-- リゾルバが最初にUDPで試行し、次に再試行するため、インスタンス
-- TCP を使用。
UDPの場合 -- DNSの最も一般的なトランスポートプロトコル
EDNS0の場合
EDNS0_Size > MTUの場合
-- BIND デフォルト、EDNS0_size = 4096 バイト
DO_DNSSECの場合
-- 検証が設定されていない場合でも、BIND のデフォルト
Min_Response_Size > MTU の場合 -- ルートでは現在のところ当てはまりません
Clean_Path_for_fragmentsの場合
わかりました;
それ以外
-- しばらくするとBINDはno-EDNS0に切り替わり、やり直します
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
Min_Response_Size > 512の場合
-- 断片化は発生しません
Clean_Path_For_EDNS0の場合
OK; -- これはBINDの通常の典型的なケースです
-- 署名されたルートを持つ今日のリゾルバ
それ以外
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
そうでない場合 -- 今日は発生しません。ルートからの応答はすでに 512 を超えています。
わかりました;
終了の場合;
それ以外
-- DNSSECがない場合、応答は短くなりますが、
-- ルートからの応答はすでに 512 を超えています
Min_Response_Size > MTUの場合
-- DNSSECがなければ、あり得ない
Clean_Path_for_fragmentsの場合
わかりました;
それ以外
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
Min_Response_Size > 512の場合
Clean_Path_For_EDNS0の場合
わかりました;
それ以外
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
else -- 今日最も一般的なケース、典型的なunsigned
-- 答えは100〜200バイトです
わかりました;
終了の場合;
終了の場合;
elsif EDNS0_Size >= 512 then -- ただしMTUより小さい
DO_DNSSECの場合
Min_Response_Size > EDNS0_Sizeの場合
-- これは、TCビットが設定されたDNSパケットが到着することを前提としています
-- 安全だが、必ずしも真実ではない
再試行("切り捨て");
Min_Response_Size >= 512の場合
Clean_Path_for_EDNS0の場合
わかりました;
それ以外
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
else -- 今日ではあまり発生しません。ルートからの応答の一部はすでに 512 を超えています。
OK; -- 必ずしもそうとは限りません。一部のミドルボックスは EDNS0 をブロックする場合があります。
-- 応答、サイズが512であっても
Clean_Path_For_EDNS0の場合
わかりました;
それ以外
再試行("応答が受信されなかったのは、EDNS0 が原因である可能性があります");
終了の場合;
それ以外
わかりました;
終了の場合;
終了の場合;
そうでない場合 -- サイズ512のEDNS0
再試行("切り捨て");
それ以外
わかりました;
終了の場合;
終了の場合;
それ以外の場合 -- TCP
Can_TCPの場合
OK; -- しかし、権威あるネームサーバのレイテンシと負荷が高くなります
それ以外
エラー("TCP へのフォールバックに失敗しました"); -- 完全な失敗
終了の場合;
終了の場合;
答え3
セットアップをテストするためのもう1つの解決策は、Netalyzrよりもはるかに簡単だと思います。OARC 応答サイズ テスト。