DNSレコードの種類一覧｜digの実出力で役割と設定ミスを確認

DNSレコードとは、ドメイン名に対して「IPアドレスはどこか」「メールはどこへ届けるか」などの情報を1件ずつ登録したデータのことです。 レコードには種類（タイプ）があり、A・AAAA・CNAME・MX・TXT・NS・SOA・CAA・SRV・HTTPS・PTRなど、用途ごとに使い分けます。

この記事では、各レコードの役割を一覧で整理したうえで、検証用の権威DNSサーバー（BIND 9.18）をローカルに立て、すべてのレコードを dig で実際に引いた出力を載せています。 外部のドメインではなく、テスト用に予約された example.test と文書用のIPアドレス（192.0.2.0/24、2001:db8::/32）を使っているため、読者の環境でも同じゾーンファイルで再現できます。さらに、CNAMEをapex（ドメインの頂点）に置いたときのエラー、TTLが減っていく様子、「DNS伝播」の正体、存在しない名前がキャッシュされるネガティブキャッシュも、実際の出力で確認します。

DNSレコードの種類 早見表

検証環境：ローカルに権威DNSサーバーを立てる

この環境の dig は外部のDNS（8.8.8.8）も引けましたが、実在ドメインの設定は日々変わるため、記事ではローカルの権威DNSサーバーで検証しました。 権威DNSサーバーとは、そのドメインの正解データを持ち、問い合わせに答えるサーバーです。対して、利用者の代わりに問い合わせて結果をキャッシュするのがフルリゾルバ（キャッシュDNSサーバー）です。

flowchart LR
    C[パソコン・スマホ<br/>スタブリゾルバ] -->|問い合わせ| R[フルリゾルバ<br/>キャッシュDNS]
    R -->|キャッシュに無ければ| Root[ルート]
    R --> TLD[TLDのDNS]
    R --> A[権威DNSサーバー<br/>example.test]
    A -->|レコード + TTL| R
    R -->|TTLの間キャッシュ| C

権威DNSはBIND 9.18.39を127.0.0.1:7063で、キャッシュDNSは同じBINDを7064で起動し、dig 9.18.39から問い合わせています。

使ったゾーンファイル

$TTL 3600
$ORIGIN example.test.
@       IN SOA  ns1.example.test. hostmaster.example.test. (
                2026092801 ; serial
                7200       ; refresh
                1800       ; retry
                1209600    ; expire
                300 )      ; negative cache TTL
@       IN NS    ns1.example.test.
@       IN NS    ns2.example.test.
ns1     IN A     192.0.2.53
ns2     IN A     192.0.2.54
@       IN A     192.0.2.10
@       IN AAAA  2001:db8::10
www     IN CNAME example.test.
@       IN MX 10 mail.example.test.
@       IN MX 20 mail2.example.test.
mail    IN A     192.0.2.25
mail2   IN A     192.0.2.26
@       IN TXT   "v=spf1 ip4:192.0.2.25 ip4:192.0.2.26 -all"
sel1._domainkey IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAexamplekey"
_dmarc  IN TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.test"
@       IN CAA   0 issue "ca.example.net"
@       IN CAA   0 iodef "mailto:security@example.test"
_sip._tcp IN SRV 10 60 5060 sip.example.test.
sip     IN A     192.0.2.60
@       IN HTTPS 1 . alpn="h2,h3" ipv4hint=192.0.2.10
api     IN A     192.0.2.20
short   300 IN A 192.0.2.30

@ はゾーンの頂点（ここでは example.test.）を表します。名前の末尾の . は「これで完結した名前」という意味で、付け忘れると $ORIGIN が後ろに足されます（mail.example.test と書くと mail.example.test.example.test. になる）。

ゾーンファイルは、読み込む前に named-checkzone で文法を確認できます。

$ named-checkzone example.test example.test.zone
zone example.test/IN: loaded serial 2026092801
OK

digの出力の読み方

dig の出力は「ヘッダー」「質問」「回答」「権威」「追加」の各セクションに分かれています。 まずはAレコードを、省略なしで見てみます。

$ dig @127.0.0.1 -p 7063 example.test A +norec

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8573
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;example.test.          IN  A

;; ANSWER SECTION:
example.test.       3600    IN  A   192.0.2.10

;; AUTHORITY SECTION:
example.test.       3600    IN  NS  ns2.example.test.
example.test.       3600    IN  NS  ns1.example.test.

;; ADDITIONAL SECTION:
ns1.example.test.   3600    IN  A   192.0.2.53
ns2.example.test.   3600    IN  A   192.0.2.54

;; Query time: 0 msec
;; SERVER: 127.0.0.1#7063(127.0.0.1) (UDP)

よく使うオプションは次のとおりです。

レコードごとの実出力と解説

以下は dig @127.0.0.1 -p 7063 +noall +answer で問い合わせた実際の出力です。

A / AAAAレコード：名前からIPアドレスへ

$ dig ... example.test AAAA
example.test.       3600    IN  AAAA    2001:db8::10

Aは IPv4、AAAAは IPv6 のアドレスを返します。 両方を登録しておくと、IPv6が使える利用者はIPv6で、そうでない利用者はIPv4で接続します。

CNAMEレコード：別名を付ける

$ dig ... www.example.test A
www.example.test.   3600    IN  CNAME   example.test.
example.test.       3600    IN  A   192.0.2.10

Aを聞いたのに、まずCNAMEが返り、続けて別名先のAが返っています。 CNAMEは「この名前は別の名前の別名です」という意味で、リゾルバは別名先をたどって最終的な値を返します。外部のサービスにホスト名を向けるときによく使います。

MXレコード：メールの配送先

$ dig ... example.test MX
example.test.       3600    IN  MX  10 mail.example.test.
example.test.       3600    IN  MX  20 mail2.example.test.

数字は優先度で、小さいほど優先されます。 10のサーバーに届かないとき、20のサーバーに配送されます。MXの値はホスト名で、IPアドレスを直接書くことはできません。

TXTレコード：SPF・DKIM・DMARC

$ dig ... example.test TXT
example.test.       3600    IN  TXT "v=spf1 ip4:192.0.2.25 ip4:192.0.2.26 -all"
$ dig ... sel1._domainkey.example.test TXT
sel1._domainkey.example.test. 3600 IN   TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAexamplekey"
$ dig ... _dmarc.example.test TXT
_dmarc.example.test.    3600    IN  TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.test"

TXTは任意の文字列ですが、メールの送信ドメイン認証ではとくに重要です。

SPFには「DNSの参照は10回まで」という上限があり、include: を重ねすぎると検証に失敗します。SPFは1つのドメインに1レコードだけにまとめましょう。DMARCは2026年5月に改訂版（RFC 9989〜9991）が公開され、pct= などいくつかのタグが廃止されています。既存の設定を見直す機会に確認しておくと安心です。

NS / SOAレコード：ゾーンの管理情報

$ dig ... example.test NS
example.test.       3600    IN  NS  ns1.example.test.
example.test.       3600    IN  NS  ns2.example.test.
$ dig ... example.test SOA
example.test.       3600    IN  SOA ns1.example.test. hostmaster.example.test. 2026092801 7200 1800 1209600 300

NSはそのゾーンを管理する権威DNSサーバー、SOAはゾーン全体の管理情報です。 SOAの数値は左から次の意味です。

CAAレコード：証明書を発行できる認証局を限定する

$ dig ... example.test CAA
example.test.       3600    IN  CAA 0 iodef "mailto:security@example.test"
example.test.       3600    IN  CAA 0 issue "ca.example.net"

CAA（Certification Authority Authorization）は、このドメインの証明書を発行してよい認証局を指定するレコードです（RFC 8659）。 認証局は発行前にCAAを確認することが義務づけられており、ここに載っていない認証局は発行を控えます。issue は通常の証明書、issuewild はワイルドカード証明書、iodef は違反の報告先です。CAAを設定したら、利用中の認証局を必ず含めておくと、更新時の発行エラーを防げます。

SRVレコード：サービスのホストとポート

$ dig ... _sip._tcp.example.test SRV
_sip._tcp.example.test. 3600    IN  SRV 10 60 5060 sip.example.test.

名前は _サービス._プロトコル.ドメイン の形で、値は「優先度 重み ポート ホスト名」です（RFC 2782）。 同じ優先度の中では重みの比率で振り分け、ポートも伝えられるのが特徴です。

HTTPS（SVCB）レコード：接続方法を事前に伝える

$ dig ... example.test HTTPS
example.test.       3600    IN  HTTPS   1 . alpn="h2,h3" ipv4hint=192.0.2.10

HTTPSレコードは、HTTPSで接続する前に「HTTP/3に対応している」「このIPで接続できる」などの情報を伝えるレコードです（RFC 9460、汎用形がSVCB）。 先頭の数字が 1 以上なら接続情報を持つ「ServiceMode」、0 なら別名を示す「AliasMode」です。. は「この名前自身」を意味します。

AliasMode（優先度0）はapexにも置けるため、後述の「apexにCNAMEを置けない」問題の標準的な解決策として期待されています。

PTRレコード：逆引き

$ dig @127.0.0.1 -p 7063 +noall +answer -x 192.0.2.10
10.2.0.192.in-addr.arpa. 3600   IN  PTR example.test.

IPアドレスを逆順に並べ、in-addr.arpa（IPv6は ip6.arpa）を付けた名前で問い合わせます。 逆引きゾーンは通常、IPアドレスを割り当てた側（クラウドやプロバイダ）が管理するため、設定はその管理画面や申請で行います。メールサーバーでは、正引き（A）と逆引き（PTR）が一致していることが受信側の確認項目になることが多いです。

CNAMEのルール：apexに置けない・他のレコードと共存できない

CNAMEを設定した名前には、ほかのレコードを一切置けません。 apex（example.test そのもの）には必ずSOAとNSがあるため、結果としてapexにCNAMEは置けません。実際にゾーンを作って確かめました。

失敗例1：apexにCNAME

@   IN NS    ns1.example.test.
@   IN CNAME lb.example.net.

$ named-checkzone example.test bad1.zone
dns_master_load: bad1.zone:5: example.test: CNAME and other data
zone example.test/IN: loading from master file bad1.zone failed: CNAME and other data
zone example.test/IN: not loaded due to errors.

失敗例2：CNAMEとTXTを同じ名前に置く

ドメイン所有確認のTXTを、CNAME設定済みの www に追加しようとするケースです。

www IN CNAME lb.example.net.
www IN TXT "verify=abc123"

$ named-checkzone example.test bad2.zone
dns_master_load: bad2.zone:6: www.example.test: CNAME and other data
zone example.test/IN: not loaded due to errors.

どちらも「CNAME and other data」でゾーン全体が読み込まれませんでした。 管理画面型のDNSサービスでは登録時にエラーになるのが一般的です。

警告例：MXの向け先がCNAME

$ named-checkzone example.test bad3.zone
zone example.test/IN: example.test/MX 'mail.example.test' is a CNAME (illegal)
zone example.test/IN: loaded serial 1
OK

こちらは読み込みは成功しますが、「MXの向け先がCNAME」は仕様上認められない（illegal）と警告されます。 MX・NSの値には、A/AAAAを持つホスト名を直接指定しましょう。

apexを外部サービスに向けたいときの選択肢

TTLと「DNS伝播」の正体

「DNSの変更が伝播するまで待つ」と言われるものの正体は、各地のキャッシュDNSが持っている古いデータのTTLが切れるのを待つことです。 変更が能動的に配られるわけではありません。キャッシュDNS（ポート7064）を通して確かめました。

## 1回目の問い合わせ（権威DNSから取得、TTL=300）
short.example.test. 300 IN  A   192.0.2.30
## 5秒後（キャッシュから応答、TTLが減っている）
short.example.test. 295 IN  A   192.0.2.30

## ここで権威DNS側を 192.0.2.31 に変更して再読み込み
$ dig @127.0.0.1 -p 7063 +noall +answer short.example.test A
short.example.test. 300 IN  A   192.0.2.31

## キャッシュDNSに聞くと、まだ古い値（残りTTL 293秒）
short.example.test. 293 IN  A   192.0.2.30

権威DNSはすでに新しい値を返しているのに、キャッシュDNSは残りTTLが0になるまで古い値を返し続けました。 世界中のキャッシュDNSがそれぞれ違うタイミングで取得しているため、「場所によって切り替わる時刻が違う」ように見えます。

切り替えを速くしたいときの手順は次のとおりです。

1. 変更予定日の前に、TTLを短く（例：300秒）しておく。 元のTTL（例：3600秒）が経過するまで待つ
2. レコードを変更する（切り替えは最大300秒で行き渡る）
3. 安定したらTTLを元に戻す

なお、NSレコードの変更（DNSサーバーの移管）は、親ゾーン（TLD側）のNSのTTLにも左右されます。 親側のTTLは自分では短くできないため、旧DNSサーバーもしばらく同じ内容で動かしておくと、移行が安全に進みます。

ネガティブキャッシュ：存在しない名前もキャッシュされる

「その名前は存在しない（NXDOMAIN）」という回答もキャッシュされます。これをネガティブキャッシュと呼びます（RFC 2308）。 保持時間は、SOAのminimum値とSOAレコード自身のTTLのうち小さいほうです。

## まだ登録していない new.example.test を問い合わせる
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
example.test.       300 IN  SOA ns1.example.test. ... 2026092801 7200 1800 1209600 300

## 権威DNSに new.example.test（192.0.2.99）を追加して再読み込み
$ dig @127.0.0.1 -p 7063 +noall +answer new.example.test A
new.example.test.   60  IN  A   192.0.2.99

## キャッシュDNSに再度問い合わせると、まだ NXDOMAIN（残り298秒）
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN
example.test.       298 IN  SOA ns1.example.test. ... 2026092801 7200 1800 1209600 300

新しいレコードは追加したのに、事前に一度問い合わせていたキャッシュDNSでは、ネガティブキャッシュのTTL（300秒）が切れるまで「存在しない」と返り続けました。 新しいサブドメインを公開するときは、レコードを作る前に動作確認で問い合わせないか、SOAのminimumを短めにしておくとスムーズです。

なお、名前は存在するがその型のレコードがない場合（例：api.example.test のAAAA）は、NXDOMAIN ではなく status: NOERROR で回答が0件（NODATA）になることも確認しました。

よくある設定ミス早見表

digとnslookupの対応表

Windows標準の nslookup でも同じ確認ができます。 今回のローカル環境で実行したnslookupの出力は次のとおりです。

$ nslookup -port=7063 -type=MX example.test 127.0.0.1
Server:     127.0.0.1
Address:    127.0.0.1#7063

example.test    mail exchanger = 10 mail.example.test.
example.test    mail exchanger = 20 mail2.example.test.

TTLやフラグ（aa）まで一目で確認できるため、原因調査にはdigが便利です。

よくある質問

Q. CNAMEとAレコードはどちらを使えばよいですか？ A. 自分でIPアドレスを管理しているならA、外部サービスなど向け先のIPが変わりうるならCNAMEが基本です。ただしapexにはCNAMEを置けないため、apexはA/AAAAか、DNSサービスのALIAS機能、HTTPSレコードのAliasModeを使います。

Q. DNSの変更が反映されるまで何時間かかりますか？ A. 変更前のレコードのTTLが上限の目安です。 TTLが3600秒なら最大1時間、86400秒なら最大1日、古い値が残る可能性があります。今回の実験でも、キャッシュDNSは残りTTLが切れるまで古い値を返しました。NSの変更は親ゾーン側のTTLも関係します。

Q. HTTPSレコードは設定したほうがよいですか？ A. HTTP/3を提供している場合や、ECHを使いたい場合に効果があります。 対応していないクライアントはHTTPSレコードを無視してA/AAAAで接続するため、A/AAAAを残したうえで追加する形なら、既存の利用者に影響を与えずに導入できます。

Q. 追加したばかりのサブドメインが「存在しない」と言われます。 A. ネガティブキャッシュの可能性があります。 追加前に問い合わせていた場合、SOAのminimum（今回は300秒）が経過するまで NXDOMAIN が返ります。権威DNSに dig @権威DNS 名前 +norec で直接聞いて正しく登録されているか確認し、あとは時間が経つのを待ちましょう。

まとめ

• DNSレコードは用途ごとに型がある：A/AAAA（IP）、CNAME（別名）、MX（メール）、TXT（認証）、NS/SOA（管理）、CAA（証明書）、SRV（ポート）、HTTPS（接続情報）、PTR（逆引き）
• digの status・flags aa・TTL を読めば、どこから来た回答かがわかる
• CNAMEは他のレコードと共存できず、apexに置けない（実際に「CNAME and other data」で読み込み失敗）
• 「DNS伝播」の正体はキャッシュのTTL切れ待ち。切り替え前にTTLを短くしておく
• 存在しない名前もネガティブキャッシュされる。保持時間はSOAのminimumとSOAのTTLの小さいほう
• CAAで認証局を限定し、HTTPSレコードでHTTP/3などを事前に伝えられる
• メール認証はSPF・DKIM・DMARCのTXT。DMARCは2026年5月の改訂版（RFC 9989）も確認しておく

株式会社RJCでは、手元に検証環境を作って仕組みを確かめる楽しさを、プロジェクトの中で仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。