DNSレコード
1. DNSレコードの概要と目的
DNSレコード（DNS Record／リソースレコード）は、ドメイン名に関する設定情報をDNS上に登録するためのデータの単位です。
Webサイトの公開やメールの設定、外部サービスの導入を行う際に、「DNSレコードを追加してください」と案内されることがあります。DNSレコードは、ドメイン名をどのサーバーに結び付けるか、メールをどこで受信するかといった情報を定義し、インターネット上の通信の宛先を決定する役割を担っています。
この章では、DNSレコードがどのようなものなのか、また、なぜ知っておく必要があるのかを確認します。
DNSレコードとは？
DNSレコードとは、DNSの基本仕様（RFC 1034 / RFC 1035）で定義されている「リソースレコード（Resource Record）」のことで、ドメイン名に紐づく各種情報を1件ずつ記述したデータです。
1件のDNSレコードは、次のような要素で構成されています。
www.example.com. 3600 IN A 192.0.2.10
; ↑名前 ↑TTL ↑クラス ↑タイプ ↑値それぞれの要素は、次の意味を持ちます。
- 名前： 設定の対象となるホスト名・ドメイン名。
- TTL： この情報をキャッシュしてよい秒数。
- クラス： 通常はインターネットを表す
INが使われます。 - タイプ： レコードの種類。
AやMXなど、用途ごとに定められています。 - 値： そのレコードが示す実際の内容。
重要なのは、DNSレコードがタイプごとに異なる役割を持つという点です。同じ example.com というドメイン名に対しても、Webサーバーの所在を示すレコード、メールの宛先を示すレコード、所有権の確認用のレコードなどを、それぞれ別のタイプで登録します。
このように、ドメイン名に関するさまざまな情報を、用途別のレコードとして登録・公開する仕組みがDNSレコードです。
DNSレコードはどのような場面で登場するのか？
DNSレコードは、ドメインを取得した直後の初期設定から、日々のサーバー運用まで、幅広い場面で登場します。
例えば、次のような場面が代表的な利用例です。
- Webサイトの公開： ドメイン名をWebサーバーのIPアドレスに結び付け、ブラウザからアクセスできるようにする。
- メールの送受信設定： 受信サーバーを指定し、あわせて送信元の正当性を示す認証情報を登録する。
- 外部サービスの導入： SaaSやCDNとの連携時に、指定されたレコードを追加して独自ドメインで利用できるようにする。
- サーバー移行： 接続先を新しいサーバーへ切り替える。
Web担当者やインフラ担当者にとって、DNSレコードはサービスの到達性を左右する、最も基本的な設定項目の一つです。
2. DNSレコードの仕組み・規格・主な特徴
DNSレコードは、「ゾーン」と呼ばれる管理単位にまとめて登録され、権威DNSサーバーから配信されます。
利用者のパソコンやスマートフォンは、直接このゾーンを読みに行くわけではなく、キャッシュDNSサーバーを経由して必要なレコードを取得します。
ここでは、主なレコードタイプと、実際の記述例を確認します。
主なレコードタイプと役割
実務でよく利用されるDNSレコードには、次のようなものがあります。
- Aレコード： ドメイン名をIPv4アドレスに対応付ける。Webサイトの公開で最も基本となるレコード。
- AAAAレコード： ドメイン名をIPv6アドレスに対応付ける。
- CNAMEレコード： ドメイン名を別のドメイン名の別名として定義する。CDNや外部サービスとの連携で利用される。
- MXレコード： そのドメイン宛のメールを受信するサーバーを指定する。数値の優先度を伴い、値が小さいものほど優先される。
- NSレコード： そのゾーンを管理している権威DNSサーバーを示す。
- TXTレコード： 任意のテキストを登録する。SPFやDKIM、DMARCといったメール認証や、ドメイン所有権の確認に広く使われる。
- SOAレコード： ゾーンの管理情報（管理者情報、シリアル番号、各種の時間設定など）を保持する、ゾーンに必ず1つ存在するレコード。
- PTRレコード： IPアドレスからホスト名を引く「逆引き」に使用される。自分のドメインのゾーンではなく、IPアドレスを割り当てている事業者側のゾーンで管理されるため、設定を希望する場合はサーバー事業者やISPへの依頼が必要になる点に注意。
- SRVレコード： サービスの提供先ホストとポート番号を示す。
- CAAレコード： そのドメインのSSL/TLS証明書を発行してよい認証局を限定する。
なお、かつてはSPF専用のレコードタイプも定義されていましたが、現在は廃止され、SPFはTXTレコードで記述するのが標準です。
名前解決の流れを具体的に追うと、次のようになります。
- クライアントが
www.example.comのAレコードをキャッシュDNSサーバーに問い合わせる。 - キャッシュDNSサーバーが、ルートDNSサーバー、
.comを管理するサーバーへと順に問い合わせ、担当する権威DNSサーバーを特定する。 - 権威DNSサーバーが、登録されているAレコードの値を返す。
- キャッシュDNSサーバーは、その結果をTTLで指定された秒数だけ保持し、クライアントへ返す。
この4の段階でキャッシュが働くため、DNSレコードを変更しても、即座にすべての利用者へ反映されるわけではありません。
ゾーンファイルでの記述
DNSレコードは、ゾーンファイルやDNS管理サービスの画面上で、名前・タイプ・値を指定して登録します。
例えば、次のような記述ができます。
【記述・構造の具体例】
1つのドメインに対して、Web・メール・認証用のレコードをあわせて設定する例です。
$TTL 3600 example.com. IN SOA ns1.example.com. admin.example.com. ( 2026100601 ; シリアル番号 7200 ; リフレッシュ 900 ; リトライ 1209600 ; 期限切れ 3600 ) ; ネガティブキャッシュTTL example.com. IN NS ns1.example.com. example.com. IN NS ns2.example.com. example.com. IN A 192.0.2.10 example.com. IN MX 10 mail.example.com. example.com. IN TXT "v=spf1 include:_spf.example.net ~all" ns1 IN A 192.0.2.1 ns2 IN A 192.0.2.2 www IN CNAME example.com. mail IN A 192.0.2.20
このように、1つのドメインに対して用途の異なる複数のレコードを登録することで、Webアクセスとメールの受信をそれぞれ別のサーバーへ振り分けられます。
なお、この例のようにネームサーバー自身が同じゾーン内のホスト名である場合は、その名前に対するAレコード（ns1・ns2）も忘れずに用意しておく必要があります。名前解決の出発点となるため、これが欠けているとゾーン全体が引けなくなります。
また、ゾーンファイルで参照先のドメイン名を記述する際は、末尾のドット（.）の有無に注意してください。末尾のドットがない場合は相対表記として扱われ、自ドメイン名が補完されます。DNS管理サービスの入力画面では自動的に補完される場合もあるため、保存後に実際の値を確認しておくと確実です。
3. DNSレコードが使われる理由・メリットと活用シーン
DNSレコードが必要とされる理由は、人が扱いやすいドメイン名と、通信に必要なIPアドレスやサーバー情報とを切り離して管理できることにあります。
サーバーを入れ替えてもドメイン名を変えずに済むのは、この仕組みによるものです。
DNSレコードを管理するメリット
もしドメイン名とサーバーの情報が固定的に結び付いていた場合、サーバーを移転するたびに利用者側の設定変更が必要になります。
DNSレコードを適切に管理することで、次のようなメリットが生まれます。
- 構成変更の柔軟性： サーバーを移転・増設しても、レコードの値を書き換えるだけで切り替えが完了する。
- 役割ごとの振り分け： Webは自社サーバー、メールは外部サービス、といった構成を1つのドメインで実現できる。
- サービス連携の標準的な手段： 外部サービスの導入や所有権確認が、レコードの追加という共通の手順で行える。
- 安全性の向上： CAAレコードやメール認証用のTXTレコードによって、なりすましや不正な証明書発行のリスクを抑えられる。
ただし、レコードの設定を誤ると、Webサイトが表示されない、メールが届かないといった形で、サービス全体に影響が及びます。
サイト運用やサービス連携で活用する
実際のサイト運用では、以下のような場面で活用されます。
- 独自ドメインでのサイト公開： ドメイン名をWebサーバーやCDNへ向ける。
- メール環境の構築： 受信サーバーをMXレコードで指定し、SPF・DKIM・DMARCをTXTレコードで設定する。
- サブドメインの振り分け：
blogやshopなどを、それぞれ別のサービスへ割り当てる。 - 証明書の取得・更新： 認証局によるドメイン所有権の確認を、指定されたレコードの登録によって行う。
このように、ドメインを基点とした各種サービスの設定は、ほぼすべてDNSレコードを介して行われます。
DNSレコードの検索・確認方法
設定したDNSレコードが正しく登録・反映されているかは、コマンドやWeb上のツールで検索できます。
# タイプを指定してDNSレコードを検索する
dig example.com A +short
dig example.com MX +short
dig example.com TXT +short
# nslookupコマンドで検索する（Windowsなど）
nslookup -type=mx example.com
# 権威DNSサーバーへ直接問い合わせ、反映状況を確認する
dig @ns1.example.com example.com NSDNSレコードの検索は、タイプを指定して1つずつ問い合わせるのが基本です。かつては ANY を指定してすべてのレコードをまとめて取得する方法が使われていましたが、現在は多くの権威DNSサーバーがこの問い合わせに対して完全な一覧を返さないため、結果が空に見えても設定が存在しないとは限りません。
また、通常の問い合わせでは、経路上のキャッシュDNSサーバーが保持している古い情報が返る場合があります。設定変更の直後に確認したい場合は、権威DNSサーバーを指定して問い合わせると、実際に登録されている内容を確かめられます。
Web上の確認ツールを利用すれば、コマンドを使わずに主要なレコードタイプをまとめて検索できます。設定ミスなのか反映待ちなのかを切り分ける際にも有効です。
関連技術・関連用語との違い
DNSレコードと混同されやすい関連用語として、次のようなものがあります。
- ゾーン／ゾーンファイル： DNSレコードをまとめて管理する単位、およびその内容を記述したファイル。レコードが「1件のデータ」であるのに対し、ゾーンは「その集合と管理範囲」を指す。
- ネームサーバー（権威DNSサーバー）： DNSレコードを実際に保持し、問い合わせに応答するサーバー。ドメイン登録業者側で「どのネームサーバーを使うか」を指定したうえで、そのネームサーバー上でレコードを設定するという二段構えになっている。
- hostsファイル： 各端末内に置かれる名前解決用のファイル。通常はDNSより優先されるため、DNSレコードを正しく設定していても、端末側の記述が残っていると意図しない宛先へ接続される。
特に混乱しやすいのが、ネームサーバーの指定とレコードの設定が別々の場所で行われる点です。
ドメイン登録業者で指定したネームサーバーと、実際にレコードを編集しているDNSサービスが一致していないと、編集した内容はいつまでも反映されません。
4. DNSレコードの導入・運用時の注意点と課題
DNSレコードは影響範囲が広く、1件の設定ミスがサイトの全面停止やメールの不達につながることがあります。
また、設定内容はインターネット上に公開される情報であるため、記載する内容にも配慮が必要です。
ここでは、実務上注意すべきポイントを説明します。
よくあるミス・設定ミス
よくある問題の一つが、変更が即座に反映されると思い込んでしまうことです。
DNSレコードはTTLで指定された秒数のあいだキャッシュされるため、変更直後は古い情報が返り続けます。切り替え作業を行う場合は、事前にTTLを短く設定しておくと、反映までの時間を短縮できます。
また、次のようなミスも頻出します。
- 編集先のDNSサービスの取り違え： ドメイン登録業者で指定しているネームサーバーと、レコードを編集している管理画面が一致しておらず、変更が反映されない。
- CNAMEとの共存： CNAMEを設定した名前には、他のレコードを併設できません。
- MXの優先度の誤解： 数値が小さいものほど優先されます。大きい値を優先と誤解すると、意図しないサーバーへ配送されます。
- ワイルドカードの影響範囲：
*を使ったレコードは、個別に定義していないすべてのサブドメインに適用されるため、意図しない名前まで応答するようになります（個別に定義済みの名前には適用されません）。 - 末尾のドットの付け忘れ： 相対表記として扱われ、自ドメイン名が余分に付加されてしまう。
運用・セキュリティ上の注意点
設定内容の誤りのなかでも、特に気づきにくいのがメール認証用のTXTレコードです。SPFは、1つのドメインに対して1件のみ有効であると定められており、複数登録するとエラーとして扱われ、認証そのものが失敗します。
【よくある失敗・注意点の例】
サービスを追加した際に、SPFレコードを新たに1件追加してしまい、重複している例です。
; 悪い例：SPFのTXTレコードが2件登録されている example.com. IN TXT "v=spf1 include:_spf.example.net ~all" example.com. IN TXT "v=spf1 include:_spf.another.jp ~all" ; 正しい例：1件のレコードにまとめて記述する example.com. IN TXT "v=spf1 include:_spf.example.net include:_spf.another.jp ~all"
この例では、受信側のサーバーがどちらを採用すべきか判断できず、SPFの評価がエラーとなります。メールが迷惑メール扱いされたり、受信を拒否されたりする原因になるため、送信サービスを追加した際は既存のレコードに追記する形で設定してください。
ただし、include を増やす際にも上限がある点に注意が必要です。SPFの評価では、include などによって発生するDNS問い合わせの回数が10回までと定められており、これを超えるとやはりエラーとなります。送信サービスを次々に追加していくと超過しやすいため、利用していないサービスの記述は忘れずに削除してください。
そのほか、運用面では次の点にも注意が必要です。
- 不要なレコードの放置： 利用を終了した外部サービスへ向けたレコードを残すと、第三者に同じ参照先を取得され、自ドメインのサブドメインが乗っ取られる「サブドメインテイクオーバー」のリスクがあります。
- 公開情報であることの意識： DNSレコードの内容は誰でも検索できます。社内システムのホスト名や構成が推測できるような情報を、不用意に登録しないようにします。
- 改ざん・なりすましへの対策： 経路上での応答の偽装に備える仕組みとしてDNSSECがあります。また、CAAレコードを設定しておくと、意図しない認証局による証明書発行を抑止できます。
安全に利用するための対策
DNSレコードを適切に運用するためには、以下の対策が有効です。
- 変更作業の前にTTLを短くし、切り替え後に意図した値が返るかを確認したうえで元に戻す。
- 編集前に、ドメイン登録業者で指定しているネームサーバーと、編集中の管理画面が一致しているかを確認する。
- SPFは必ず1件にまとめ、送信サービスを追加・解約した際にあわせて見直す。
- 使われていないレコードが残っていないか、定期的に棚卸しする。
- 変更前の設定内容を記録しておき、問題が起きた際にすぐ戻せるようにする。
- 設定後は
digやnslookup、確認ツールなどで、実際に返される値を必ず検証する。
特に、メールに関わるレコードは不具合に気づくまで時間がかかりやすいため、変更後はテスト送信を行い、認証結果まで確認しておくことが重要です。
5. まとめと関連ツールのご案内
ここまで解説したDNSレコードについて、重要なポイントを振り返ります。
DNSレコードは、ドメイン名に関する設定情報をDNS上に登録するデータの単位である。- 名前・TTL・クラス・タイプ・値で構成され、タイプごとに異なる役割を持つ。
- A・AAAA・CNAME・MX・NS・TXT・SOAなどが、実務でよく使われる主要なレコードタイプである。
- TTLによるキャッシュが働くため、変更が即座に全体へ反映されるわけではない。
- SPFは1件のみ有効で、重複して登録すると認証が失敗する。また、DNS問い合わせの回数にも上限がある。
- 内容は公開情報であり、不要なレコードの放置はサブドメインテイクオーバーのリスクにつながる。
- 設定後はタイプを指定して検索し、実際に返される値を必ず検証する。
【お役立ちツールのご案内】
ここまで解説したDNSレコードの設定内容を実際に検索・確認したい場合は、当サイトの DNSレコード確認ツール をぜひご活用ください。
ドメイン名を入力するだけで、A・CNAME・MX・TXT・NSといった主要なDNSレコードをまとめて検索できます。設定変更後の反映状況のチェックや、意図しないレコードが残っていないかの確認にお役立てください。