DNSゾーンファイルとは：レコードと名前の基本

DNSゾーンファイルは、example.com のようなゾーンのDNSレコードをテキストで表現したものです。名前と、それに関連付けられたデータ（アドレス、エイリアス、メールエクスチェンジャー、ネームサーバー、テキストポリシーなど）を記述します。マネージドプロバイダーの多くは、ファイルそのものをウェブインターフェースの裏に隠していますが、エクスポートとインポートでは今もゾーンファイルの考え方が使われています。この形式を理解しておくと、プロバイダーの移行、監査、トラブルシューティングで役立ちます。構文としては正しいレコードでも、誤った名前に付いていたり、想定外のデフォルト値で解釈されたりすることがあるからです。丁寧に確認するには、各レコードの内容と、そのレコードが置かれているゾーンの文脈の両方を見る必要があります。

リソースレコードの構成要素

リソースレコードには、一般に所有者名、省略可能なTTL、クラス（通常はインターネット用データを表す IN）、レコードタイプ、そしてタイプ固有のデータが含まれます。Aレコードの行にはIPv4アドレスが、MXの行には優先度とメールエクスチェンジャーのホスト名が、CNAMEの行には正規の名前が入ります。ゾーンファイルでは相対名を使うことができ、その場合、所有者名はゾーンのオリジンからの相対名として解釈されます。また、@ のような特殊な記号でゾーンの頂点（エイペックス）を表すこともできます。末尾のドットは、完全修飾名であることを示します。データをインポートするとき、相対名と絶対名を取り違えると、ドメインのサフィックスが重複した名前が意図せず作られてしまうことがあります。

ゾーンの頂点（エイペックス）とは、example.com のようにサブドメインを含まないゾーン名そのもので、ゾーンファイルではよく @ で表されます。ゾーンのSOAレコードとNSレコードは、ここに置きます。頂点のAレコードとAAAAレコードはアドレスを公開し、www や mail のようなサブドメインの所有者名は、別個の名前を表します。プロバイダーによっては、頂点にアドレスがあるように見せながら、裏ではホスト名をたどるALIASやフラットニングといった機能を提供しています。これらは、ルートに置く通常のCNAMEレコードではなく、プロバイダー固有の動作です。移行の際は、移行先のプロバイダーがこうした機能をどう扱うかを確認してから、そのままコピーしてください。

ゾーンはサービス全体の地図として確認する

DNSのエクスポートを、ウェブサイトの設定だけと考えてはいけません。メールの配信は、MXに加えて、SPF、DKIM、DMARCのTXTレコードに依存している場合があります。アナリティクス、検索サービス、証明書システム、SaaSプラットフォームの所有確認が、TXTやCNAMEレコードに頼っていることもあります。サービスディスカバリーにはSRVが使われ、委任されたサブドメインには、独自のNSレコードがある場合もあります。見慣れない古いレコードが、本番環境の依存関係を支えているかもしれません。何かを削除する前に、その持ち主と目的を特定してください。出所が分からない場合は、アプリケーションのドキュメントと照合し、使われていないように見えるホスト名でも安全に削除できると思い込まず、担当チームに確認してください。

• プロバイダーの移行やクリーンアップの前に、ゾーン全体をエクスポートする。
• 相対名のルールを含め、頂点とサブドメインの名前を慎重に確認する。
• メール、所有確認、委任されたサブドメインのレコードを保持する。
• TTLと、プロバイダー固有のフラットニングやプロキシ機能を確認する。
• インポート後は、権威ネームサーバーに問い合わせて、重要なレコードを比較する。

安全にインポートして検証する

ゾーンファイルのインポートは、未対応のレコードタイプ、書式の違い、所有者名の重複、プロバイダー固有の拡張などが原因で失敗することがあります。切り替えの前に、エクスポートしたファイルを検証し、プロバイダーのインポートレポートで、スキップされたレコードがないかを確認してください。DNSプロバイダーを変更する場合は、レジストラの委任を更新する前に、新しいゾーンにレコードが登録済みであることを確かめます。委任を変更したら、NSレコードを確認し、主要なレコードを直接問い合わせます。実際の応答をエクスポート元と比べ、ウェブサイトとメールについて、サービス固有のチェックを実行してください。インポートが構文上成功したことは、移行が検証されたことと同じではありません。それが証明するのは、ツールがファイルを受け付けたという事実だけです。

主なレコードの意味については、DNSレコードタイプの解説 をご覧ください。移行におけるネームサーバー側については、NSレコードの役割 をお読みください。ゾーンファイルは、設定をコンパクトにまとめた一覧であり、その価値は、チームが生の行だけでなく文脈も一緒に残したときに最大になります。珍しいレコードがある理由、その持ち主、そのレコードに依存しているサービスをメモしておきましょう。このわずかな記録が、あとで行うクリーンアップで重要なものが黙って消えてしまうのを防ぎます。

エクスポートした行だけでなく、意図も残す

ゾーンの生のエクスポートは便利なバックアップですが、そのレコードがなぜあるのか、どのチームが依存しているのかを説明してくれることはほとんどありません。ファイルと並べて、アプリケーションの担当者、ベンダー、更新または見直しの日付、値を変更しても安全かどうかを記載した一覧を用意してください。この文脈は、TXTレコードで特に重要です。意味のないトークンのように見えても、ドメインの所有権を証明したり、メールシステムを承認したりしている場合があります。監査では、現在使われているレコードと、すでに不要だが移行のために残してあるレコードを区別します。新しいプロバイダーにインポートしたあとは、データと動作の両方を比較してください。プロバイダー固有のプロキシの切り替え、フラットニング、検証の設定は、通常のゾーンファイルの行としては表現されないことがあります。ゾーンは運用上の設定であり、その意図を残しておけば、のちの変更がより安全になります。