メインコンテンツまでスキップ

6. Zone Integrity (ゾーンの整合性)

転送されたゾーンデータの整合性を確保することは, DNSインフラストラクチャのセキュリティと信頼性を維持するために重要です。このセクションでは, AXFRの整合性に関する考慮事項について説明し, ベストプラクティスを推奨します。

整合性の脅威​

ゾーン転送はいくつかの整合性の脅威にさらされています:

  1. 中間者攻撃: AXFRクライアントとサーバーの間に位置する攻撃者が, 転送中のゾーンデータを傍受および変更する可能性があります。

  2. なりすまし攻撃: 攻撃者がAXFRサーバーになりすまし, AXFRクライアントに偽造されたゾーンデータを送信する可能性があります。

  3. リプレイ攻撃: 攻撃者が正当なゾーン転送をキャプチャし, 後でそれを再生し, クライアントが古いゾーンデータに戻る可能性があります。

  4. 承認されていない変更: 適切な認証と整合性チェックがなければ, 攻撃者がゾーン転送中にリソースレコードを注入, 削除, または変更する可能性があります。

整合性保護メカニズム​

これらの脅威から保護するために, AXFR実装は以下の整合性保護メカニズムの1つ以上を採用すべきです:

TSIG (Transaction Signature, トランザクション署名)​

TSIG [RFC2845] は, 共有秘密鍵とHMACアルゴリズムを使用してメッセージレベルの認証と整合性保護を提供します。

TSIGがAXFRでどのように機能するか:

  1. AXFRクライアントは, 事前共有鍵で署名されたクエリメッセージにTSIG RRを含めます。

  2. AXFRサーバーは, クエリのTSIG署名を検証します。検証が失敗した場合, サーバーはRCODE NOTAUTHまたはREFUSEDで応答します。

  3. クエリが有効な場合, AXFRサーバーは応答メッセージにTSIG RRを含めます:

    • 最初の応答メッセージにはTSIG RRを含めなければなりません。
    • 効率のために中間メッセージはTSIGを省略できますが, シーケンスは最初と最後のメッセージのTSIGによって保護されます。
    • 最後の応答メッセージにはTSIG RRを含めなければなりません。

  4. AXFRクライアントは, 応答メッセージのTSIG署名を検証します。検証が失敗した場合, クライアントはゾーン転送全体を破棄しなければなりません。

利点: TSIGは強力な整合性保護と相互認証を提供します。DNS実装で広くサポートされています。

制限: 事前共有鍵が必要であり, それらは安全に配布および管理されなければなりません。

SIG(0) (Signature, 署名)​

SIG(0) [RFC2931] は, DNSSEC形式の署名を使用して公開鍵ベースのメッセージ認証を提供します。

SIG(0) がAXFRでどのように機能するか:

  1. AXFRクライアントは, その秘密鍵でクエリメッセージに署名し, クエリに結果として生じるSIG(0) RRを含めます。

  2. AXFRサーバーは, クライアントの公開鍵 (DNSを介して取得されるか, ローカルトラストアンカーから) を使用して署名を検証します。

  3. AXFRサーバーは, 自身の秘密鍵で応答メッセージに署名することができ, クライアントが応答の真正性を検証できるようにします。

利点: 事前共有秘密の必要性を排除します。鍵配布が困難なシナリオに適しています。

制限: TSIGよりも実装と構成が複雑です。公開鍵基盤に依存します。

DNSSEC​

DNSSEC署名ゾーンの場合, AXFRクライアントは, DNSSEC署名 (RRSIGレコード) を使用して転送されたゾーンデータの整合性を検証できます。

DNSSECがAXFRを保護する方法:

  1. AXFRサーバーは, すべてのRRSIG, DNSKEY, およびNSEC/NSEC3レコードを含むゾーンを転送します。

  2. AXFRクライアントは, ゾーン内のDNSKEYレコードを使用して, 転送されたRRsetのRRSIG署名を検証します。

  3. DNSSEC検証が失敗した場合, クライアントはゾーンデータを提供すべきではありません。

利点: ゾーンデータに対するエンドツーエンドの整合性保護を提供し, 転送中だけでなく, データがリゾルバに提供されるときにも保護します。

制限: ゾーンがDNSSEC署名されている必要があります。AXFRプロトコル自体を保護しません (たとえば, 承認されていないクライアントに対して)。

ネットワークレベルのセキュリティ​

アプリケーションレベルのセキュリティメカニズムに加えて, AXFR転送はネットワークレベルのセキュリティを使用して保護されることがあります:

  1. TLS/SSL: TLSまたはSSLを使用してTCP接続を暗号化すると, ゾーン転送の機密性と整合性保護が提供されます。(注: ゾーン転送用のDNS-over-TLSは, 本書執筆時点では標準化されていません。)

  2. IPsec: IPsec保護された接続を介して実施されるゾーン転送は, IPsecによって提供される機密性, 整合性, および認証の恩恵を受けます。

  3. VPNまたはプライベートネットワーク: プライベートネットワーク (VPNなど) を介してゾーン転送を実施すると, 追加のセキュリティ層を提供できます。

推奨事項​

  1. TSIGまたはSIG(0) を使用する: AXFRサーバーとクライアントは, ゾーン転送を保護するためにTSIGまたはSIG(0) をサポートおよび使用すべきです。TSIGは最も一般的に展開されているソリューションであり, ほとんどの展開に推奨されます。

  2. 転送されたデータを検証する: AXFRクライアントは, ローカルゾーンデータベースにコミットする前に, 受信したゾーンデータの整合性を検証すべきです。DNSSEC署名ゾーンの場合, この検証にはDNSSEC署名の検証が含まれます。

  3. 安全な鍵管理: TSIGベースの展開の場合, オペレーターは, 暗号的に強力な乱数生成器を使用して共有鍵が生成されること, および鍵が安全に保管および配布されることを保証しなければなりません。

  4. 異常を監視する: オペレーターは, ゾーンサイズの予期しない変更, 異常な転送頻度, または失敗した整合性チェックなど, ゾーン転送の異常を監視すべきです。

  5. 強力なアルゴリズムを使用する: TSIGを使用する場合, オペレーターは, HMAC-MD5のような弱いアルゴリズムではなく, HMAC-SHA256やHMAC-SHA512などの強力なHMACアルゴリズムを使用すべきです。アルゴリズムの選択に関するガイダンスについては, [RFC4635] および [RFC5702] を参照してください。

整合性失敗の処理​

AXFRクライアントが整合性失敗 (たとえば, TSIG検証失敗, DNSSEC検証失敗) を検出した場合, 次のことを行わなければなりません:

  1. 失敗したゾーン転送から受信したすべてのデータを破棄する。
  2. 監査とトラブルシューティングの目的で失敗を記録する。
  3. 必要に応じて, 適切な遅延 (バックオフ付き) 後にゾーン転送を再試行する。

AXFRクライアントは, 部分的に受信された, または整合性に失敗したゾーンデータを権威ゾーンデータベースにコミットしてはなりません。そうすると, DNSクライアントに不正または悪意のあるデータを提供する可能性があります。

に最終更新