DNS レコード
概要
DNS レコード は、ドメイン名に紐づく情報を格納するデータベースのエントリです。RFC 1035 で定義されたリソースレコード（Resource Record、RR）の形式に従い、ゾーンファイルに保存されます。ウェブサーバーの IPv4 アドレスを返す A レコード、メールサーバーの宛先を指定する MX レコード、ドメイン認証情報を格納する TXT レコードなど、用途ごとに異なる型が定義されています。
インターネット上のほぼすべての通信は DNS レコードの解決から始まります。example.com にアクセスしたとき、ブラウザーは A レコードを問い合わせてサーバーの IP アドレスを取得します。メールを送るときは MX レコードで配送先サーバーを特定します。SSL 証明書の発行時には CAA レコードで許可された認証局を確認します。DNS レコードの設定ミスはサービス停止に直結するため、変更前に全体像を把握しておく必要があります。
主なレコードの種類と仕組み
DNS レコードは用途ごとにタイプが分かれており、A・AAAA・CNAME・MX・TXT・NS・SOA・CAA・SRV が代表的です。
| レコード種別 | 用途 | 定義 RFC |
|---|---|---|
| A | ドメイン名を IPv4 アドレスに対応付ける | RFC 1035 |
| AAAA | ドメイン名を IPv6 アドレスに対応付ける | RFC 3596 |
| CNAME | ドメイン名を別のドメイン名にエイリアスする | RFC 1035 |
| MX | メールの配送先サーバーを指定する | RFC 1035 |
| TXT | SPF・DKIM・DMARC 等の認証データを格納する | RFC 1035 |
| NS | ドメインの権威 DNS サーバーを指定する | RFC 1035 |
| SOA | ゾーンの管理情報（シリアル番号・TTL 等）を格納する | RFC 1035, RFC 2308 |
| CAA | SSL/TLS 証明書を発行できる認証局を制限する | RFC 8659 |
| SRV | サービスのホスト・ポートを指定する | RFC 2782 |
A レコードと AAAA レコード
A レコードは RFC 1035 で定義されており、ドメイン名を 32 ビットの IPv4 アドレスに対応付けます。AAAA レコードは RFC 3596 で定義され、128 ビットの IPv6 アドレスに対応付けます。1 つのドメインに複数の A レコードを設定すると、DNS ラウンドロビンによる負荷分散が可能になります。
example.com. IN A 93.184.216.34
example.com. IN AAAA 2606:2800:21f:cb07:6820:80da:af6b:8b2cCNAME レコード
CNAME（Canonical Name）レコードは、ドメイン名を別のドメイン名にエイリアスします。www.example.com を example.com に向けるような用途で使われます。重要な制約として、CNAME が設定されたドメインには他のレコードを同時に設定できません。example.com 自体（ゾーンの頂点、Apex ドメイン）に CNAME を使えないのはこの制約によるものです。
www.example.com. IN CNAME example.com.MX レコード
MX（Mail Exchange）レコードはメールの配送先を指定します。プリファレンス値（優先度の数値）が小さいほど優先されます。複数の MX レコードを設定することで、プライマリサーバーが応答しない場合のフォールバックを構成できます。
example.com. IN MX 10 mail1.example.com.
example.com. IN MX 20 mail2.example.com.TXT レコード
TXT レコードは任意のテキストを格納します。元来は人間が読むメモ用途でしたが、現在は SPF（RFC 7208）、DKIM、DMARC（RFC 7489）、Google や GitHub のドメイン所有権確認など、機械が読む認証データの主要な格納場所になっています。1 つのドメインに複数の TXT レコードを設定することは可能ですが、SPF レコードは 1 つに限定されています。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
example.com. IN TXT "google-site-verification=abc123..."NS レコード
NS（Name Server）レコードは、そのドメインの権威 DNS サーバーを指定します。ドメインレジストラが管理するものであり、通常は 2 本以上設定して冗長性を確保します。NS レコードを変更するとドメイン全体の DNS 管理が移行するため、変更には特に慎重さが求められます。
example.com. IN NS ns1.nameserver.example.
example.com. IN NS ns2.nameserver.example.SOA レコード
SOA（Start of Authority）レコードはゾーンの管理情報を格納します。RFC 1035 で定義された MNAME（プライマリネームサーバー）、RNAME（管理者メールアドレス。@ を . に置換した形式）、SERIAL（ゾーンのバージョン番号）、REFRESH、RETRY、EXPIRE、MINIMUM の 7 フィールドで構成されます。RFC 2308 によって MINIMUM フィールドの意味は「ネガティブキャッシュの TTL」に再定義されています。
example.com. IN SOA ns1.example.com. admin.example.com. (
2024010101 ; SERIAL
3600 ; REFRESH (1時間)
900 ; RETRY (15分)
604800 ; EXPIRE (7日)
300 ; MINIMUM / ネガティブ TTL (5分)
)CAA レコード
CAA（Certification Authority Authorization）レコードは RFC 8659 で定義されており、そのドメインに対して SSL/TLS 証明書を発行できる認証局を制限します。CAA レコードが未設定の場合、任意の認証局が証明書を発行できます。設定は任意ですが、意図しない認証局による誤発行を防ぎたい場合に推奨されます。たとえば Let’s Encrypt のみに発行を限定したい場合は letsencrypt.org を許可する CAA レコードを設定します。
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"SRV レコード
SRV（Service）レコードは、特定のサービスを提供するホストとポートを指定します。SIP や XMPP など、ポート番号まで含めてサービスを探索するプロトコルで使われます。フォーマットは _サービス._プロトコル.ドメイン で、優先度・ウェイト・ポート・ターゲットの 4 フィールドを持ちます。
_sip._tcp.example.com. IN SRV 10 20 5060 sip.example.com.レコードの共通フォーマット
RFC 1035 はリソースレコードの共通フォーマットを次のように定義しています。
名前 TTL クラス タイプ データ- 名前: レコードのオーナー（ドメイン名）
- TTL: キャッシュ有効期間（秒）
- クラス: ほぼすべての場合
IN（Internet） - タイプ: A、MX、TXT など
- データ: タイプに応じた値
TTL を省略するとゾーンの $TTL ディレクティブの値が適用されます。
設定例
典型的なドメインの DNS ゾーン設定一式を示します。
$TTL 3600
example.com. IN SOA ns1.example.com. admin.example.com. (
2024010101 3600 900 604800 300 )
; ネームサーバー
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; Web サーバー
example.com. IN A 93.184.216.34
www IN CNAME example.com.
; メールサーバー
example.com. IN MX 10 mail.example.com.
mail IN A 198.51.100.1
; 認証レコード
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"
; 証明書制限
example.com. IN CAA 0 issue "letsencrypt.org"確認方法
特定のレコードタイプを手元から確認するには dig でタイプを指定します。
A レコードの確認:
dig A example.com;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34MX レコードの確認:
dig MX example.com;; ANSWER SECTION:
example.com. 3600 IN MX 10 mail1.example.com.
example.com. 3600 IN MX 20 mail2.example.com.TXT レコード（SPF など）の確認:
dig TXT example.com;; ANSWER SECTION:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=example.com"{
"success": true,
"data": {
"domain": "example.com",
"records": {
"A": [{ "address": "93.184.216.34", "ttl": 3600 }],
"AAAA": [{ "address": "2606:2800:21f:cb07:6820:80da:af6b:8b2c", "ttl": 3600 }],
"MX": [{ "priority": 10, "exchange": "mail1.example.com" }],
"TXT": [["v=spf1 include:_spf.google.com ~all"]],
"NS": ["ns1.example.com", "ns2.example.com"],
"CNAME": null,
"SOA": [{
"mname": "ns1.example.com",
"rname": "admin.example.com",
"serial": 2024010101,
"refresh": 3600,
"retry": 900,
"expire": 604800,
"minimum": 300
}],
"CAA": [{ "flags": 0, "tag": "issue", "value": "letsencrypt.org" }]
}
},
"error": null,
"meta": { "responseTime": 120 }
}A、AAAA、MX、TXT、NS、CNAME、SOA、CAA の各レコードがまとめて返されます。dig の結果と差異がある場合はキャッシュの影響を疑ってください。
よくある問題
DNS レコードの設定では CNAME の共存制約、TTL の事前短縮忘れ、TXT の文字列長制限が頻出するトラブルです。
CNAME と他のレコードの共存
CNAME が設定されたドメインに A や MX などのレコードを追加しようとすると、ゾーンの整合性エラーが発生します。Apex ドメインに CNAME を使えない問題の回避策として、CloudFlare や NS1 などのプロバイダーは ALIAS レコードや CNAME Flattening と呼ばれる独自拡張を提供しています。これらは DNS プロトコルの正式な仕様ではなく、プロバイダー固有の機能です。
TTL が高いままでの変更
TTL を下げずに IP アドレスの変更や MX レコードの切り替えを行うと、キャッシュが古い値を保持し続けます。変更の 24 時間前に TTL を 300 秒程度に下げ、変更後に元の値（3600 秒前後）に戻すのが標準的な手順です。
MX レコードのプリファレンス設定ミス
プリファレンス値が同じ MX レコードを複数設定すると、送信側は等コストとしてランダムに選択します。意図的な負荷分散ならよいですが、プライマリ・フォールバックの構成が目的なら値を変えて優先順位を明示する必要があります。
TXT レコードの文字列長制限
RFC 1035 は 1 つの文字列を 255 文字以内と定めています。DKIM 公開鍵のように長い文字列は、複数の文字列に分割して 1 つの TXT レコードに格納します。DNS プロバイダーの管理画面が自動分割を行う場合もあれば、手動で分割が必要な場合もあります。