DNSゾーンファイルとは

DNSゾーンファイルとは、特定のDNSゾーンに関するDNSレコードを記述したデータファイルのことです。

ドメイン名とIPアドレスの対応関係、メールサーバーの指定、ネームサーバーの情報、TXTレコードによる認証情報など、ドメインを正しく利用するために必要なDNS情報がまとめられています。

たとえば、Webサイトにアクセスするとき、ユーザーは example.com のようなドメイン名を入力します。

しかし、インターネット上の通信では、実際にはIPアドレスが使われます。

そのため、DNSでは次のような対応関係を管理します。

example.com.      IN  A   203.0.113.10
www.example.com.  IN  A   203.0.113.10

このようなDNSレコードをまとめて記述したものが、DNSゾーンファイルです。

簡単にいうと、DNSゾーンファイルは、「このドメインでは、どの名前をどのサーバーに向けるか」を定義するファイルと考えるとわかりやすいです。

DNSゾーンファイルの「ゾーン」とは？

DNSゾーンファイルを理解するには、まずゾーンという考え方を押さえる必要があります。

DNSにおけるゾーンとは、DNS名前空間のうち、特定の管理者や権威DNSサーバーが管理権限を持つ範囲のことです。

たとえば、example.com というドメインを管理している場合、一般的には次のような名前を同じゾーンで管理します。

example.com
www.example.com
mail.example.com
blog.example.com

この場合、example.com ゾーンのDNS情報をまとめたものが、example.com のDNSゾーンファイルです。

ただし、サブドメインが別のネームサーバーに委任されている場合、そのサブドメインは別のゾーンとして扱われます。

たとえば、shop.example.com を別のDNSサーバーに委任している場合、shop.example.com は example.com とは別のゾーンとして管理されることがあります。

つまり、DNSゾーンとは、単に「ドメイン配下すべて」という意味ではなく、管理権限が及ぶ範囲を指します。

DNSゾーンファイルの役割

DNSゾーンファイルの主な役割は、ドメインに関するDNSレコードを定義することです。

具体的には、次のような情報を管理します。

管理する情報	主に使うDNSレコード
ドメイン名とIPv4アドレスの対応	Aレコード
ドメイン名とIPv6アドレスの対応	AAAAレコード
サブドメインの向き先	A、AAAA、CNAMEレコード
メールサーバーの指定	MXレコード
ネームサーバーの指定	NSレコード
ゾーンの管理情報	SOAレコード
SPF、DKIM、DMARCなどの認証情報	TXTレコード
証明書を発行できる認証局の指定	CAAレコード

Webサイトの表示、メールの送受信、サブドメインの運用、メール認証、CDNの導入など、さまざまな場面でDNSゾーンファイルの内容が関係します。

DNSゾーンファイルに書かれる主なDNSレコード

DNSゾーンファイルには、複数のDNSレコードが記述されます。

代表的なDNSレコードは次の通りです。

レコード	役割
SOAレコード	ゾーンの管理情報を定義する
NSレコード	そのゾーンを管理するネームサーバーを指定する
Aレコード	ドメイン名をIPv4アドレスに対応させる
AAAAレコード	ドメイン名をIPv6アドレスに対応させる
CNAMEレコード	ある名前を別のホスト名の別名として扱う
MXレコード	メールの配送先サーバーを指定する
TXTレコード	任意のテキスト情報を設定する
PTRレコード	IPアドレスからホスト名を逆引きする
SRVレコード	特定サービスの提供先サーバーを指定する
CAAレコード	SSL/TLS証明書を発行できる認証局を指定する

この中でも、Webサイトやメール運用でよく使うのは、Aレコード、AAAAレコード、CNAMEレコード、MXレコード、TXTレコード、NSレコード、SOAレコードです。

DNSゾーンファイルの基本的な書式

DNSゾーンファイルのレコードは、一般的に次のような形式で記述されます。

名前  TTL  クラス  タイプ  値

たとえば、次のような記述です。

www.example.com.  3600  IN  A  203.0.113.10

それぞれの意味は次の通りです。

項目	意味
名前	対象となるドメイン名やホスト名
TTL	DNS情報をキャッシュしてよい時間
クラス	通常は IN を指定する
タイプ	A、MX、TXTなどのレコード種別
値	IPアドレス、ホスト名、テキスト情報など

上記の例は、www.example.com は 203.0.113.10 に対応するという意味です。

DNSゾーンファイルの例

以下は、シンプルなDNSゾーンファイルの例です。

$TTL 3600
$ORIGIN example.com.

@   IN  SOA ns1.example.com. admin.example.com. (
        2026042801 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600       ; minimum
)

@       IN  NS   ns1.example.com.
@       IN  NS   ns2.example.com.

ns1     IN  A    203.0.113.53
ns2     IN  A    203.0.113.54

@       IN  A    203.0.113.10
www     IN  A    203.0.113.10
mail    IN  A    203.0.113.20

@       IN  MX   10 mail.example.com.

@       IN  TXT  "v=spf1 include:_spf.example.net ~all"

この例では、次のような設定を行っています。

記述	意味
$TTL 3600	デフォルトTTLを3600秒に設定
$ORIGIN example.com.	相対名の基準を example.com. に設定
SOAレコード	ゾーンの管理情報を設定
NSレコード	権威DNSサーバーを指定
Aレコード	WebサーバーやメールサーバーのIPアドレスを指定
MXレコード	メールの配送先を指定
TXTレコード	SPFなどの認証情報を指定

なお、203.0.113.x はドキュメント用に予約されているIPアドレスです。

実際のDNS設定では、利用しているサーバーやDNSサービスから指定されたIPアドレスを設定します。

DNSゾーンファイルで使われる主な記号・項目

DNSゾーンファイルでは、$TTL、$ORIGIN、@、末尾のドットなど、独特の記述が使われます。

それぞれの意味を理解しておくと、ゾーンファイルの内容を読み取りやすくなります。

$TTLとは？

$TTL は、DNSゾーンファイル内で使われるデフォルトTTLを指定するためのディレクティブです。

TTLは「Time To Live」の略で、DNS情報をキャッシュしてよい時間を表します。

たとえば、次のように書かれている場合、

$TTL 3600

個別のレコードにTTLが指定されていなければ、デフォルトで3600秒、つまり1時間のTTLが適用されます。

たとえば、次の例を見てみましょう。

$TTL 3600
www   600  IN  A  203.0.113.10
mail       IN  A  203.0.113.20

この場合、TTLは次のようになります。

レコード	TTL
www.example.com	600秒
mail.example.com	3600秒

www には個別に 600 が指定されているため、TTLは600秒です。

一方、mail には個別のTTLがないため、$TTL 3600 が適用されます。

TTLは、DNSの変更反映時間にも関係します。TTLが長いとキャッシュが長く残りやすく、DNSサーバーへの問い合わせを減らせます。

一方で、DNS設定を変更したときに反映まで時間がかかる場合があります。

逆に、TTLが短いと変更は比較的早く反映されやすくなりますが、DNSへの問い合わせ回数は増えやすくなります。

ただし、TTLは「必ずその時間だけキャッシュされる」という意味ではなく、その時間を上限としてキャッシュしてよいという意味です。

DNSリゾルバー、OS、ブラウザ、CDNなどのキャッシュが影響し、設定変更がすぐに反映されないこともあります。

$ORIGINとは？

$ORIGIN は、DNSゾーンファイル内で使われる相対名の基準を指定するディレクティブです。

たとえば、次のように書かれている場合、

$ORIGIN example.com.

ゾーンファイル内の相対的な名前は、example.com. を基準として解釈されます。

www   IN  A  203.0.113.10
mail  IN  A  203.0.113.20

この場合、実際には次の意味になります。

www.example.com.   IN  A  203.0.113.10
mail.example.com.  IN  A  203.0.113.20

つまり、www や mail のようにドメイン名を省略して書いた場合、$ORIGIN で指定されたドメイン名が補完されます。

@の意味

DNSゾーンファイルでは、@ という記号がよく使われます。

@ は、現在の $ORIGIN を表します。通常は、そのゾーン名を意味します。

たとえば、次のように $ORIGIN が指定されている場合、

$ORIGIN example.com.

次の記述は、

@  IN  A  203.0.113.10

次と同じ意味になります。

example.com.  IN  A  203.0.113.10

つまり、@ はゾーンの基点となるドメイン名を省略して書くための記号です。

Webサイトのルートドメイン、つまり example.com 自体にAレコードやMXレコードを設定する場合によく使われます。

末尾のドットの意味

DNSゾーンファイルでは、ドメイン名の末尾にドットを付けることがあります。

example.com.
mail.example.com.
ns1.example.com.

この末尾のドットは、その名前が完全修飾ドメイン名であることを示します。

完全修飾ドメイン名は、FQDNとも呼ばれます。

たとえば、次のように末尾にドットがある場合、

mail.example.com.

これは絶対的なドメイン名として扱われます。

一方、末尾にドットがない場合、$ORIGIN が補完されることがあります。

たとえば、$ORIGIN example.com. のゾーンファイル内で、

mail

と書くと、通常は次のように解釈されます。

mail.example.com.

この仕組み自体は便利ですが、外部ドメイン名を指定するときに末尾のドットを忘れると、意図しない名前として解釈されることがあります。

たとえば、example.com のゾーンファイルで次のように書いた場合、

@  IN  MX  10 mail.example.com

末尾のドットがないため、環境によっては次のように解釈される可能性があります。

mail.example.com.example.com.

そのため、MXレコードやCNAMEレコードなどで完全なホスト名を指定する場合は、次のように末尾のドットを付けるのが安全です。

@  IN  MX  10 mail.example.com.

SOAレコードとは？

SOAレコードは「Start of Authority」の略で、そのゾーンの管理情報を示すDNSレコードです。

DNSゾーンファイルには、通常、SOAレコードが1つ含まれます。

@   IN  SOA ns1.example.com. admin.example.com. (
        2026042801 ; serial
        3600       ; refresh
        900        ; retry
        1209600    ; expire
        3600       ; minimum
)

SOAレコードには、主に次のような情報が含まれます。

項目	内容
プライマリDNSサーバー	そのゾーンの基準となるDNSサーバー
管理者メールアドレス	ゾーン管理者の連絡先
serial	ゾーンデータの更新番号
refresh	セカンダリDNSが更新確認する間隔
retry	更新確認に失敗した場合の再試行間隔
expire	ゾーンデータを有効とみなす期限
minimum	主にネガティブキャッシュTTLとして使われる値

SOAレコードのserialとは？

SOAレコードで特に重要なのが、serial です。

serialは、ゾーンデータの更新番号です。

ゾーンファイルを変更した場合、serialの値を増やすことで、セカンダリDNSサーバーが「ゾーンデータが更新された」と判断しやすくなります。

よく使われる形式は、次のような日付ベースの番号です。

YYYYMMDDNN

たとえば、

2026042801

であれば、2026年4月28日の1回目の更新という意味で使えます。

ただし、必ずこの形式でなければならないわけではありません。

重要なのは、更新時に以前より大きい値にすることです。

SOAレコードの管理者メールアドレスに注意

SOAレコード内の管理者メールアドレスは、通常のメールアドレス表記とは異なります。

たとえば、次の記述を見てみましょう。

admin.example.com.

これは、実際には次のメールアドレスを意味します。

admin@example.com

DNSゾーンファイルでは、SOAレコード内の管理者メールアドレスについて、@ をドットに置き換えて記述します。

そのため、admin@example.com を表したい場合は、次のように書きます。

admin.example.com.

初心者が混乱しやすい部分なので、SOAレコードを見るときは注意が必要です。

SOAレコードのminimumとは？

SOAレコードの最後にある minimum は、現在では主にネガティブキャッシュTTLとして使われます。

ネガティブキャッシュとは、存在しないレコードに対する問い合わせ結果を一定時間キャッシュする仕組みです。

たとえば、存在しない abc.example.com に問い合わせがあった場合、DNSリゾルバーは「その名前は存在しない」という結果を一定時間キャッシュすることがあります。

SOAレコードの minimum は、このような存在しないレコードの問い合わせ結果をどの程度キャッシュするかに関係します。

古いDNSの解説では、SOAの minimum を「ゾーン内レコードのデフォルトTTL」と説明していることもあります。

しかし、現在のゾーンファイルでは、通常 $TTL ディレクティブでデフォルトTTLを指定します。

DNSゾーンファイルとDNSレコードの違い

DNSゾーンファイルとDNSレコードは混同されやすいですが、意味が異なります。

DNSゾーンファイルは、複数のDNSレコードをまとめたデータファイルです。

一方、DNSレコードは、DNSゾーンファイルの中に書かれる1つ1つの設定情報です。

たとえば、次の1行がDNSレコードです。

www  IN  A  203.0.113.10

このようなDNSレコードが複数集まったものが、DNSゾーンファイルです。

簡単に整理すると、次のようになります。

DNSゾーンファイル = DNSレコードをまとめたもの
DNSレコード = 1つ1つのDNS設定

たとえるなら、DNSゾーンファイルは「住所録全体」、DNSレコードは「住所録に書かれた1件1件の情報」のようなものです。

DNSゾーンファイルと権威DNSサーバーの関係

DNSゾーンファイルは、主に権威DNSサーバーで使われます。

権威DNSサーバーとは、特定のドメインについて正式なDNS情報を持っているDNSサーバーのことです。

たとえば、example.com の権威DNSサーバーが ns1.example.com と ns2.example.com であれば、これらのサーバーが example.com のDNS情報を管理します。

そのDNS情報の元になるデータが、DNSゾーンファイルです。

ただし、現在ではCloudflare、Amazon Route 53、Google Cloud DNS、各種レンタルサーバー、ドメイン管理サービスなどを使ってDNSを管理するケースも多くなっています。

その場合、ユーザーがゾーンファイルを直接編集するのではなく、管理画面からAレコード、CNAMEレコード、MXレコード、TXTレコードなどを設定します。

管理画面で設定した内容は、サービス側の内部システムによってゾーンデータとして管理されます。

プライマリDNSとセカンダリDNSにおけるゾーンファイル

従来のDNS運用では、ゾーンデータの元となるDNSサーバーをプライマリDNSサーバー、そこからゾーンデータを受け取るDNSサーバーをセカンダリDNSサーバーと呼びます。

プライマリDNSサーバーでは、ゾーンデータの元となる情報を管理します。ゾーンファイルを直接編集する構成では、通常、プライマリDNSサーバー側のゾーンファイルを更新します。

一方、セカンダリDNSサーバーは、プライマリDNSサーバーからゾーンデータを取得して保持します。

このデータ取得の仕組みをゾーン転送といいます。

ゾーン転送には、主に次のような方式があります。

方式	内容
AXFR	ゾーン全体を転送する方式
IXFR	変更差分を転送する方式

セカンダリDNSサーバーは、SOAレコードのserialなどを確認し、必要に応じてプライマリDNSサーバーから最新のゾーンデータを取得します。

これにより、複数のDNSサーバーで同じゾーン情報を保持でき、1台のDNSサーバーに障害が発生しても名前解決を継続しやすくなります。

ただし、クラウドDNSやDNS管理サービスでは、内部的に複数の権威DNSサーバーへ分散されていることが多く、利用者がプライマリDNSやセカンダリDNSを直接意識しないケースも一般的です。

DNSゾーンファイルでよく使われるレコードの例

ここからは、DNSゾーンファイルでよく使われる主要なDNSレコードについて、具体例を交えて解説します。

Aレコード

Aレコードは、ドメイン名をIPv4アドレスに対応させるレコードです。

@    IN  A  203.0.113.10
www  IN  A  203.0.113.10

この例では、example.com と www.example.com が 203.0.113.10 に対応します。

Webサイトを公開するときによく使われるレコードです。

AAAAレコード

AAAAレコードは、ドメイン名をIPv6アドレスに対応させるレコードです。

www  IN  AAAA  2001:db8::10

IPv6環境で名前解決を行う場合に使われます。

AレコードがIPv4用であるのに対し、AAAAレコードはIPv6用です。

CNAMEレコード

CNAMEレコードは、ある名前を別のホスト名の別名として扱うためのレコードです。

blog  IN  CNAME  example-blog.example.net.

この場合、blog.example.com は example-blog.example.net の別名として扱われます。

CNAMEレコードは、外部サービスやCDN、ブログサービス、計測ツールなどを独自ドメインに接続するときによく使われます。

ただし、CNAMEには重要な注意点があります。

CNAMEレコードを設定した名前には、原則として他のレコードを同時に設定できません。

たとえば、次のような設定は不適切です。

www  IN  CNAME  example.com.
www  IN  A      203.0.113.10

www にCNAMEを設定しているにもかかわらず、同じ www にAレコードも設定しているためです。

CNAMEを使う場合は、同じ名前に他のレコードを置かないように注意しましょう。

MXレコード

MXレコードは、メールの配送先サーバーを指定するレコードです。

@  IN  MX  10 mail.example.com.

この例では、example.com 宛てのメールを mail.example.com に配送することを示しています。

MXレコードの数値は優先度を表します。数値が小さいほど優先度が高くなります。

@  IN  MX  10 mail1.example.com.
@  IN  MX  20 mail2.example.com.

この場合、通常は mail1.example.com が優先され、利用できない場合に mail2.example.com が使われます。

また、MXレコードの参照先には、CNAMEではなく、AレコードまたはAAAAレコードで直接解決できるホスト名を指定するのが原則です。

たとえば、次のように設定します。

@     IN  MX  10 mail.example.com.
mail  IN  A       203.0.113.20

メール配送の安定性を考えると、MXの参照先をCNAMEにする設定は避けるべきです。

TXTレコード

TXTレコードは、任意のテキスト情報をDNSに登録するためのレコードです。

@  IN  TXT  "v=spf1 include:_spf.example.net ~all"

TXTレコードは、特にメール認証でよく使われます。

代表的な用途は次の通りです。

用途	内容
SPF	送信元メールサーバーの正当性を示す
DKIM	メールに電子署名を付けて改ざんを検出する
DMARC	SPFやDKIMの検証結果に基づく処理方針を指定する
ドメイン所有確認	Google Search Consoleなどの認証に使う

Webマーケティングやメール配信の実務では、TXTレコードの設定が非常に重要です。

SPF、DKIM、DMARCの設定が不十分だと、メールが迷惑メール扱いされやすくなることがあります。

NSレコード

NSレコードは、そのゾーンを管理するネームサーバーを指定するレコードです。

@  IN  NS  ns1.example.com.
@  IN  NS  ns2.example.com.

この例では、example.com の権威DNSサーバーとして ns1.example.com と ns2.example.com を指定しています。

NSレコードは、DNSの委任にも関係します。

たとえば、shop.example.com を別のDNSサーバーに委任する場合、親ゾーンである example.com 側に次のようなNSレコードを設定することがあります。

shop  IN  NS  ns1.other-dns.example.
shop  IN  NS  ns2.other-dns.example.

これにより、shop.example.com のDNS情報は別のネームサーバーで管理されます。

PTRレコード

PTRレコードは、IPアドレスからホスト名を調べる逆引きDNSで使われるレコードです。

通常の正引きゾーンではなく、in-addr.arpa や ip6.arpa などの逆引き用ゾーンに記述されます。

たとえば、IPv4アドレス 203.0.113.10 の逆引きでは、次のようなゾーンが使われます。

113.0.203.in-addr.arpa.

その中で、次のようにPTRレコードを設定します。

10  IN  PTR  example.com.

PTRレコードは、特にメールサーバーの信頼性に関係することがあります。

メール配信では、送信元IPアドレスの逆引き設定が適切でないと、受信側で不審なメールと判断される場合があります。

ただし、PTRレコードは通常、ドメイン管理画面ではなく、IPアドレスを管理しているサーバー事業者やクラウド事業者側で設定することが多いです。

CAAレコード

CAAレコードは、SSL/TLS証明書を発行できる認証局を指定するためのレコードです。

@  IN  CAA  0 issue "letsencrypt.org"

この例では、example.com に対してLet’s Encryptが証明書を発行できることを示しています。

CAAレコードを設定することで、意図しない認証局から証明書が発行されるリスクを抑えることができます。

DNSゾーンファイルでよくある設定ミス

DNSゾーンファイルは、少しの記述ミスでもWebサイトの表示やメールの送受信に影響することがあります。

ここでは、よくある設定ミスを紹介します。

末尾のドットを忘れる

完全なホスト名を指定するときに末尾のドットを忘れると、意図しない名前として解釈されることがあります。

悪い例は次の通りです。

@  IN  MX  10 mail.example.com

$ORIGIN example.com. の環境では、mail.example.com.example.com. のように解釈される可能性があります。

正しくは次のように書きます。

@  IN  MX  10 mail.example.com.

外部ドメインや完全修飾ドメイン名を指定するときは、末尾のドットに注意しましょう。

SOAレコードのserialを更新し忘れる

ゾーンファイルを変更したあと、SOAレコードのserialを更新し忘れると、セカンダリDNSサーバーが変更を検知できないことがあります。

特に、プライマリDNSとセカンダリDNSを使っている環境では注意が必要です。

たとえば、次のようなserialを使っている場合、

2026042801

同じ日に2回目の更新を行うなら、次のように増やします。

2026042802

ゾーンファイルを直接編集する運用では、レコードの変更だけでなく、serialの更新も忘れないようにしましょう。

CNAMEと他のレコードを同じ名前に設定する

CNAMEレコードを設定した名前には、原則として他のレコードを同時に設定できません。

悪い例は次の通りです。

www  IN  CNAME  example.com.
www  IN  A      203.0.113.10

この場合、www にCNAMEとAレコードが同時に設定されています。

www をCNAMEにするなら、同じ www にAレコードなどを併用しないようにします。

MXレコードの参照先にCNAMEを使う

MXレコードの参照先には、AレコードまたはAAAAレコードで直接解決できるホスト名を指定するのが原則です。

避けた方がよい例は次の通りです。

@     IN  MX     10 mail.example.com.
mail  IN  CNAME  server.example.net.

この場合、MXレコードの参照先である mail.example.com がCNAMEになっています。

メール配送の互換性や安定性を考えると、次のようにAレコードまたはAAAAレコードで直接解決できるようにするのが基本です。

@     IN  MX  10 mail.example.com.
mail  IN  A       203.0.113.20

TTLを短くすればすぐ反映されると思い込む

TTLを短くすると、DNS変更が比較的早く反映されやすくなります。

しかし、TTLを短くしたからといって、すべての環境ですぐにDNS変更が反映されるとは限りません。

DNSリゾルバー、OS、ブラウザ、CDN、プロキシなどのキャッシュが影響する場合があります。

サーバー移転やDNS切り替えを行う場合は、事前にTTLを短くしておき、切り替え後も反映状況を確認することが重要です。

DNSゾーンファイルは誰が編集するのか

DNSゾーンファイルを直接編集するのは、主に次のようなケースです。

ケース	内容
自前でDNSサーバーを運用している場合	BINDなどでゾーンファイルを直接管理する
VPSや専用サーバーでDNSを構築している場合	サーバー上のゾーンファイルを編集する
大規模なDNS運用をしている場合	Gitなどでゾーンファイルを管理することもある
DNS管理サービスを使っている場合	管理画面からDNSレコードを編集する

一般的なレンタルサーバー、ドメイン管理サービス、クラウドDNSを利用している場合、ユーザーがゾーンファイルそのものを直接編集することは少ないです。

多くの場合、管理画面から次のような項目を設定します。

ホスト名
レコード種別
TTL
値

たとえば、管理画面でAレコードやMXレコードを追加すると、その内容がサービス側でゾーンデータとして管理されます。

つまり、直接ゾーンファイルを触らなくても、DNSゾーンファイルの考え方を理解しておくと、DNS管理画面で何を設定しているのかがわかりやすくなります。

DNSゾーンファイルを理解すると何ができるのか

DNSゾーンファイルの仕組みを理解すると、Webサイトやメールに関する設定・トラブル対応がしやすくなります。

具体的には、次のような場面で役立ちます。

場面	関係するDNS設定
Webサイトを公開する	Aレコード、AAAAレコード
サブドメインを作成する	Aレコード、CNAMEレコード
サーバー移転を行う	Aレコード、TTL
CDNを導入する	CNAMEレコード、Aレコード
独自ドメインメールを使う	MXレコード
メール到達率を改善する	SPF、DKIM、DMARC、PTR
SSL/TLS証明書を管理する	CAAレコード、TXTレコード
Google Search Consoleなどで所有権確認をする	TXTレコード
外部SaaSと独自ドメインを接続する	CNAMEレコード、TXTレコード

特にWebサイト運営やWebマーケティングでは、DNSの理解が重要です。

たとえば、DNS設定を誤ると、次のようなトラブルが起きることがあります。

Webサイトが表示されない
サブドメインが使えない
メールが受信できない
メールが迷惑メールに入りやすい
CDNや外部サービスの認証が通らない
Google Search Consoleの所有権確認ができない

DNSゾーンファイルの基本を理解しておくと、こうしたトラブルの原因を切り分けやすくなります。

DNSゾーンファイルのイメージ

DNSゾーンファイルは、ドメインの「住所録」のようなものです。

たとえば、次のように考えるとわかりやすいです。

DNSの要素	たとえ
ドメイン名	会社名や建物名
IPアドレス	実際の住所
Aレコード	Webサイトの住所
MXレコード	メールの配送先
NSレコード	住所録を管理する管理者
SOAレコード	住所録の管理情報
TTL	住所録の情報を覚えておいてよい時間
DNSゾーンファイル	住所録全体

ユーザーは example.com のような覚えやすい名前でWebサイトにアクセスします。

しかし、インターネット上では、最終的にIPアドレスが必要になります。

そのため、DNSはドメイン名とIPアドレスなどの対応関係を管理します。

DNSゾーンファイルは、その対応関係をまとめたデータファイルです。

まとめ

DNSゾーンファイルとは、特定のDNSゾーンに関するDNSレコードを記述したデータファイルです。

DNSゾーンファイルには、Aレコード、AAAAレコード、CNAMEレコード、MXレコード、TXTレコード、NSレコード、SOAレコードなどが記述されます。

これらのレコードによって、次のような情報を管理します。

管理内容	例
WebサーバーのIPアドレス	example.com → 203.0.113.10
サブドメインの向き先	www.example.com → 203.0.113.10
メールサーバー	example.com 宛てのメールを mail.example.com へ配送
ネームサーバー	ns1.example.com、ns2.example.com
メール認証情報	SPF、DKIM、DMARCなど
ゾーン管理情報	SOAレコード、serial、refreshなど

DNSゾーンファイルを理解すると、Webサイト公開、サブドメイン設定、メール設定、サーバー移転、CDN導入、メール認証、SSL/TLS証明書管理などの仕組みが理解しやすくなります。

現在では、DNS管理サービスの画面からレコードを設定するケースも多く、ゾーンファイルを直接編集しないこともあります。

しかし、管理画面で行っている操作の本質は、DNSゾーンファイルに書かれるDNSレコードを追加・変更していることと同じです。

そのため、DNSゾーンファイルの基本を理解しておくことは、ドメイン運用やWebサイト管理において非常に役立ちます。

以上、DNSゾーンファイルについてでした。

最後までお読みいただき、ありがとうございました。