今回は、DNS運用において必須の知識となるDNSレコードタイプについて、各レコードの役割と用途を詳しく解説します。
DNSの基本的な知識はあるものの、各レコードタイプの具体的な使い分けや実務での活用方法に不安を感じている方に向けて、実践的な内容をまとめました。この記事を読むことで、各DNSレコードの特性を理解し、適切なレコード設定ができるようになります。
DNSレコードとは
DNSレコードは、ドメイン名とそれに関連する情報を紐付けるデータベースのエントリです。DNSサーバーは、これらのレコードを参照してドメイン名の解決やメールの配送先決定など、様々な情報提供を行います。各レコードタイプは特定の目的に特化しており、適切なレコードを設定することでドメインが正しく機能します。
DNSレコードは、DNSゾーンファイル内に記述され、各レコードには以下の共通要素があります。
- 名前（Name）: ドメイン名またはホスト名
- TTL（Time To Live）: キャッシュの有効期間（秒単位）
- クラス（Class）: 通常はIN（インターネット）
- タイプ（Type）: レコードの種類
- データ（RDATA）: レコードタイプに応じた具体的な値
DNSレコードタイプ一覧表
実務でよく使用されるDNSレコードタイプを一覧にまとめました。各レコードの基本的な役割を把握しましょう。
| レコードタイプ | 正式名称 | 主な用途 | 重要度 |
|---|---|---|---|
| A | Address Record | ドメイン名をIPv4アドレスに変換 | ★★★ |
| AAAA | IPv6 Address Record | ドメイン名をIPv6アドレスに変換 | ★★★ |
| CNAME | Canonical Name Record | ドメイン名のエイリアス設定 | ★★★ |
| MX | Mail Exchange Record | メールサーバーの指定 | ★★★ |
| TXT | Text Record | テキスト情報の格納（SPF、DKIM等） | ★★★ |
| NS | Name Server Record | 権威DNSサーバーの指定 | ★★★ |
| SOA | Start of Authority Record | ゾーン情報の管理 | ★★★ |
| PTR | Pointer Record | IPアドレスからドメイン名への逆引き | ★★☆ |
| SRV | Service Record | サービスの位置情報 | ★★☆ |
| CAA | Certification Authority Authorization | SSL証明書発行機関の制限 | ★★☆ |
各DNSレコードタイプの詳細解説
ここからは、各レコードタイプの役割、用途、実務での使用シーンを詳しく解説していきます。
Aレコード（Address Record）
役割と用途:
Aレコードは、DNSの最も基本的なレコードタイプで、ドメイン名をIPv4アドレス（32ビット）に変換する役割を持ちます。Webサイトにアクセスする際、ブラウザはまずこのAレコードを参照してサーバーのIPアドレスを取得します。
設定例:
example.com. 3600 IN A 192.0.2.1
www.example.com. 3600 IN A 192.0.2.1
実務での使用シーン:
- Webサーバーへのアクセス
- アプリケーションサーバーの名前解決
- APIエンドポイントの設定
- ロードバランサーのフロントエンド設定
よくある設定ミスと注意点:
- 同一ホスト名に対してAレコードとCNAMEレコードを同時に設定することはできません
- IPアドレス変更時にTTL値が大きいと、変更が反映されるまで時間がかかるため、事前にTTLを短縮しておくことが推奨されます
- 複数のAレコードを設定すると、ラウンドロビン方式でアクセスが分散されますが、障害時の自動切り替えは行われません
AAAAレコード（IPv6 Address Record）
役割と用途:
AAAAレコード（クアッドエーレコード）は、ドメイン名をIPv6アドレス（128ビット）に変換する役割を持ちます。IPv6の普及に伴い、Aレコードと併用して設定することが一般的になっています。
設定例:
example.com. 3600 IN AAAA 2001:db8::1
www.example.com. 3600 IN AAAA 2001:db8::1
実務での使用シーン:
- IPv6対応のWebサーバー設定
- モバイルキャリアのIPv6ネットワークからのアクセス対応
- 大規模サービスでのIPアドレス枯渇対策
- 次世代インターネット対応
よくある設定ミスと注意点:
- AレコードとAAAAレコードの両方を設定する場合、両方のIPアドレスで同じコンテンツが提供されることを確認してください
- IPv6未対応のネットワーク環境では、AAAAレコードが優先されてアクセスできなくなる可能性があります
- ファイアウォールやロードバランサーがIPv6に対応しているか確認が必要です
CNAMEレコード（Canonical Name Record）
役割と用途:
CNAMEレコードは、あるドメイン名を別のドメイン名のエイリアス（別名）として設定するレコードです。実際のIPアドレスはエイリアス先のAレコードまたはAAAAレコードで管理されます。
設定例:
www.example.com. 3600 IN CNAME server01.example.com.
ftp.example.com. 3600 IN CNAME server01.example.com.
server01.example.com. 3600 IN A 192.0.2.1
実務での使用シーン:
- 複数のサブドメインを1つのサーバーに集約
- CDN（Content Delivery Network）サービスの利用
- ロードバランサーのエイリアス設定
- サーバー移行時の柔軟な切り替え
よくある設定ミスと注意点:
- ゾーンのAPEX（example.comそのもの）にCNAMEレコードは設定できません
- CNAMEレコードを設定したホスト名には、他のレコードタイプ（A、MX、TXTなど）を同時に設定できません
- CNAME chainを深くしすぎると名前解決に時間がかかり、パフォーマンスが低下します
- メールサーバー（MXレコード）の宛先としてCNAMEを指定することは推奨されません
MXレコード（Mail Exchange Record）
役割と用途:
MXレコードは、そのドメイン宛のメールを受信するメールサーバーを指定するレコードです。郵便に例えると、MXレコードは「このドメイン宛の手紙（メール）はこの郵便局（メールサーバー）に配達してください」という配達先の指示書のような役割を果たします。
優先度（Priority）を設定でき、複数のメールサーバーを指定して冗長化することができます。これは、メインの郵便局が閉まっているときに配達する予備の郵便局を指定しておくイメージです。
設定例:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.
mail1.example.com. 3600 IN A 192.0.2.10
mail2.example.com. 3600 IN A 192.0.2.11
実務での使用シーン:
- 独自ドメインでのメール受信設定
- メールサーバーの冗長化構成
- Google Workspace、Microsoft 365などのクラウドメールサービス利用
- メールサーバーの段階的な移行
よくある設定ミスと注意点:
- MXレコードの値（メールサーバー名）は必ずAレコードまたはAAAAレコードで解決できる必要があり、CNAMEは使用できません
- 優先度の数値が小さいほど優先度が高くなります（10が20より優先）
- 同じ優先度の複数サーバーを設定した場合、ランダムに選択されます
- MXレコードを変更した際は、古いメールサーバーもしばらく稼働させておく必要があります（TTL + αの期間）
TXTレコード（Text Record）
役割と用途:
TXTレコードは、ドメインに関する任意のテキスト情報を格納するレコードです。これは、ドメインに付箋（メモ）を貼り付けておくようなイメージです。様々な用途に使用できる汎用的なレコードで、主にドメインの所有権確認や、メール認証技術で使用されます。
具体的には、SPF（Sender Policy Framework：「このドメインからメールを送信できるのはこれらのサーバーだけです」という宣言）、DKIM（DomainKeys Identified Mail：メールに電子署名を付けて本物であることを証明）、DMARC（Domain-based Message Authentication, Reporting & Conformance：SPFとDKIMの認証結果をどう扱うかのポリシー設定）などのメール認証技術で重要な役割を果たします。
これらは、メールが本当にそのドメインから送信されたものであることを証明する「身分証明書」のような働きをします。
設定例:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. 3600 IN TXT "google-site-verification=xxxxxxxxxx"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
実務での使用シーン:
- SPFレコード設定によるメール送信元の認証
- DKIM設定による電子署名の検証
- DMARC設定によるなりすましメール対策
- ドメイン所有権の確認（Google Search Console、SSL証明書発行等）
- サービス連携の認証情報格納
よくある設定ミスと注意点:
- TXTレコードの値は必ずダブルクォーテーション（”）で囲む必要があります
- 1つのTXTレコードは255文字以内に制限されていますが、複数の文字列を連結することで長い値を設定できます
- SPFレコードに含めるDNSルックアップは10回以内に制限されています（includeやa、mxなどがカウント対象）
- 同じホスト名に複数のTXTレコードを設定できますが、用途ごとに整理して管理することが重要です
NSレコード（Name Server Record）
役割と用途:
NSレコードは、そのドメインまたはサブドメインの権威DNSサーバー（ネームサーバー）を指定するレコードです。
図書館に例えると、NSレコードは「このドメインに関する情報（本）はこの図書館（DNSサーバー）に保管されています」という案内看板のような役割を果たします。インターネット上で誰かがあなたのドメイン情報を知りたいとき、NSレコードが「情報はここにありますよ」と正しい管理サーバーを教えてくれるのです。
複数のNSレコードを設定することで、メインの図書館が閉館していても、別の図書館（バックアップDNSサーバー）で情報を提供できるようになります。
設定例:
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
subdomain.example.com. 3600 IN NS ns1.subdomain.example.com.
ns1.example.com. 3600 IN A 192.0.2.20
ns2.example.com. 3600 IN A 192.0.2.21
実務での使用シーン:
- ドメインの権威DNSサーバーの指定
- サブドメインの委譲（子ゾーンの管理を別のDNSサーバーに委譲）
- DNSサーバーの冗長化構成
- マルチクラウド環境でのDNS管理
よくある設定ミスと注意点:
- NSレコードで指定したネームサーバーは、ドメインレジストラ側でも同じように設定する必要があります
- 最低2つ以上のネームサーバーを設定することが推奨されます（冗長化のため）
- NSレコードで指定するサーバー名は、必ずAレコードまたはAAAAレコードで解決できる必要があります
- サブドメインにNSレコードを設定する場合、親ゾーンと子ゾーンの両方で設定が必要です
SOAレコード（Start of Authority Record）
役割と用途:
SOAレコードは、DNSゾーンの管理情報を定義する特別なレコードです。各ゾーンに必ず1つだけ存在し、ゾーンの管理者情報、シリアル番号、更新間隔などの重要なパラメータを含んでいます。
マンションの管理規約に例えると、SOAレコードは「この建物（ドメイン）の管理人は誰で、いつ点検して、どのくらいの頻度で情報を更新するか」といった基本ルールを記載した台帳のようなものです。
特にシリアル番号は、ゾーンファイルの「版番号」として機能し、この番号が変わることで「情報が更新されたので確認してください」という合図になります。これは、書類の改訂履歴のようなイメージです。
設定例:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2024112801 ; Serial（シリアル番号）
3600 ; Refresh（更新間隔）
1800 ; Retry（再試行間隔）
604800 ; Expire（有効期限）
86400 ) ; Minimum TTL（最小TTL）
実務での使用シーン:
- DNSゾーンの基本設定
- セカンダリDNSサーバーへのゾーン転送制御
- DNSゾーンの更新管理
- トラブルシューティング時のゾーン情報確認
よくある設定ミスと注意点:
- シリアル番号は、ゾーン更新のたびに増加させる必要があります（通常はYYYYMMDDNN形式を使用）
- シリアル番号を誤って減少させると、セカンダリサーバーがゾーン転送を行わなくなります
- Refresh値はセカンダリサーバーがプライマリサーバーをチェックする間隔です
- Expire値は、プライマリサーバーに接続できない場合にセカンダリサーバーがゾーン情報を保持する期間です
- 管理者メールアドレスは「@」を「.」に置き換えて記述します（例: admin@example.com → admin.example.com.）
PTRレコード（Pointer Record）
役割と用途:
PTRレコードは、IPアドレスからドメイン名への逆引き参照（Reverse DNS Lookup）を行うためのレコードです。
電話帳に例えると、通常のAレコードは「名前（ドメイン名）から電話番号（IPアドレス）を調べる」順引き電話帳です。一方、PTRレコードは「電話番号（IPアドレス）から名前（ドメイン名）を調べる」逆引き電話帳のような役割を果たします。
特にメールサーバーでは、このPTRレコードが「このIPアドレスのサーバーは本当に正規のメールサーバーです」という身元証明として使われるため、設定していないとスパムメールの送信者と疑われてしまうことがあります。
設定例:
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
実務での使用シーン:
- メールサーバーの逆引き設定（スパム判定回避）
- サーバーのホスト名確認
- ログ解析時のIPアドレスからホスト名への変換
- セキュリティ監査でのアクセス元確認
よくある設定ミスと注意点:
- PTRレコードは、IPアドレスの管理者（通常はISPやホスティング事業者）が設定する必要があります
- 正引き（Aレコード）と逆引き（PTRレコード）の結果が一致していることが推奨されます
- メールサーバーでは、PTRレコードが設定されていないとスパムと判定されることがあります
- IPv4の場合は「in-addr.arpa」、IPv6の場合は「ip6.arpa」ゾーンで管理されます
SRVレコード（Service Record）
役割と用途:
SRVレコードは、特定のサービスを提供するサーバーの位置情報（ホスト名とポート番号）を指定するレコードです。サービスの自動検出や負荷分散に使用されます。
大型商業施設のフロアガイドに例えると、SRVレコードは「3階にレストラン、5階に映画館があります」というように、「どのサービスがどこのサーバーの何番ポートで提供されているか」を案内する標識のような役割を果たします。
通常のAレコードが「建物の住所（IPアドレス）」を教えるだけなのに対し、SRVレコードは「建物の中のどの階の何号室でサービスを受けられるか」まで詳しく教えてくれるイメージです。
これにより、クライアントアプリケーションは自動的に適切なサーバーとポート番号を見つけて接続できます。
設定例:
_service._proto.example.com. 3600 IN SRV 10 60 5060 sipserver.example.com.
_ldap._tcp.example.com. 3600 IN SRV 10 0 389 ldap.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 5 0 5269 xmpp.example.com.
SRVレコードの形式は以下の通りです。
_service._protocol.name TTL class SRV priority weight port target
実務での使用シーン:
- Microsoft Active DirectoryのKerberos、LDAP認証
- SIP（VoIP）サーバーの自動検出
- XMPPメッセージングサービス
- Minecraftサーバーなどのゲームサーバー設定
よくある設定ミスと注意点:
- サービス名とプロトコルは、アンダースコア（_）で始まる必要があります
- Priority（優先度）は小さい値ほど優先されます
- Weight（重み）は同じ優先度内での負荷分散の割合を示します
- Targetには必ずホスト名を指定し、そのホスト名はAレコードまたはAAAAレコードで解決できる必要があります
- CNAME レコードをtargetとして使用することはできません
CAAレコード（Certification Authority Authorization）
役割と用途:
CAAレコードは、そのドメインに対してSSL/TLS証明書を発行できる認証局（CA）を制限するレコードです。不正な証明書の発行を防ぐセキュリティ対策として使用されます。
印鑑証明に例えると、CAAレコードは「この実印の証明書を発行できるのは、指定した役所（認証局）だけです」という制限をかけるようなものです。これにより、信頼していない第三者が勝手にあなたのドメイン名でSSL証明書を発行することを防ぎます。
例えば、「Let’s Encryptからの証明書発行のみ許可する」と設定すれば、他の認証局が誤って（または悪意を持って）証明書を発行しようとしても、CAAレコードをチェックした認証局は発行を拒否します。これはドメインのなりすまし被害を防ぐ重要なセキュリティ対策です。
設定例:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"
実務での使用シーン:
- SSL/TLS証明書の発行制限
- 特定の認証局のみに証明書発行を許可
- ワイルドカード証明書の発行制限
- セキュリティインシデント時の通知先設定
よくある設定ミスと注意点:
- CAAレコードが設定されていない場合、すべての認証局が証明書を発行できます
- サブドメインに対する証明書発行を許可する場合は「issuewild」タグを使用します
- 複数の認証局を許可する場合は、それぞれ個別のCAAレコードを設定します
- CAAレコードを設定する前に、現在使用している認証局を確認してください
- 「iodef」タグで不正な証明書発行の試行を通知する連絡先を指定できます
レコードタイプの使い分けポイント
各DNSレコードタイプを適切に使い分けるために、実務での判断基準をまとめました。
Aレコード vs CNAMEレコード
Aレコードを使用する場合:
- ゾーンのAPEX（example.com自体）
- 最速の名前解決が必要な場合
- IPアドレスを直接管理したい場合
CNAMEレコードを使用する場合:
- 複数のホスト名を1つのサーバーに向けたい場合
- CDNやロードバランサーなどの外部サービスを利用する場合
- サーバー移行時の柔軟性を確保したい場合
MXレコードの優先度設定
メールサーバーを複数設定する場合の推奨設定パターン：
プライマリ・バックアップ構成:
- プライマリ: 優先度 10
- バックアップ: 優先度 20
優先度の差を10以上にすることで、明確な優先順位を設定できます。
負荷分散構成:
- サーバー1: 優先度 10
- サーバー2: 優先度 10
同じ優先度を設定することで、ランダムに振り分けられます。
TXTレコードの整理方法
TXTレコードは1つのホスト名に複数設定できるため、用途別に整理することが重要です。
example.com. IN TXT "v=spf1 ..." # SPF設定
example.com. IN TXT "google-site-..." # Google確認
_dmarc.example.com. IN TXT "v=DMARC1 ..." # DMARC設定
selector._domainkey.example.com. IN TXT "v=DKIM1..." # DKIM設定
よくある設定ミスのまとめ
実務でよく発生するDNSレコード設定のミスをまとめました。
1. TTL値の設定ミス
問題: DNS変更前にTTL値を短縮せずに変更を行い、切り替えに時間がかかる。
対策:
- 変更の24〜48時間前にTTLを短縮（例: 300秒程度）
- 変更完了後、TTLを元の値に戻す
2. レコードタイプの競合
問題: 同一ホスト名に対してCNAMEと他のレコードタイプを同時に設定してしまう。
対策:
- CNAMEレコードを設定する場合は、そのホスト名に他のレコードタイプを設定しない
- ゾーンAPEXにはCNAMEを使用せず、Aレコードを使用する
3. MXレコードでCNAMEを指定
問題: MXレコードの値としてCNAMEレコードのホスト名を指定してしまう。
対策:
- MXレコードの値は必ずAレコードまたはAAAAレコードで解決できるホスト名を指定する
- メールサーバーにCNAMEを使用したい場合は、MXレコードには実体のあるホスト名を指定し、そのホスト名に対してAレコードを設定する
4. 逆引き設定の未実施
問題: メールサーバーに逆引き（PTRレコード）を設定せず、送信メールがスパム判定される。
対策:
- メールサーバーのIPアドレスには必ずPTRレコードを設定する
- 正引きと逆引きの結果が一致することを確認する
- ISPやホスティング事業者に逆引き設定を依頼する
5. SPFレコードのDNSルックアップ制限超過
問題: SPFレコードに多数のincludeを記述し、DNSルックアップが10回を超えてしまう。
対策:
- SPFレコード内のinclude、a、mx、ptr、existsメカニズムの合計が10回以内になるよう設計する
- 不要なincludeを削除し、可能な限りip4やip6で直接IPアドレスを指定する
- 複数のメール送信サービスを利用する場合は、統合を検討する
6. ゾーンファイルの末尾ドット忘れ
問題: FQDN（完全修飾ドメイン名）の末尾にドット（.）を付け忘れ、意図しないドメイン名になってしまう。
対策:
- ゾーンファイル内でFQDNを記述する際は、必ず末尾にドット（.）を付ける
- 相対名を使用する場合は、ゾーンのoriginが自動的に付加されることを理解する
# 正しい記述
mail.example.com. IN A 192.0.2.10
# 誤った記述（ドット忘れ）
mail.example.com IN A 192.0.2.10
# → mail.example.com.example.com. として解釈される可能性がある
7. NSレコードとレジストラ設定の不一致
問題: DNSゾーンファイルのNSレコードと、ドメインレジストラに登録されているネームサーバーが一致していない。
対策:
- DNSゾーンファイルのNSレコードと、レジストラ側のネームサーバー設定を常に同期させる
- ネームサーバーを変更する場合は、両方を確実に更新する
- whoisコマンドで現在のネームサーバー設定を確認する
DNSレコード設定のベストプラクティス
最後に、DNSレコードを設定・管理する際のベストプラクティスをまとめます。
1. 冗長化の徹底
- 重要なレコード（NS、MX）は必ず複数設定する
- ネームサーバーは異なるネットワーク上に配置する
- メールサーバーもプライマリとバックアップを用意する
2. TTL値の適切な設定
- 通常時は3600秒（1時間）〜86400秒（24時間）程度
- 変更予定がある場合は事前に短縮（300秒程度）
- 変更完了後は元の値に戻す（キャッシュサーバーの負荷軽減）
3. ドキュメント化と変更履歴の管理
- すべてのDNSレコードの設定意図を文書化する
- 変更履歴を記録し、いつ、誰が、何を変更したかを追跡可能にする
- 緊急時の連絡先と手順を明確にする
4. 定期的な確認と監視
- digコマンドやnslookupで定期的にレコードを確認する
- DNS監視ツールを使用して、レコードの変更や障害を検知する
- 外部DNSサーバーからも名前解決を確認する
5. セキュリティ対策の実施
- DNSSEC（DNS Security Extensions）の導入を検討する
- CAAレコードで証明書発行機関を制限する
- SPF、DKIM、DMARCでメール認証を強化する
- 不要なレコードは削除し、攻撃対象を最小化する
6. テスト環境での事前検証
- 本番環境への変更前に、テスト環境で動作を確認する
- DNSシミュレーターツールを使用して設定を検証する
- ロールバック手順を事前に準備しておく
関連記事
DNSレコードの確認には、digコマンドが非常に有用です。digコマンドの詳しい使い方については、以下の記事で解説していますので、ぜひ併せてご覧ください。
【RHEL】digコマンドの使い方完全ガイド – 基礎から実践的なトラブルシューティングまで
この記事では、digコマンドを使って各種DNSレコードを確認する方法や、実践的なトラブルシューティング手法を詳しく解説しています。本記事で学んだDNSレコードの知識と組み合わせることで、より効果的なDNS運用が可能になります。
まとめ
今回は、DNSレコードタイプの種類と各レコードの役割、用途について詳しく解説しました。
重要なポイント:
- DNSレコードは用途に応じて適切なタイプを選択する必要がある
- A/AAAAレコードは基本的なIPアドレス解決、MXレコードはメールルーティング、TXTレコードは認証情報の格納に使用される
- CNAMEレコードは便利だが、ゾーンAPEXや他のレコードタイプとの併用に制約がある
- MXレコード、NSレコードでは優先度や冗長化を考慮した設計が重要
- SPF、DKIM、DMARCなどのTXTレコードはメールセキュリティに不可欠
- よくある設定ミスを理解し、事前に対策を講じることでトラブルを回避できる
- TTL値の適切な管理、冗長化、ドキュメント化がDNS運用の基本
各DNSレコードタイプの特性を理解し、適切に設定・管理することで、安定したドメイン運用が可能になります。実務でDNSレコードを扱う際は、今回紹介した内容を参考に、計画的かつ慎重に設定を行ってください。特に本番環境での変更は、事前のテストとロールバック手順の準備を忘れずに実施しましょう。
コメント