DNSゾーン転送

DNS ゾーン転送は、DNS クエリ タイプAXFRの誘導とも呼ばれ、 DNS トランザクションの一種です。これは、管理者がDNS サーバーセット間で DNS データベースを複製するために利用できる多くのメカニズムの 1 つです。

ゾーン転送は、転送に伝送制御プロトコル（TCP）を使用し、^{[1] [2]}クライアント・サーバートランザクションの形式をとります。ゾーン転送を要求するクライアントは、プライマリサーバーからデータを要求するセカンダリサーバーの場合もあります。^[3]複製されるデータベースの部分がゾーンです。

ゾーン転送は、プリアンブルとそれに続く実際のデータ転送で構成されます。プリアンブルは、 「ゾーンの頂点」、つまり「ゾーン」の最上位にある DNS 名前空間のノードのStart of Authority (SOA) リソース レコードの検索で構成されます。この SOA リソース レコードのフィールド、特に「シリアル番号」によって、実際のデータ転送を実行する必要があるかどうかが決まります。クライアントは、SOA リソース レコードのシリアル番号と、クライアントが保持しているそのリソース レコードの最後のコピーのシリアル番号を比較します。転送されるレコードのシリアル番号の方が大きい場合、ゾーン内のデータは (何らかの方法で) 「変更」されたとみなされ、セカンダリは実際のゾーン データ転送を要求します。シリアル番号が同一である場合、ゾーン内のデータは「変更」されていないとみなされ、クライアントは、既に保持しているデータベースのコピー (ある場合) を引き続き使用できます。

実際のデータ転送プロセスは、クライアントが TCP 接続を介して特別なクエリ タイプ AXFR (値 252) のクエリ (オペコード 0) をサーバーに送信することで開始されます。DNS は技術的にはユーザー データグラム プロトコル(UDP) 上の AXFR をサポートしていますが、パケットの損失や偽装のリスクがあるため、受け入れられないと考えられています。^{[2] [1]}サーバーは、"ゾーン" 内のすべてのドメイン名のすべてのリソース レコードを含む一連の応答メッセージで応答します。最初の応答は、ゾーン アペックスの SOA リソース レコードで構成されます。その他のデータは、特定の順序なしで続きます。データの終了は、サーバーがゾーン アペックスの SOA リソース レコードを含む応答を繰り返すことで示されます。

一部のゾーン転送クライアントは、システムの通常の DNS クエリ解決メカニズムを使用して、プリアンブルの SOA ルックアップを実行します。これらのクライアントは、実際のデータ転送を実行する必要があると判断するまで、サーバーへの TCP 接続を開きません。ただし、TCP は通常の DNS トランザクションだけでなくゾーン転送にも使用できるため、他のゾーン転送クライアントは、実際のデータ転送を実行するときに (実行できる)、同じ TCP 接続で SOA ルックアップ プリアンブルを実行します。これらのクライアントは、プリアンブルを実行する前に、サーバーへの TCP 接続を開きます。

上記は完全なゾーン転送について説明しています。増分ゾーン転送は、次の点で完全なゾーン転送と異なります。

• クライアントは、AXFR QTYPE の代わりに特殊な QTYPE IXFR (値 251) を使用します。
• クライアントは、現在持っているゾーン アペックスの SOA リソース レコード (存在する場合) を IXFR メッセージで送信し、サーバーに、どのバージョンの「ゾーン」が最新であると認識されているかを知らせます。
• サーバーは、ゾーンの完全なデータで通常の AXFR 方式で応答する場合もありますが、代わりに「増分」データ転送で応答する場合もあります。後者は、クライアントがサーバーに報告したゾーンのバージョンと、サーバーで現在使用されているゾーンのバージョン間のゾーン データの変更のリストを、ゾーンのシリアル番号順に構成します。変更は、削除されたリソース レコードのリストと、挿入されたリソース レコードのリストの 2 つで構成されます (リソース レコードの変更は、削除とそれに続く挿入として表されます)。

ゾーン転送は完全にクライアントによって開始されます。ゾーン データに変更があった場合、サーバーはクライアントに NOTIFY メッセージ (通知済み) を送信できますが、ゾーン転送のスケジュールは完全にクライアントによって制御されます。クライアントは、データベースが空のときに最初にゾーン転送をスケジュールし、その後はゾーン アペックスの SOA リソース レコードの "refresh"、"retry"、"expire" フィールドの値によって制御されるパターンで、定期的にゾーン転送をスケジュールします。

ゾーン転送は標準化されており、RFC 1034 および RFC 5936 (RFC 1995 で説明されている増分ゾーン転送) で可能なデータベース レプリケーション メカニズムの 1 つとして説明されていますが、ゾーン転送はこれらのデータベース レプリケーション メカニズムの中で最も制限が厳しいものです。ゾーン転送は、「ワイヤ形式」のリソース レコード、つまりDNS プロトコルを使用して転送されるリソース レコードに基づいて動作します。ただし、ワイヤ形式のリソース レコードのスキーマは、 DNS サーバー自体のバックエンドで使用されるデータベース スキーマと同じではない場合があります。

ゾーン転送のプリアンブル部分は、ゾーンのデータが変更されたかどうか、つまり実際のデータ転送が必要かどうかを判断するために、シリアル番号だけに依存します。一部の DNS サーバー パッケージでは、SOA リソース レコードのシリアル番号は管理者によって手動で管理されています。データベースを編集するたびに、変更するレコードとゾーンのシリアル番号の 2 つの変更が行われます。このプロセスには正確さが求められます。管理者がシリアル番号の変更を忘れたり、誤って変更したり (減らしたり) する場合があります。RFC 1912 (セクション 2.2 SOA レコード) では、番号として値 YYYYMMDDnn (YYYY= 年、MM= 月、DD= 日、nn= リビジョン番号) を使用することが推奨されています。これは、4294 年までオーバーフローしません。

一部の DNS サーバー パッケージでは、ディスク上のデータベース ファイルの最終変更タイムスタンプからシリアル番号を自動的に作成することで、この問題を克服しています。たとえば、 djbdns がこれに該当します。オペレーティング システムは、管理者がデータベース ファイルを編集するたびに最終変更タイムスタンプが更新されるようにし、シリアル番号を効果的に自動的に更新します。これにより、管理者は変更ごとに 2 回の編集 (2 つの異なる場所で) を行う必要がなくなります。

さらに、シリアル番号チェック (およびゾーン転送自体) が設計されているデータベース レプリケーションのパラダイムは、単一の中央 DNS サーバーがデータベースのプライマリ バージョンを保持し、他のすべての DNS サーバーが単にコピーを保持するというものであり、多くの最新の DNS サーバー パッケージのパラダイムとは単純に一致しません。^[要出典] SQLサーバーやActive Directoryなどの高度なデータベース バックエンドを備えた最新の DNS サーバー パッケージでは、管理者が複数の場所でデータベースを更新できます (このようなシステムではマルチマスター レプリケーションが採用されています)。データベース バックエンドの独自のレプリケーション メカニズムが、他のすべてのサーバーへのレプリケーションを処理します。このパラダイムは、変更を記録するための単一の中央の単調に増加する番号のパラダイムとは単純に一致しないため、ゾーン転送と大幅に互換性がありません。^[要出典]高度なデータベース バックエンドを備えた最新の DNS サーバー パッケージでは、多くの場合、更新が行われる単一の中央の場所の存在をシミュレートする「シム」シリアル番号が作成されますが、これはせいぜい不完全です。

幸いなことに、この理由と後述するいくつかの理由により、このような高度なデータベース バックエンドを使用する DNS サーバーは、一般に、データベース レプリケーション メカニズムとしてゾーン転送を使用することはほとんどなく、代わりにバックエンド自体が提供するはるかに優れた分散データベース レプリケーション メカニズムを採用するのが一般的です。^{[引用が必要]}

シリアル番号の比較は、RFC 1982 で定義されているシリアル番号演算を使用することを目的としています。ただし、これは RFC 1034 で明確に指定されていなかったため、すべてのクライアントがプリアンブルでシリアル番号のチェックを同じ方法で実行するわけではありません。一部のクライアントは、サーバーから提供されたシリアル番号がクライアントが認識しているものと異なるか、またはゼロでないかどうかのみをチェックします。他のクライアントは、サーバーから提供されたシリアル番号がクライアントが既に認識しているシリアル番号の指定範囲内にあるかどうかをチェックします。さらに、後者のチェックを実行し、さらにサーバーから提供されたシリアル番号がゼロでないかどうかもチェックするクライアントもあります。

元々、実際のデータ転送では、単一のドメイン名とタイプのリソース レコードの各セットが、サーバーからクライアントへの個別の応答メッセージで転送されていました。しかし、これは非効率的であり、一部の DNS サーバー ソフトウェアでは、DNS プロトコルの応答圧縮メカニズムによってデータ転送の総帯域幅要件を削減できるようにするための最適化が実装されています。たとえば、次のようになります。

• 「追加セクション処理」を実行して、NS、SRV、または MX リソース レコード セットと同じ応答に「グルー」リソース レコード セットを含める
• 単一のドメイン名に関連するすべてのリソースレコードセットをまとめて収集し、それらが収まる場合は単一の応答で送信する

一部のクライアントは、元の応答形式のみを期待するように作成されており、このような最適化が採用されるとデータ転送を実行できなくなります。そのため、いくつかの DNS サーバー パッケージには、管理者が「単一応答形式」の応答を必要とするクライアントに対してその使用を指定できる構成設定があります。

DNSゾーンに含まれるデータは、運用上のセキュリティの観点から機密性が高い場合があります。これは、サーバーのホスト名などの情報が公開される可能性があるためです。これは、組織に関する情報の発見に使用され、さらに攻撃対象領域が拡大する可能性もあります。2017年6月、ロシアのトップレベルドメインを担当するレジストラが誤ってAXFR経由のDNSゾーン転送を有効にし、560万件のレコードが誤って公開されました。^[4]

2008年、米国ノースダコタ州の裁判所は、公にアクセスできない情報を入手するために許可されていない部外者としてゾーン転送を実行することは、ノースダコタ州法に違反するとの判決を下した。^[5]

• DNSレコードタイプのリスト

• 「AXFR プロトコルの仕組み」。インターネット出版物、DJ Bernstein。2005年2 月 15 日閲覧。
• 「ゾーンとゾーン転送について」。Microsoft Windows Server 2003 製品ドキュメント。2009 年 10 月 8 日。2011年 11 月 27 日に取得。
• 「Active Directory の DNS サポートの仕組み」。Microsoft Windows Server 2003 製品ドキュメント。2011年 11 月 27 日取得。
• 「Active Directory での DNS ゾーンのレプリケーション」。Microsoft Windows Server 2003 製品ドキュメント。2009 年 10 月 8 日。2011 年 11 月 27 日に取得。
• McClure, Stuart; Scambray, Joel; Kurtz, George (2009)。Hacking Exposed: Network Security Secrets & Solutions (第 6 版)。McGraw- Hill。ISBN 978-0-07-161374-3。

• CAPEC-291 DNS ゾーン転送
• CVE-1999-0532 DNS サーバーはゾーン転送を許可します。
• CWE-16 構成
• CWE-276 デフォルトの権限が正しくありません

• RFC 5936 DNS ゾーン転送プロトコル (AXFR の定義、RFC 1034 ドメイン名 - 概念と機能、および RFC 1035 ドメイン名 - 実装と仕様の更新)
• RFC 1995 DNS における増分ゾーン転送
• RFC 1996 ゾーン変更の迅速な通知メカニズム (DNS NOTIFY)
• draft-ietf-dnsext-axfr-clarify DNS ゾーン転送プロトコル (AXFR)インターネット ドラフト