権威DNSとキャッシュDNSの違い｜役割と名前解決の流れ、digでの見分け方

権威 DNS サーバーは「ドメインの正式な情報を持ち、その情報だけを答えるサーバー」、キャッシュ DNS サーバーは「利用者の代わりに権威 DNS をたどって答えを調べ、一定時間覚えておくサーバー」です。DNS のレコードを変更したのに反映されない、という悩みの多くは、この2つの違いを知っていると原因を切り分けられます。この記事では、両者の役割と名前解決の流れ、dig コマンドでどちらの答えを見ているかを確かめる方法、自分でサーバーを運用する場合に役割を分けるべき理由を解説します。

2種類のDNSサーバーの役割

権威DNSサーバー

権威 DNS サーバーは、特定のゾーン（example.com など）のレコードを保持し、そのゾーンについての問い合わせに答えます。レジストラやレンタルサーバーの DNS、Cloudflare DNS、Amazon Route 53 などで「レコードを登録している場所」が権威 DNS です。自分で運用する場合は、BIND、NSD、Knot DNS、PowerDNS Authoritative Server などのソフトウェアが使われます。

権威 DNS は自分が管理するゾーン以外のことは調べに行きません。example.com の権威 DNS に google.com を聞いても、答えは返ってこない（または拒否される）のが正しい動作です。

キャッシュDNSサーバー（フルリゾルバー）

キャッシュ DNS サーバーは、パソコンやサーバーからの問い合わせを受け付け、ルートサーバーから順に権威 DNS をたどって答えを調べ、その結果を TTL の間保存します。プロバイダが提供する DNS、社内ネットワークの DNS、Google Public DNS（8.8.8.8）、Cloudflare の 1.1.1.1、Quad9（9.9.9.9）などがこれに当たります。ソフトウェアでは Unbound、BIND（再帰問い合わせを有効にした構成）、PowerDNS Recursor、Knot Resolver などが代表的です。

そのほかの登場人物

パソコンやサーバーの OS には、キャッシュ DNS に問い合わせるだけの小さな仕組み（スタブリゾルバー）があります。また、家庭用ルーターや Linux の systemd-resolved のように、受けた問い合わせを別のキャッシュ DNS に転送しつつ、自分でも少しキャッシュする「フォワーダー」もあります。どれも「調べる側」であり、ドメインの正式な情報を持つのは権威 DNS だけです。

名前解決の流れ

www.example.com を初めて調べるときは、次のように進みます。

1. パソコンの OS が、設定されたキャッシュ DNS に www.example.com を問い合わせる
2. キャッシュ DNS が、ルートサーバーに問い合わせ、com を管理するサーバーを教えてもらう
3. com のサーバーに問い合わせ、example.com の権威 DNS サーバー（NS レコード）を教えてもらう
4. example.com の権威 DNS サーバーに問い合わせ、www.example.com の A レコードを受け取る
5. キャッシュ DNS が答えを TTL の間保存し、パソコンに返す

2回目以降、TTL が残っている間は、キャッシュ DNS が保存した答えをそのまま返します。権威 DNS への問い合わせは発生しません。

この流れから分かるとおり、権威 DNS でレコードを書き換えても、キャッシュ DNS が古い答えを保存している間はその答えが返り続けます。いわゆる「DNS の反映待ち」は、キャッシュ DNS に残った古い答えの期限切れを待っている状態です。

違いを整理すると

digでどちらの答えか見分ける

dig コマンドは、問い合わせ先を @ で指定できます。権威 DNS とキャッシュ DNS に同じ質問をして結果を比べると、どこで食い違っているかが分かります。

# まず権威DNSサーバーの名前を調べる
dig example.com NS +short

# 権威DNSに直接聞く（+norec で再帰を求めない）
dig www.example.com A @ns1.example.net +norec

# キャッシュDNS（例：Google Public DNS）に聞く
dig www.example.com A @8.8.8.8

結果の flags: 行に注目します。権威 DNS からの応答には aa が付きます。キャッシュ DNS からの応答には通常 ra が付き、キャッシュから返した答えには aa が付きません。また、キャッシュ DNS の結果の TTL（2列目）は残り秒数なので、続けて実行すると減っていきます。

判断の目安は次のとおりです。

• 権威 DNS が新しい値、キャッシュ DNS が古い値：設定は正しく、キャッシュの期限切れを待てば揃います。待ち時間の上限は変更前の TTL です
• 権威 DNS も古い値：変更が保存されていない、別の DNS サービスのゾーンを編集している、などが考えられます。dig example.com NS で返るネームサーバーと、編集した管理画面のサービスが一致しているかを確認します
• **権威 DNS が答えない、または aa が付かない**：ネームサーバーの指定先にゾーンが作られていない可能性があります

公開されているキャッシュ DNS の一部（Google Public DNS や Cloudflare の 1.1.1.1 など）は、特定の名前のキャッシュを消してもらう申請ページを用意しています（2026年10月現在）。ただし、プロバイダや社内の DNS のキャッシュは利用者側では消せないため、基本は TTL の期限切れを待つことになります。

自分で運用するなら役割を分ける

VPS などで DNS サーバーを自分で立てる場合は、権威 DNS とキャッシュ DNS を別のサーバー（少なくとも別のプロセス）に分けるのが推奨される構成です。理由は次のとおりです。

• オープンリゾルバーになる危険：権威 DNS で再帰問い合わせを許可したままインターネットに公開すると、誰の問い合わせでも代わりに調べる「オープンリゾルバー」になります。これは DNS を使った増幅型の DDoS 攻撃の踏み台として悪用されます
• キャッシュポイズニングの影響：キャッシュに偽の情報を入れられた場合、同じサーバーが権威 DNS も兼ねていると、影響の範囲が広がります
• 障害の切り分け：役割が混ざっていると、どちらの機能の問題かが分かりにくくなります

BIND を権威 DNS 専用にする場合は、設定ファイルで再帰問い合わせを無効にします。キャッシュ DNS として使う場合は、問い合わせを受け付ける範囲を自分のネットワークに限定します。

// 権威DNS専用の例（named.conf の options 内）
options {
    recursion no;
};

// キャッシュDNSの例：再帰を許可する範囲を限定
options {
    recursion yes;
    allow-recursion { 127.0.0.1; 192.0.2.0/24; };
};

設定ファイルを変更する前にはバックアップを取り、named-checkconf で構文を確認してから再読み込みしてください。外部からの再帰問い合わせを受け付けていないかは、別のネットワークから dig @サーバーのIP example.org を実行し、答えが返らない（拒否される）ことで確かめられます。

まとめ

• 権威 DNS はゾーンの正式な情報を持ち、自分のゾーンについてだけ答える
• キャッシュ DNS は利用者の代わりに権威 DNS をたどって調べ、TTL の間答えを保存する
• 「反映待ち」はキャッシュ DNS に残った古い答えが期限切れになるのを待っている状態
• dig @権威DNS +norec と dig @キャッシュDNS を比べ、aa・ra のフラグと TTL を見る
• 自分で運用するなら役割を分け、再帰問い合わせは自分のネットワークだけに許可する

• NSレコードの仕組みとゾーン委任の設定
• DNSキャッシュポイズニングの対策