はじめに
DNSレコード、触ったことある人なら「なんかいっぱい種類あってよくわからん」って思ったことありますよね。
DNSレコードとは、ドメインのふるまいを決める設定書です。
より正確に言えば、権威DNSが「このドメインはこう振る舞え」と世界に宣言する公式情報です。
「example.comにアクセスしたらどのサーバーに繋ぐか」「メールはどこに送るか」「このドメインは誰が管理してるか」——こうした動作をすべてDNSレコードが制御しています。
よく「DNSはドメインをIPアドレスに変換するもの」と説明されますが、それは機能の一部に過ぎません。実際には、メール配送、認証、委譲、別名設定など、ドメインに関わるあらゆる指示をDNSレコードが担っています。
この記事では、DNSレコードの本質から主要な種類、実務での使い方、そしてよくある失敗まで、厳しく・実用的に解説します。記事の内容はRFC（Request for Comments）をベースにしています。
DNSレコードが果たす役割
DNSレコードは以下のような役割を果たします:
- 名前解決: ドメイン名をIPアドレスに変換
- ルーティング指定: トラフィックをどのサーバーに向けるか指定（※DNSはトラフィックを流したり中継したりはしません。どこへ行くかを決めるだけです）
- メール配送: メールサーバーの宛先を定義
- 認証・証明: SPFやDKIMなどの認証情報を保持
- サブドメイン管理: 権限の委譲や別名の設定
DNSレコードとゾーンファイル
DNSレコードはDNSゾーンに格納されます。ゾーンは権威DNSサーバーが管理する「設定データベース」のようなもので、実体はゾーンファイルという形式で記述されます。
$TTL 3600
$ORIGIN example.com.
@ IN SOA ns1.example.com. admin.example.com. (
2024010101 7200 3600 1209600 3600 )
@ IN NS ns1.cloudflare.com.
@ IN NS ns2.cloudflare.com.
@ IN A 203.0.113.10
www IN CNAME @
mail IN A 203.0.113.20
@ IN MX 10 mail.example.com.
この「ゾーンファイル形式」がDNSレコードの正体です。実務ではCloudflareやRoute53などの管理画面で設定しますが、裏側ではこの形式に変換されています
DNS問い合わせの流れ
TTL（Time To Live）の重要性
DNSにはキャッシュ機構があります。毎回権威DNSに問い合わせていたら遅くなるため、リゾルバは一定時間結果をキャッシュします。この「一定時間」がTTL（Time To Live）です。
TTLの推奨値:
| 用途 | TTL | 理由 |
|---|---|---|
| 通常運用 | 3,600秒（1時間） | 変更頻度と鮮度のバランス |
| サーバー移行前 | 300秒（5分） | 変更を素早く反映させる |
| CDN利用時（Cloudflare） | Auto推奨 | CDN側で最適化される |
| 変更頻度が高い | 600〜1,800秒 | 柔軟に対応 |
| ほぼ変更しない | 86,400秒（1日） | キャッシュ効率最大化 |
TTLを長くするメリット:
- DNSクエリ数が減り、サーバー負荷が下がる
- 名前解決が高速化
TTLを短くするメリット:
- 変更が素早く反映される
- 障害時の切り替えが迅速
このように、クライアントのリクエストに対して、DNSレコードが返す値によって接続先が決まります。
主要DNSレコード（必須級）
実務で絶対に押さえておくべきレコードを解説します。
Aレコード
IPv4アドレスへの変換を行う、最も基本的なレコードです。
- Webサイトへのアクセスで最も頻繁に使われる
- 1つのドメインに複数のAレコードを設定すると、ラウンドロビンでアクセスが分散される
example.com. A 203.0.113.10
AAAAレコード（クアッドエー）
IPv6アドレスへの変換を行います。
- IPv6対応が必要な場合に設定
- Aレコードと併用するのが一般的
example.com. AAAA 2001:db8::1
CNAMEレコード
別名（エイリアス） を定義します。
-
www.example.comをexample.comの別名として設定する、といった用途 - 重要な制約: ルートドメイン（example.com）には設定できない
- CNAMEを設定すると、他のレコード（A、MXなど）と共存できない
www.example.com. CNAME example.com.
CNAME解決の流れ
CNAMEは「別名」なので、実際のIPアドレスを得るには2段階の問い合わせが必要です:
この2段階解決があるため、CNAMEは若干遅延が発生します（通常は無視できるレベルですが、大量アクセス時は積み重なる可能性があります）。
ルートドメインのCNAME問題を解決する方法
DNS仕様上、ルートドメイン（example.com）にはCNAMEを設定できません。しかし、CDNやホスティングサービスを使う際に「ルートドメインをCNAMEで指定したい」場面があります。
解決策:
| DNS プロバイダー | 機能名 | 説明 |
|---|---|---|
| Cloudflare | CNAME Flattening | 自動的にAレコードに変換 |
| AWS Route53 | ALIAS レコード | CNAMEライクだがAとして振る舞う |
| DNSimple | ANAME レコード | 同上 |
これらの機能を使えば、実質的にルートドメインでもCNAMEのような動作が可能です。
MXレコード
メール配送先を指定します。
- 優先度（プリファレンス値）を指定可能
- 数字が小さいほど優先度が高い（10より5が優先）
example.com. MX 10 mail.example.com.
example.com. MX 20 backup-mail.example.com.
メール配送の流れ
MXレコードも2段階で解決されます:
重要: MXレコードが指す先（mail.example.com）には必ずAレコードが必要です。CNAMEは推奨されません。
TXTレコード
テキスト情報を格納する汎用レコードです。
- SPF（送信元認証）
- DKIM（電子署名）
- ドメイン所有確認（Google Search Consoleなど）
- その他の認証・設定情報
example.com. TXT "v=spf1 include:_spf.google.com ~all"
example.com. TXT "google-site-verification=xxxxx"
実用例
実際の設定例を見てみましょう:
example.com. A 203.0.113.10
www.example.com. CNAME example.com.
mail.example.com. A 203.0.113.20
example.com. MX 10 mail.example.com.
example.com. TXT "v=spf1 mx ~all"
時々使うが重要なレコード
現場で触れる確率が高い順に解説します。
NSレコード
権威DNSサーバーを指定し、ドメインやサブドメインの管理を委譲します。
- ドメイン登録時に必ず設定される
- サブドメインを別のDNSサーバーで管理する際にも使用
example.com. NS ns1.cloudflare.com.
example.com. NS ns2.cloudflare.com.
sub.example.com. NS ns1.subdomain-host.com.
SRVレコード
特定のサービスの接続先を定義します。
- Minecraft、SIP、XMPPなどで使用
- プロトコル、ポート番号、優先度、重み、ホスト名を指定
- クライアント側がSRVに対応している必要がある
_minecraft._tcp.example.com. SRV 0 5 25565 mc.example.com.
SRVレコードの構造:
_service._proto.name. TTL class SRV priority weight port target.
実用例:
| サービス | SRVレコード | 用途 |
|---|---|---|
| Minecraft | _minecraft._tcp.domain |
サーバー接続 |
| SIP | _sip._tcp.domain |
VoIP通話 |
| LDAP | _ldap._tcp.domain |
ディレクトリサービス |
| XMPP | _xmpp-client._tcp.domain |
チャット |
SRVレコードを使うと、ポート番号をURLに含めなくても接続できるようになります。
CAAレコード
SSL/TLS証明書の発行権限を制限します。
- 指定した認証局（CA）のみが証明書を発行可能
- フィッシング対策やセキュリティ強化に有効
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild ";"
PTRレコード
逆引き（IPアドレスからドメイン名） を定義します。
- メールサーバーの信頼性確認で重要
- スパム判定を避けるために設定必須
10.113.0.203.in-addr.arpa. PTR mail.example.com.
SOAレコード
ゾーン情報を保持します。
- プライマリDNSサーバー
- 管理者のメールアドレス
- シリアル番号、更新間隔、有効期限など
通常、DNSプロバイダーが自動で設定するため、手動での変更は稀です。
example.com. SOA ns1.example.com. admin.example.com. (
2024010101 ; シリアル
7200 ; リフレッシュ
3600 ; リトライ
1209600 ; 期限
3600 ) ; ネガティブキャッシュTTL
DNSSEC関連レコード
DNSSEC（DNS Security Extensions） は、DNSの応答が改ざんされていないことを暗号的に保証する仕組みです。
主なレコード:
- DS（Delegation Signer）: 子ゾーンの公開鍵のハッシュ
- DNSKEY: 公開鍵本体
- RRSIG: デジタル署名
example.com. DS 12345 8 2 AABBCCDD...
DNSSECを有効化すると、なりすましやキャッシュポイズニング攻撃を防げますが、設定ミスでドメイン全体がアクセス不可になるリスクもあります。詳細は別記事で解説しますが、セキュリティ要件が高い場合は導入を検討しましょう。
実例: 1つのドメインを構成するレコード一覧
実際のドメイン（example.com）の設定例を見てみましょう:
; Webサイト
example.com. A 203.0.113.10
www.example.com. CNAME example.com.
; メール
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
; 認証
example.com. TXT "v=spf1 mx ip4:203.0.113.20 ~all"
default._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
; DNS管理
example.com. NS ns1.cloudflare.com.
example.com. NS ns2.cloudflare.com.
これを図で表すと、以下のようになります:
1つのドメインに複数のレコードが設定され、それぞれが異なる役割を果たしていることが分かります。
よくある失敗と落とし穴
実務でよくやらかす失敗を挙げていきます。
1. CNAMEをルートドメインに置いてしまう
ダメな例:
example.com. CNAME hosting-provider.com.
ルートドメイン（example.comそのもの）にCNAMEを設定することはDNS仕様上できません。SOAやNSレコードと競合するためです。
正しい方法:
- Aレコードを使う
- ALIAS/ANAMEレコード（一部DNSプロバイダー提供）を使う
2. TTLを短くせずにサーバー移行してしまう
TTL（Time To Live）は、DNSレコードのキャッシュ時間です。
移行前にTTLを短く（300秒=5分など）設定しておかないと、古いIPアドレスが長時間キャッシュされ、サイトにアクセスできないユーザーが出ます。
移行手順:
- 数日前にTTLを短く設定（例: 300秒）
- 移行作業を実施
- 移行完了後、TTLを元に戻す（例: 3600秒）
3. MXレコードの優先度を逆に理解している
MXレコードの優先度は数字が小さい方が優先度が高いです。
example.com. MX 10 primary-mail.example.com.
example.com. MX 20 backup-mail.example.com.
この場合、10のprimary-mailが優先されます。
4. 複数のAレコードでラウンドロビンになることを知らない
同じ名前に複数のAレコードを設定すると、アクセスが分散されます。
example.com. A 203.0.113.10
example.com. A 203.0.113.11
これは簡易的な負荷分散として使えますが、故障検知やセッション維持の機能はありません。本格的な負荷分散にはロードバランサーを使いましょう。
5. TXTレコードは複数行にできることを知らない
長いTXTレコード（特にDKIMキー）は1行に収まらない場合があります。ほとんどのDNS管理画面では、複数の文字列として記載しても問題なく、自動的に結合されて1つの文字列として扱われます。
default._domainkey.example.com. TXT (
"v=DKIM1; k=rsa; "
"p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ..."
)
DNSプロバイダーによっては自動で分割してくれますが、手動設定の場合は注意が必要です。
6. MXレコードの先にAレコードを設定し忘れる
これは実務で本当によくあるミスです。
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20 ← これを忘れる！
MXレコードは「メールサーバーのホスト名」を指定するだけで、そのホスト名のIPアドレスは別途Aレコードで定義する必要があります。
間違った設定:
example.com. MX 10 mail.example.com.
; mail.example.comのAレコードがない → メールが届かない
正しい設定:
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
7. CNAMEをMX先に使ってしまう
MXレコードのターゲット（宛先）がCNAMEだと、動作しない、もしくは非推奨とされています。これはRFC 2181で明確に禁止されています。
ダメな例:
example.com. MX 10 mail.example.com.
mail.example.com. CNAME mail-backend.example.net.
正しい例:
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.20
理由:
- メール配送の信頼性に影響
- 一部のメールサーバーがCNAMEを正しく解決できない
- RFC違反のため、将来的に完全に動作しなくなる可能性
MXのポイント先には必ずAレコード（またはAAAA） を使いましょう。
8. DNSSECを適当にオンにしてドメイン全落ち
DNSSECの設定ミスで有効期限切れや鍵不一致を起こすと、権威DNS応答が「改ざんされたもの」と見なされ、ドメイン全体が名前解決不能になります。
よくある事故:
- 管理者が理解せずにオンにする
- レジストラ側でDS設定を忘れる
- 鍵のロールオーバー（更新）に失敗する
- 有効期限切れに気づかない
結果:
- Webサイトが完全にアクセス不可
- メールが全て不達
- 復旧に数時間〜数日かかる
対策:
- DNSSECを有効化する前に仕組みを理解する
- 監視ツールで有効期限を追跡する
- ロールオーバー手順を事前に確認する
- テストドメインで試してから本番適用
DNSSECはセキュリティを大幅に向上させますが、運用リスクも高いため、慎重に導入しましょう。
Cloudflare等のDNS管理画面での例
実務では、DNS管理画面で設定を行います。Cloudflareを例に見てみましょう。
基本的な設定項目
| 項目 | 説明 |
|---|---|
| Type | レコードタイプ（A、AAAA、CNAME、MXなど） |
| Name | ホスト名（@はルートドメイン、wwwはサブドメイン） |
| Content | 値（IPアドレス、ドメイン名など） |
| TTL | キャッシュ時間（Auto、または秒数） |
| Proxy status | Cloudflareのプロキシを通すかどうか |
Proxy status（オレンジ雲/グレー雲）
Cloudflareには独自の機能があります:
-
オレンジ雲（Proxied）: CloudflareのCDN・WAFを経由してアクセス
- DDoS保護、キャッシュ、SSL/TLSなどの機能が有効
- 実際のサーバーIPアドレスが隠蔽される
-
グレー雲（DNS only）: 通常のDNS動作
- Cloudflareを経由せず、直接サーバーにアクセス
- 実際のIPアドレスが公開される
注意: MXレコードやTXTレコードなど、A/AAAA以外のレコードはProxyを使えません。
実際の設定例
Type: A Name: @ Content: 203.0.113.10 Proxy: オレンジ雲
Type: A Name: www Content: 203.0.113.10 Proxy: オレンジ雲
Type: A Name: mail Content: 203.0.113.20 Proxy: グレー雲
Type: MX Name: @ Content: mail.example.com Priority: 10
Type: TXT Name: @ Content: v=spf1 mx ~all
まとめ：DNSレコードの本質
DNSレコードはただの「IP変換装置」ではありません。
DNSレコードが担う役割:
- Webの向き先を決める
- メール配送を制御する
- 認証とセキュリティを担保する
- サブドメイン管理を委譲する
- インフラ構成全体の設計に関係する
つまり、DNSレコードはドメインの仕様書そのものです。
特に押さえるべきレコード
必須級（これだけは絶対）:
- A / AAAA: IPv4/IPv6アドレス変換
- CNAME: 別名設定
- MX: メール配送先
- TXT: 認証情報（SPF/DKIM）
重要級（用途に応じて）:
- NS: DNS権限委譲
- SRV: サービス定義
- CAA: 証明書発行制限
- PTR: 逆引き
覚えておくべき鉄則
- CNAMEはルートドメインに設定できない
- MX先はA/AAAAレコード必須（CNAMEは不可）
- TTLは用途に応じて調整（移行時は短く）
- DNSSECは理解してから有効化（全落ちリスクあり）
- 変更前にTTLを短縮（移行を円滑に）
- MX優先度は数字が小さい方が優先
- 複数Aレコード＝ラウンドロビン（簡易負荷分散）
この記事で達成できること
この記事を読み終えた人が：
✅ DNSレコードの種類と役割を理解できる
✅ 運用で使う主要レコードを選べる
✅ 変更・移行時に失敗を避けられる
✅ セキュリティ面も意識できる
✅ トラブル時に原因を切り分けられる
これらができれば、DNSレコードの基礎は完璧です。
次のステップ
さらに深く学びたい方は、以下のトピックを探求してみてください:
- SPF/DKIM/DMARC深掘り: メール認証の完全ガイド
- CNAME Flattening/ALIAS比較: ルートドメインCNAME問題の各社対応
- DNSSEC実運用: 鍵管理とロールオーバー手順
- DNS障害と可用性: TTL、キャッシュ、冗長化の実践
- メール配送の仕組み: MX、SPF、DKIM、DMARCの連携
これらを習得すれば、DNSマスターへの道が開けます。
DNSレコードは地味な存在ですが、インターネットインフラの根幹を支える重要な技術です。正しく理解し、適切に運用することで、安定したサービス提供が可能になります。
設定を変える前には必ず確認し、テスト環境で検証し、万が一に備えてバックアップを取る。 これがDNS運用の基本です。
この記事が、あなたのDNS運用の一助となれば幸いです。
DNSレコードを間違えると、Webサイトにアクセスできなくなったり、メールが届かなくなったりします。 設定変更の際は必ず内容を確認し、可能であればテスト環境で事前検証を行いましょう。
DNSレコード設定チェックリスト
実務でDNSレコードを設定・変更する際に確認すべき項目をまとめました。
基本確認項目
- Aレコード: IPアドレスは正しいか？（誤字・脱字チェック）
- AAAAレコード: IPv6アドレスは正しいか？
- CNAMEレコード: ルートドメインに設定していないか？
- CNAMEレコード: 同じ名前に他のレコード（A、MXなど）が存在しないか？
- MXレコード: 優先度は正しいか？（小さい数字が優先）
- MXレコード: 指定したホスト名にAレコードが設定されているか？
- TXTレコード: SPF/DKIMの構文は正しいか？（v=spf1の記述ミス等）
- TTL: 変更予定がある場合、事前に短く設定したか？（推奨: 300秒）
メール関連の特別チェック
- MXレコードの先がCNAMEになっていないか？（Aレコード必須）
- PTRレコード（逆引き）は設定されているか？（スパム判定回避）
- SPFレコードは正しく設定されているか？
- DKIMレコードは正しく設定されているか？
セキュリティ関連
- CAAレコードで証明書発行元を制限しているか？
- DNSSECを有効化する場合、設定は正しいか？
サーバー移行時
- 移行前にTTLを300秒程度に短縮したか？
- 新旧両方のサーバーが稼働しているか？
- 移行完了後、TTLを元の値（3600秒等）に戻したか？
確認方法
設定後は以下のコマンドで確認できます:
# Aレコードの確認
dig example.com A
# MXレコードの確認
dig example.com MX
# TXTレコードの確認
dig example.com TXT
# 特定のレコードタイプを指定して確認
dig example.com NS
dig example.com AAAA
注意: dig example.com ANY で全レコードを取得しようとしても、CloudflareやGoogle Public DNSなどの近年のDNSサーバーでは制限されており、すべてのレコードが返らない場合があります。実務ではレコードタイプを明示して確認するのが基本です。
または、オンラインツール（MXToolbox、DNSChecker等）を使って世界中のDNSサーバーから見えているか確認しましょう。
この記事が、DNSレコードの理解と実務での活用に役立てば幸いです。