DNSゾーンのエクスポートを文書化する:原本と不足情報を分けて残す
DNSエクスポートにレコードのテキストが残っていても、必要な情報がすべて揃ったとは限りません。変更しない原本、期待するレコードセット一覧、事業者固有の機能や復元上の不足を記す別紙の三つを関連づけます。本稿は2026年10月14日に閲覧した資料に基づく解説で、エクスポート、アカウント調査、インポートは実施していません。
Boletolibre編集部
公開日
エクスポートが表す範囲を決める
後日のエクスポートを計画する前に、ゾーン、公開・非公開の範囲、事業者、表現形式、許可された取得方法を記録します。その方法がどのレコードセットや設定を含むのか、資料上の範囲を確認します。ダウンロードできるファイル、合致するハッシュ、構文解析の成功は、情報の完全性、機能の同等性、復元の成功とは別の問いに答えるものです。
原本は承認された保護領域に保管します。後日、許可を得て実際に取得した場合だけ、取得日時とタイムゾーン、方法、バイト数、ハッシュを記録します。例から実測値を作ってはいけません。編集には別の作業コピーを使い、意味のあるコメントや出所を残します。コメントだから不要とは限りません。
空欄の証拠台帳から始める
表紙:ゾーンと範囲の参照先____、取得元事業者と資料の日付____、許可された取得担当者と方法____、実際の取得日時とタイムゾーン____、保護された原本の保存先・取得済みの場合のバイト数とハッシュ____、作業コピー____、移行先・インポートモード・現行資料____、期待セット数・個別レコード数・除外項目____。根拠がない欄は不明と明記します。
| 項目 | 期待する名前・種類のセットごとに記入 |
|---|---|
| 識別と内容 | 名前・種類____、全値または承認された限定公開の参照先____、原本内の位置____。 |
| レコードの意味 | 明示・継承TTLと単位____、該当する優先度・重み・ポートなどの属性____。 |
| 事業者の属性 | モード・機能・コメント・タグ____、資料と日付____、表現済み・事業者固有・不明____。 |
| 網羅性と担当 | 原本に存在・欠落____、差異____、追加根拠の担当者と確認基準____。 |
別紙の欄:機能または権威情報の論点____、取得元と移行先の資料・日付____、理解済み・変換が必要・非対応・不明____、想定差異____、担当者____、別途許可された後日の受け入れ基準と証拠____。文書化した想定と、すでに受け入れ済みの操作を区別します。
取得元と移行先の規則を別々に読む
2026年4月16日更新のCloudflare資料には、行内コメントと、出力される予約済みcf-タグの説明があります。cf-proxied:trueとcf-proxied:falseは、プロキシ有効とDNSのみのレコード設定を表します。インポート時はレコード単位のタグが全体の選択に優先し、タグがなければ全体設定が使われます。他社が同じ解釈や同等のプロキシを提供すると考えず、この文脈を保存します。[2]
説明されたインポートでは、Cloudflareは$ORIGIN、$TTL、$GENERATEに対応し、$INCLUDEには対応しません。2026年8月11日更新のAzureポータル資料は$ORIGINと$TTLに対応し、$GENERATEと$INCLUDEを拒否します。一方のインポーターに適したファイルが他方にも適するとは限りません。操作前には対象製品、モード、現在の制限を再確認します。[2][1]
Azureはゾーン新規作成時のインポートと既存ゾーンへのマージを区別します。記載のマージでは通常、既存セットのTTLを使い、CNAMEは既存CNAMEを置き換え得ますが、別種類との競合では既存レコードを使います。SOAホストと頂点NSデータは事業者管理のままで、他のSOAパラメーターや頂点NSのTTLとは扱いが別です。TXTの文字列構造も変わる可能性があります。いずれも限定された変換上の論点で、復元実施の証拠ではありません。[1]
架空のCopper Lantern Archiveで不足を数える
| 期待する架空セット | 原本での表現と分類 |
|---|---|
| R1 Apex-A | OneWebV4Old、TTL 1800秒。表現済み。 |
| R2 Apex-AAAA | OneWebV6Old、TTL 1800秒。表現済み。 |
| R3 WWW-CNAME | TargetApex、TTL Auto、コメントタグcf-proxied:true。事業者固有で原本に存在。 |
| R4 Apex-MX | 優先度10、MailTarget、TTL 3600秒。表現済み。 |
| R5 Apex-SPF-TXT | 仮の値ExistingProviderApprovedSPF、TTL 3600秒。表現済み。 |
| R6 ServiceVerification-TXT | 架空の所有者メモにProviderVerificationPlaceholder。F-001にはなく、不明。 |
表現済み四つ+事業者固有一つ+不明一つ=期待する六行です。四つ+一つ=原本にある五セット、六−五=欠落一セット。これはセット数であり、ファイル行数や個別レコード総数ではありません。SOAと頂点NSは意図的に除外し、別に記録します。仮の値は公開可能な実アドレス、SPFポリシー、検証値ではありません。
未解決の不足と権威情報の想定を分ける
G1:R3のテキストはありますが、移行先のプロキシ動作の意味は未解決です。CNAME行だけで機能同等性は示せません。G2:R6は説明上の原本に欠落しています。所有者メモは追加根拠が必要なことを示すだけで、値の公開を許可しません。Lenaが承認済みの網羅性の根拠と移行先機能の判断を得る必要があります。未解決二件のため、完全性と厳密な機能同等性はHOLDです。
A1のSOAホスト、A2の頂点NSデータは事業者管理です。これは移行先での変換に関する二つの文書化した想定で、六つのアプリ・メール用セットには含めません。追加の欠落行でも、変換完了の証拠でもありません。委任変更は別途許可された計画で扱います。ファイルはメール継続やサイト準備完了を証明しません。[1]
後日の受け入れで何を確かめるか
別途許可されたインポートの前に、移行先製品とモード、新規作成かマージか、該当するディレクティブや容量の制限、競合、必要な変換、各担当者が受け入れる後日の証拠を記します。原本とハッシュはバイト列を識別し、解析の受理はその文脈での構文を扱います。どちらもG1・G2を解消せず、権威情報、メール、プロキシ、サービスの正常動作を示しません。
この資料一式をアカウント全体のバックアップと呼ばないでください。アカウント、認証情報、秘密鍵、サービス設定には別の承認済み復旧手順が必要です。どの設定が表現され、どれが参照されるのかを記録します。どのエクスポートも全機能を欠く、または一つですべてを含むと決めつけません。
根拠の範囲を示した文書判断を引き継ぐ
変更しない原本の参照先、独立した一覧、機能・権威情報の別紙、除外事項、未解決事項の担当者、後日の受け入れ基準を渡します。各論点を文書化済み、証拠待ちの保留、または日付付き証拠による受け入れ済みに分類します。架空例の結果はHOLDのままで、インポート許可ではありません。切り替え順序、メール依存関係、TTLの時間判断は関連ガイドで扱います。
出典と参考資料
- Azure DNSポータルのインポート・エクスポートとマージ:2026年8月11日更新Microsoft Learn · 確認日
- Cloudflare DNSのインポート・エクスポート、ディレクティブ、設定タグ:2026年4月16日更新Cloudflare · 確認日