権威DNSサーバーとはなんなのか

権威DNSサーバーとは、特定のDNSゾーンについて正式な回答を返すDNSサーバーのことです。

たとえば、example.com というドメインを運用している場合、example.com や www.example.com、mail.example.com などに関するDNSレコードを管理し、問い合わせに対して正式な回答を返すDNSサーバーが、example.com の権威DNSサーバーです。

DNSの仕組みでは、ドメイン名をIPアドレスに変換したり、メールの配送先を調べたり、外部サービスの認証情報を確認したりします。その際に、最終的な正しい情報の参照元になるのが権威DNSサーバーです。

簡単にいうと、権威DNSサーバーは「そのドメインやDNSゾーンに関する公式の情報を持っているサーバー」です。

権威DNSサーバーの「権威」とは

正式な回答元であるという意味

DNSにおける「権威」とは、そのDNSゾーンについて正式に回答できる権限を持っているという意味です。

たとえば、ある会社の住所を知りたいとき、友人から聞いた情報よりも、会社の公式サイトや登記情報のほうが信頼できます。

DNSでも同じように、DNSキャッシュサーバーが一時的に保存している情報より、その情報の元になっている権威DNSサーバーの回答が正式な情報源になります。

たとえば、www.example.com のIPアドレスを確認したい場合、最終的には example.com の権威DNSサーバーが持つDNSレコードに基づいて回答されます。

www.example.com → WebサーバーのIPアドレス

このように、特定のDNSゾーンについて「この情報が正式です」と回答する役割を持つのが権威DNSサーバーです。

「ドメイン」よりも正確には「ゾーン」単位で管理される

権威DNSサーバーを説明するとき、「ドメインのDNS情報を管理するサーバー」と表現されることがあります。

これは初心者向けにはわかりやすい説明ですが、より正確にはDNSゾーン単位で権威を持つサーバーです。

ゾーンとは、DNSで管理される範囲のことです。

たとえば、example.com というゾーンには、以下のようなレコードが含まれることがあります。

example.com
www.example.com
mail.example.com
blog.example.com

ただし、sub.example.com のようなサブドメインを別のDNSサーバーへ委任している場合、sub.example.com 配下は別のゾーンとして管理されることがあります。

そのため、厳密には以下のように理解すると正確です。

権威DNSサーバー = 特定のDNSゾーンについて正式な回答を返すDNSサーバー

権威DNSサーバーとDNSキャッシュサーバーの違い

権威DNSサーバーは正式な情報を返す

権威DNSサーバーは、特定のDNSゾーンについて正式なDNSレコードをもとに回答します。

たとえば、example.com の権威DNSサーバーであれば、example.com に関するAレコード、MXレコード、TXTレコードなどについて回答します。

つまり、権威DNSサーバーはDNS情報の公式な回答元です。

DNSキャッシュサーバーは利用者の代わりに問い合わせる

一方、DNSキャッシュサーバーは、利用者の端末の代わりにDNS情報を調べるサーバーです。

DNSキャッシュサーバーは、再帰リゾルバーとも呼ばれます。

ユーザーがWebサイトにアクセスするとき、通常はパソコンやスマートフォンが直接権威DNSサーバーへ問い合わせるわけではありません。

多くの場合、まずDNSキャッシュサーバーに問い合わせます。

利用者の端末
↓
DNSキャッシュサーバー・再帰リゾルバー
↓
必要に応じて各DNSサーバーへ問い合わせ

DNSキャッシュサーバーは、すでに情報を持っていればキャッシュから回答します。

情報を持っていなければ、ルートDNSサーバー、TLD DNSサーバー、権威DNSサーバーを順番にたどって情報を取得します。

両者の違い

権威DNSサーバーとDNSキャッシュサーバーの違いをまとめると、以下のようになります。

種類	主な役割	例
権威DNSサーバー	特定のDNSゾーンについて正式な回答を返す	Cloudflare DNS、Route 53、Xserver DNS、お名前.comのDNSなど
DNSキャッシュサーバー	利用者の代わりにDNS情報を調べ、結果を一時保存する	Google Public DNS、Cloudflare Resolver、プロバイダのDNS、社内DNSなど

権威DNSサーバーは「公式の回答元」、DNSキャッシュサーバーは「利用者の代わりに調べる窓口」と考えると理解しやすいです。

DNS問い合わせの流れ

ユーザーがWebサイトにアクセスする

たとえば、ユーザーがブラウザで以下のURLにアクセスするとします。

https://www.example.com/

ブラウザがWebサイトを表示するには、www.example.com に対応するIPアドレスを知る必要があります。

そこで、DNSによる名前解決が行われます。

まずDNSキャッシュサーバーへ問い合わせる

ユーザーの端末は、最初に設定されているDNSキャッシュサーバーへ問い合わせます。

www.example.com のIPアドレスを教えてください

このDNSキャッシュサーバーは、インターネットプロバイダが提供するDNSサーバーの場合もあれば、Google Public DNSやCloudflareのDNSなどの場合もあります。

キャッシュがあればすぐに回答する

DNSキャッシュサーバーがすでに www.example.com の情報を保存している場合、その情報を利用者に返します。

この場合、権威DNSサーバーまで問い合わせは行われません。

DNSキャッシュによって、名前解決の速度が速くなり、権威DNSサーバーへの負荷も軽減されます。

キャッシュがなければルートDNSサーバーへ問い合わせる

DNSキャッシュサーバーが情報を持っていない場合、まずルートDNSサーバーへ問い合わせます。

ルートDNSサーバーは、.com や .jp、.net などのトップレベルドメインを管理するDNSサーバーの情報を返します。

たとえば、www.example.com であれば、まず .com を管理するTLD DNSサーバーの情報を得ます。

TLD DNSサーバーへ問い合わせる

次に、DNSキャッシュサーバーは .com のTLD DNSサーバーへ問い合わせます。

TLD DNSサーバーは、example.com の権威DNSサーバーに関する情報を返します。

example.com の情報は、この権威DNSサーバーに問い合わせてください

このように、TLD DNSサーバーは対象ドメインの権威DNSサーバーへ案内する役割を持っています。

権威DNSサーバーへ問い合わせる

最後に、DNSキャッシュサーバーは example.com の権威DNSサーバーへ問い合わせます。

www.example.com のIPアドレスを教えてください

権威DNSサーバーは、自分が管理するゾーン情報をもとに回答します。

www.example.com のIPアドレスは、指定されたWebサーバーのIPアドレスです

この回答がDNSキャッシュサーバーに返され、さらに利用者の端末へ返されます。

取得した情報は一定時間キャッシュされる

DNSキャッシュサーバーは、権威DNSサーバーから取得した情報を一定時間保存します。

この保存時間を決めるのがTTLです。

同じ問い合わせが再び来た場合、TTLの範囲内であれば、DNSキャッシュサーバーは権威DNSサーバーへ再問い合わせせず、キャッシュ済みの情報を返します。

権威DNSサーバーが管理する主なDNSレコード

Aレコード

Aレコードは、ドメイン名やホスト名をIPv4アドレスに対応させるレコードです。

example.com → 192.0.2.10

Webサイトを表示するためによく使われます。

たとえば、example.com にアクセスしたユーザーを特定のWebサーバーへ向けたい場合、AレコードでIPv4アドレスを指定します。

AAAAレコード

AAAAレコードは、ドメイン名やホスト名をIPv6アドレスに対応させるレコードです。

example.com → 2001:db8::1

IPv6環境でWebサイトやサービスに接続するために使われます。

AレコードがIPv4用であるのに対し、AAAAレコードはIPv6用です。

CNAMEレコード

CNAMEレコードは、あるホスト名を別のホスト名の別名として設定するレコードです。

www.example.com → example.com

また、外部サービスやCDNを利用するときにもよく使われます。

blog.example.com → example.hatenablog.com
shop.example.com → example-shop.service.com

CNAMEレコードを使うと、直接IPアドレスを指定するのではなく、別のホスト名を参照できます。

ただし、CNAMEには重要な注意点があります。

同じ名前にCNAMEレコードと他のレコードを同時に設定することは基本的にできません。

たとえば、以下のような設定は避ける必要があります。

www.example.com CNAME example.com
www.example.com A 192.0.2.10

また、example.com のようなゾーンapex、つまりルートドメインには、通常のCNAMEを設定できません。

ゾーンapexにはSOAレコードやNSレコードが必要です。

一方で、CNAMEは同じ名前の他のレコードと共存できないためです。

そのため、DNSサービスによっては以下のような代替機能を提供している場合があります。

ALIASレコード
ANAMEレコード
CNAME flattening

MXレコード

MXレコードは、メールの配送先サーバーを指定するレコードです。

example.com → mail.example.com

独自ドメインでメールを利用する場合、MXレコードの設定が必要です。

たとえば、以下のようなサービスを使う場合にもMXレコードを設定します。

Google Workspace
Microsoft 365
独自メールサーバー
レンタルサーバーのメール機能

MXレコードが正しく設定されていないと、メールが届かない、または配送に失敗する可能性があります。

TXTレコード

TXTレコードは、DNS上にテキスト情報を登録するためのレコードです。

もともとは任意のテキスト情報を登録する用途のレコードですが、現在では各種認証やメールセキュリティ設定でよく使われます。

代表的な用途は以下です。

SPF
DKIM
DMARC
Google Search Consoleの所有権確認
SSL証明書のDNS認証
外部サービスのドメイン認証
メール配信サービスの認証

Webサイト運用やWebマーケティングの現場では、TXTレコードを設定する場面が非常に多くあります。

たとえば、Google Search Consoleでドメインプロパティを認証する場合や、メール配信ツールで送信ドメイン認証を行う場合などです。

NSレコード

NSレコードは、そのゾーンの権威DNSサーバーを示すレコードです。

example.com の権威DNSサーバーは ns1.example-dns.com です

DNSの問い合わせでは、親ゾーン側に登録されたNS情報が重要です。

たとえば、example.com の場合、.com 側に「example.com の権威DNSサーバーはどこか」という情報が登録されています。

DNSキャッシュサーバーは、その情報をもとに example.com の権威DNSサーバーへたどり着きます。

また、example.com のゾーン内にもNSレコードがあります。

親ゾーン側のNS情報と、子ゾーン側のNS情報は、基本的に整合していることが望ましいです。

SOAレコード

SOAレコードは、そのゾーンに関する基本情報を示すレコードです。

SOAは「Start of Authority」の略です。

SOAレコードには、主に以下のような情報が含まれます。

プライマリDNSサーバー
管理者情報
シリアル番号
更新間隔
再試行間隔
有効期限
ネガティブキャッシュTTL

通常のWebサイト運用では、SOAレコードを直接編集する機会は多くありません。

しかし、DNSゾーンの基本情報として重要なレコードです。

CAAレコード

CAAレコードは、そのドメインについてSSL/TLS証明書を発行できる認証局を指定するレコードです。

たとえば、特定の認証局だけに証明書発行を許可したい場合に使われます。

CAAレコードは必須ではありませんが、セキュリティを高める目的で設定されることがあります。

権威DNSサーバーとNSレコードの関係

権威DNSサーバーはNSレコードで示される

権威DNSサーバーは、NSレコードによって示されます。

たとえば、example.com のNSレコードが以下のようになっているとします。

example.com.  NS  ns1.example-dns.com.
example.com.  NS  ns2.example-dns.com.

この場合、example.com の権威DNSサーバーは以下です。

ns1.example-dns.com
ns2.example-dns.com

複数のNSレコードを設定することで、冗長性を高めることができます。

親ゾーンの委任情報が重要

権威DNSサーバーを理解するうえでは、親ゾーンの委任情報が重要です。

たとえば、example.com の場合、親ゾーンは .com です。

.com 側に以下のような情報が登録されていることで、DNSキャッシュサーバーは example.com の権威DNSサーバーへたどり着けます。

example.com の情報は ns1.example-dns.com に問い合わせてください
example.com の情報は ns2.example-dns.com に問い合わせてください

このように、親ゾーンが子ゾーンの権威DNSサーバーを示すことを委任といいます。

親ゾーンと子ゾーンのNS情報は整合している必要がある

DNSでは、親ゾーン側に登録されたNS情報と、子ゾーン側に設定されたNSレコードが存在します。

たとえば、親ゾーン側では以下のようになっているとします。

example.com. NS ns1.example-dns.com.
example.com. NS ns2.example-dns.com.

しかし、子ゾーン側では以下のようになっている場合があります。

example.com. NS ns3.example-dns.com.
example.com. NS ns4.example-dns.com.

このように親ゾーンと子ゾーンのNS情報が大きく異なると、DNS診断ツールで警告が出たり、運用上の混乱につながったりすることがあります。

そのため、権威DNSサーバーを変更するときは、親ゾーン側の設定とDNSゾーン内のNSレコードの整合性を確認することが重要です。

グルーレコードとは

ネームサーバー名の解決に必要な補助情報

グルーレコードとは、権威DNSサーバーのホスト名を解決するために、親ゾーン側に登録される補助的なAレコードまたはAAAAレコードのことです。

たとえば、example.com の権威DNSサーバーが以下だったとします。

ns1.example.com
ns2.example.com

この場合、example.com の情報を調べるためには、まず ns1.example.com のIPアドレスを知る必要があります。

しかし、ns1.example.com は example.com の配下にあります。

つまり、以下のような循環が起こります。

example.com の権威DNSサーバーを知りたい
↓
ns1.example.com に聞けばよい
↓
では ns1.example.com のIPアドレスは？
↓
example.com のDNS情報を見ないとわからない

この循環を避けるために、親ゾーン側に ns1.example.com のIPアドレスを補助的に登録します。

これがグルーレコードです。

すべてのケースで必要になるわけではない

グルーレコードは、権威DNSサーバーのホスト名が管理対象ドメインの内側にある場合に必要になります。

たとえば、以下のようなケースです。

対象ドメイン：example.com
権威DNSサーバー：ns1.example.com

一方、権威DNSサーバーが外部ドメインの場合は、通常グルーレコードは不要です。

対象ドメイン：example.com
権威DNSサーバー：ns1.example-dns.net

この場合、ns1.example-dns.net のIPアドレスは、example-dns.net 側のDNSで解決できるためです。

TTLとは

DNSレコードをキャッシュできる時間

TTLとは、DNSレコードをキャッシュしてよい時間を示す値です。

TTLは「Time To Live」の略です。

たとえば、AレコードのTTLが以下のように設定されているとします。

3600秒

これは、DNSキャッシュサーバーがその情報を原則として3600秒、つまり1時間キャッシュできることを意味します。

TTLが有効な間は、DNSキャッシュサーバーは同じ問い合わせに対して、権威DNSサーバーへ再問い合わせせずにキャッシュ済みの情報を返せます。

TTLが短い場合と長い場合の違い

TTLが短い場合、DNS変更後に新しい情報へ切り替わりやすくなります。

たとえば、TTLを300秒にしておくと、理論上は5分程度でキャッシュが期限切れになります。

一方で、TTLが短いと権威DNSサーバーへの問い合わせ回数が増えやすくなります。

TTLが長い場合、DNSキャッシュの効率はよくなります。

しかし、DNSレコードを変更したあとも、古い情報が長く残る可能性があります。

たとえば、TTLが86400秒であれば、最大で24時間程度、古い情報がキャッシュされる可能性があります。

実際の反映タイミングには環境差がある

DNSキャッシュサーバーは、原則としてTTLに従って情報をキャッシュします。

ただし、実際の反映タイミングには環境差があります。

たとえば、以下のような要素が影響することがあります。

DNSキャッシュサーバーの挙動
OSのDNSキャッシュ
ブラウザのキャッシュ
アプリケーション側のキャッシュ
ネットワーク機器のキャッシュ
CDNやプロキシの影響

そのため、DNSレコードを変更したあと、ある環境では新しい情報が見えているのに、別の環境では古い情報が見えていることがあります。

ネガティブキャッシュとは

「存在しない」という結果もキャッシュされる

DNSでは、レコードが存在しないという結果も一定時間キャッシュされることがあります。

これをネガティブキャッシュといいます。

たとえば、まだ存在しない以下のサブドメインにアクセスしたとします。

test.example.com

この時点でDNSレコードが存在しなければ、「その名前は存在しない」という結果が返されます。

その後、すぐに test.example.com のAレコードを追加しても、一部のDNSキャッシュサーバーでは、しばらく「存在しない」という結果が残っている場合があります。

新しいサブドメイン追加時に影響することがある

ネガティブキャッシュは、新しいサブドメインを追加した直後のトラブルで関係することがあります。

たとえば、以下のようなケースです。

新しいLP用に lp.example.com を作成する
DNSレコードを追加する前に、誰かが lp.example.com へアクセスする
存在しないという結果がキャッシュされる
DNSレコード追加後も、一部環境で名前解決できない

このような場合は、しばらく時間を置くことで解消されることがあります。

「DNSの浸透」と権威DNSサーバーの関係

DNS情報が世界中に配られているわけではない

DNS変更時に「DNSが浸透するまで待つ」という表現が使われることがあります。

しかし、厳密にはDNS情報が世界中のサーバーへ順番に配布されているわけではありません。

実際に起きている主な現象は、以下です。

DNSキャッシュサーバーに残っている古い情報が、TTL切れによって更新されていく

つまり、「DNSの浸透」と呼ばれているものの多くは、キャッシュの更新タイミングの違いです。

権威DNSサーバー変更時は旧NS情報が残ることがある

権威DNSサーバーを変更すると、親ゾーンに登録されている委任情報が変わります。

たとえば、以下のように変更したとします。

変更前：ns1.old-dns.com / ns2.old-dns.com
変更後：ns1.new-dns.com / ns2.new-dns.com

このとき、すべてのDNSキャッシュサーバーがすぐに新しい権威DNSサーバーを参照するわけではありません。

変更前のNS情報をキャッシュしているDNSキャッシュサーバーは、TTLが切れるまで旧DNSサーバーを参照することがあります。

そのため、しばらくの間は以下のような状態になることがあります。

ある環境では旧DNSサーバーを見ている
別の環境では新DNSサーバーを見ている

これが、DNS変更後に環境によって表示結果が異なる原因のひとつです。

権威DNSサーバーはどこで設定するのか

ドメイン管理会社でネームサーバーを設定する

権威DNSサーバーは、通常、ドメイン管理会社の管理画面で設定します。

たとえば、ドメインを取得したサービスで、ネームサーバーとして以下のような値を指定します。

ns1.example-dns.com
ns2.example-dns.com

この設定により、インターネット上では以下のように扱われます。

example.com のDNS情報は ns1.example-dns.com / ns2.example-dns.com に問い合わせる

つまり、ドメイン管理会社のネームサーバー設定は、どのDNSサービスを権威DNSサーバーとして使うかを決める重要な設定です。

ドメイン管理会社とDNS管理サービスは同じとは限らない

ドメインを取得した会社と、実際にDNSレコードを管理するサービスは同じとは限りません。

たとえば、以下のような構成があります。

ドメイン取得：お名前.com
DNS管理：Cloudflare
Webサーバー：Xserver

この場合、AレコードやTXTレコードを変更する場所は、お名前.comのDNS管理画面ではなく、Cloudflare側の管理画面です。

ドメインを取得した会社でDNSを編集すればよいとは限らないため、まず現在の権威DNSサーバーを確認することが重要です。

DNSレコードを変更すべき場所を間違えない

実務でよくあるミスが、DNSレコードを変更する場所を間違えることです。

たとえば、権威DNSサーバーがCloudflareに設定されているにもかかわらず、ドメイン管理会社側のDNS管理画面でAレコードを変更しても、実際の名前解決には反映されません。

DNSレコードを変更するときは、必ず以下を確認しましょう。

現在の権威DNSサーバーはどこか
実際にDNSレコードを管理しているサービスはどこか
変更したいレコードはその管理画面に存在しているか

権威DNSサーバーを変更するときの注意点

事前にDNSレコードを移行しておく

権威DNSサーバーを変更する前に、現在使っているDNSレコードを新しいDNSサービス側へ登録しておく必要があります。

移行すべき主なレコードは以下です。

Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
NSレコード
CAAレコード
SRVレコード

特に、以下のレコードは見落とすと影響が大きくなります。

Webサイト表示用のAレコード
www用のCNAMEレコード
メール配送用のMXレコード
SPF/DKIM/DMARC用のTXTレコード
Google Search Console認証用のTXTレコード
SSL証明書認証用のDNSレコード
外部サービス連携用のDNSレコード

権威DNSサーバーを切り替えたあとに必要なレコードが登録されていないと、Webサイトが表示されない、メールが届かない、サービス認証が失敗するといったトラブルにつながります。

メール関連レコードを忘れない

権威DNSサーバーの変更時に特に注意したいのが、メール関連レコードです。

WebサイトのAレコードだけを移行し、MXレコードやTXTレコードを移行し忘れるケースがあります。

メール関連レコードが不足すると、以下のような問題が起こる可能性があります。

メールが届かない
メール送信に失敗する
メールが迷惑メールに入りやすくなる
SPF認証に失敗する
DKIM署名が認証されない
DMARC判定に失敗する
メール配信サービスの認証が通らない

Google Workspace、Microsoft 365、メール配信ツール、MAツールなどを使っている場合は、MXレコードとTXTレコードを必ず確認しましょう。

切り替え前にTTLを短くしておく

権威DNSサーバーやDNSレコードを変更する前に、TTLを短くしておくと、変更後のキャッシュ影響を小さくしやすくなります。

たとえば、変更の数日前にTTLを以下のように変更します。

86400秒 → 300秒

これにより、変更後に古い情報が残る時間を短くしやすくなります。

ただし、すでに長いTTLでキャッシュされている情報は、そのTTLが切れるまで残る可能性があります。

そのため、切り替え直前にTTLを短くしても、すぐには効果が出ない場合があります。

TTLを短くする場合は、余裕を持って事前に設定しておくことが重要です。

旧DNSサーバーをすぐに削除しない

権威DNSサーバーを変更した直後は、一部のDNSキャッシュサーバーがまだ旧DNSサーバーを参照している可能性があります。

そのため、切り替え後すぐに旧DNSサーバー側のDNSレコードを削除したり、旧DNSサービスを解約したりするのは避けたほうが安全です。

旧DNSサーバーをすぐに停止すると、旧NS情報を参照している環境で名前解決に失敗することがあります。

権威DNSサーバー変更後もしばらくは、旧DNSサーバー側にも同じDNSレコードを残しておくと安全です。

DNSSECを利用している場合は慎重に作業する

DNSSECを利用しているドメインでは、権威DNSサーバー変更時に特に注意が必要です。

DNSSECでは、DNS情報の正当性を検証するために、DSレコードやDNSKEY、署名情報などが関係します。

設定に不整合があると、DNSSEC検証に失敗し、ドメインが正しく名前解決できなくなることがあります。

たとえば、新しいDNSサービス側でDNSSECの設定が完了していないにもかかわらず、親ゾーン側に古いDSレコードが残っていると、検証エラーが発生する可能性があります。

DNSSECを有効にしている場合は、通常のDNS移行よりも慎重に手順を確認しましょう。

プライマリDNSサーバーとセカンダリDNSサーバー

プライマリDNSサーバーとは

プライマリDNSサーバーとは、ゾーン情報の元データを管理するDNSサーバーです。

DNSレコードの追加、変更、削除は、通常プライマリDNSサーバー側で行います。

従来は「マスターDNSサーバー」と呼ばれることもありましたが、現在では「プライマリDNSサーバー」という表現が使われることが増えています。

セカンダリDNSサーバーとは

セカンダリDNSサーバーとは、プライマリDNSサーバーからゾーン情報を転送して保持するDNSサーバーです。

セカンダリDNSサーバーを用意することで、冗長性や可用性を高められます。

たとえば、以下のように複数のDNSサーバーを設定します。

ns1.example-dns.com
ns2.example-dns.com
ns3.example-dns.com

このように複数の権威DNSサーバーを用意しておけば、一部のサーバーに障害が発生しても、他のサーバーが応答できます。

DNSホスティングでは意識しないことも多い

自前でDNSサーバーを運用する場合は、プライマリDNSサーバーとセカンダリDNSサーバーを意識することがあります。

一方、Cloudflare、Amazon Route 53、Google Cloud DNS、Azure DNSなどのDNSホスティングサービスを使う場合、利用者は管理画面でDNSレコードを編集するだけで、裏側のプライマリ・セカンダリ構成を直接意識しないことも多いです。

実務上は、以下のように考えるとわかりやすいです。

自前DNS運用：プライマリ・セカンダリ構成を意識することがある
DNSホスティング利用：管理画面でDNSレコードを編集することが多い

権威DNSサーバーの確認方法

NSレコードを確認する

権威DNSサーバーは、NSレコードを確認することで調べられます。

代表的な確認方法は dig コマンドです。

dig example.com NS

より簡潔に表示したい場合は、以下のようにします。

dig example.com NS +short

結果が以下のように表示された場合、

ns1.example-dns.com.
ns2.example-dns.com.

example.com の権威DNSサーバーは、ns1.example-dns.com と ns2.example-dns.com です。

権威DNSサーバーへ直接問い合わせる

権威DNSサーバーがわかっている場合は、そのサーバーへ直接問い合わせることもできます。

dig @ns1.example-dns.com example.com A

これは、ns1.example-dns.com に対して、example.com のAレコードを直接問い合わせるコマンドです。

DNSキャッシュサーバーを経由せず、権威DNSサーバー側でどの値が返っているかを確認できます。

より明確に再帰問い合わせを使わない形で確認したい場合は、以下のようにします。

dig @ns1.example-dns.com example.com A +norecurse

DNS変更後のトラブル調査では、権威DNSサーバーが新しい値を返しているかどうかを確認することが重要です。

パブリックDNSでの見え方を確認する

DNS変更後は、パブリックDNSでの見え方も確認すると便利です。

たとえば、Google Public DNSへ問い合わせる場合は以下です。

dig @8.8.8.8 example.com A

CloudflareのDNSへ問い合わせる場合は以下です。

dig @1.1.1.1 example.com A

このように複数のDNSキャッシュサーバーで確認すると、どの環境で新しい情報が返っているか、どの環境で古い情報が残っているかを切り分けやすくなります。

dig +trace で名前解決の流れを確認する

dig +trace を使うと、ルートDNSサーバーから権威DNSサーバーまでの名前解決の流れを確認できます。

dig +trace www.example.com

このコマンドでは、以下のような流れを追えます。

ルートDNSサーバー
↓
TLD DNSサーバー
↓
権威DNSサーバー

権威DNSサーバーの委任が正しく行われているかを確認したい場合に役立ちます。

権威DNSサーバーでよくあるトラブル

DNSレコードの移行漏れ

権威DNSサーバー変更時に最も多いトラブルが、DNSレコードの移行漏れです。

たとえば、新しいDNSサービス側にAレコードを登録していないと、Webサイトが表示されなくなる可能性があります。

また、MXレコードを登録していないと、メールが届かなくなる可能性があります。

特に注意すべきレコードは以下です。

Aレコード
AAAAレコード
CNAMEレコード
MXレコード
TXTレコード
CAAレコード

DNSサービスを変更するときは、旧DNS側のレコード一覧を確認し、新DNS側に必要なレコードがすべて登録されているかチェックしましょう。

DNSレコードを変更する管理画面を間違える

DNSレコードの変更先を間違えるトラブルもよくあります。

たとえば、ドメインはお名前.comで取得していても、権威DNSサーバーがCloudflareになっている場合、DNSレコードを変更すべき場所はCloudflareです。

お名前.com側のDNS管理画面でAレコードやTXTレコードを変更しても、Cloudflareが権威DNSサーバーになっていれば、その変更は実際の名前解決には使われません。

DNS設定を変更する前には、必ず現在のNSレコードを確認しましょう。

親ゾーンと子ゾーンのNS情報が一致していない

親ゾーン側のNS情報と、子ゾーン側のNSレコードが一致していない場合、DNS診断ツールで警告が出ることがあります。

すぐに障害になるとは限りませんが、運用上の混乱を避けるためにも、権威DNSサーバーを変更したあとはNS情報の整合性を確認するのがおすすめです。

TTLが長く、古い情報が残る

TTLが長い状態でDNSレコードを変更すると、古い情報が長時間キャッシュされることがあります。

たとえば、AレコードのTTLが86400秒の場合、DNSキャッシュサーバーによっては最大24時間程度、古いIPアドレスを返し続ける可能性があります。

サーバー移転やメールサーバー切り替えなど、影響の大きい変更を行う場合は、事前にTTLを短くしておくと安全です。

CNAMEの設定ミス

CNAMEレコードの設定ミスもよくあります。

特に注意したいのは、以下の2点です。

同じ名前にCNAMEと他のレコードを同時に設定しない
ゾーンapexに通常のCNAMEを設定しない

たとえば、以下のような設定は問題になる可能性があります。

www.example.com CNAME example.com
www.example.com A 192.0.2.10

CNAMEを設定する場合は、同じホスト名に他のレコードが設定されていないか確認しましょう。

DNSSECの設定ミス

DNSSECを利用している場合、DSレコードやDNSKEY、署名情報の不整合によって名前解決に失敗することがあります。

特に、権威DNSサーバーを変更するときは注意が必要です。

DNSSECの設定を誤ると、DNSSEC検証を行うリゾルバーではドメインが正しく解決できなくなる可能性があります。

DNSSECを有効にしているドメインでは、DNSサービス変更時の手順を事前に確認しておきましょう。

Webサイト運用で権威DNSサーバーが重要になる場面

サーバー移転

Webサーバーを移転するときは、AレコードやAAAAレコード、CNAMEレコードを変更します。

このとき、現在の権威DNSサーバーがどこかを把握していないと、どの管理画面でDNSレコードを変更すべきかわかりません。

たとえば、以下のような構成は珍しくありません。

ドメイン取得：お名前.com
DNS管理：Cloudflare
Webサーバー：Xserver

この場合、WebサーバーのIPアドレスを変更するには、Cloudflare側でAレコードを変更する必要があります。

CDN導入

Cloudflare、Fastly、AkamaiなどのCDNを導入する場合も、DNS設定が関係します。

CDNの導入方法には、主に以下のようなパターンがあります。

ネームサーバーをCDN事業者のものに変更する
CNAMEでCDN側のホスト名に向ける
AレコードでCDN側のIPアドレスに向ける

どの方法を使う場合でも、現在の権威DNSサーバーを確認し、正しいDNS管理画面で設定する必要があります。

メール配信・メール認証

メール配信システムやMAツールを導入すると、DNS設定が必要になることがよくあります。

特に、以下のような認証設定ではTXTレコードやCNAMEレコードを追加します。

SPF
DKIM
DMARC
Return-Path
送信ドメイン認証

これらの設定を誤ると、メールが迷惑メールに入りやすくなったり、配信サービス側で認証エラーになったりすることがあります。

DNSレコードを追加するときは、現在の権威DNSサーバー側に設定しているかを確認しましょう。

Google Search Consoleの所有権確認

Google Search Consoleでドメインプロパティを認証する場合、TXTレコードをDNSに追加します。

このときも、現在の権威DNSサーバー側にTXTレコードを追加する必要があります。

ドメインを取得した会社の管理画面に追加すればよいとは限りません。

たとえば、権威DNSサーバーがCloudflareであれば、Cloudflare側にGoogle Search ConsoleのTXTレコードを追加します。

SSL証明書のDNS認証

SSL/TLS証明書を発行するとき、DNS認証を使う場合があります。

DNS認証では、指定されたTXTレコードやCNAMEレコードをDNSに追加し、ドメインの所有権を確認します。

この場合も、設定先は現在の権威DNSサーバーです。

誤ったDNS管理画面に認証用レコードを追加しても、認証局からは確認できず、証明書の発行に失敗することがあります。

権威DNSサーバーを理解するためのたとえ

権威DNSサーバーは公式の住所録

権威DNSサーバーは、公式の住所録のような存在です。

たとえば、ある会社の所在地を確認したいとき、公式の住所録に書かれている情報が最も信頼できます。

DNSでも同じように、ドメイン名に対応するIPアドレスやメールサーバーの情報について、正式な回答を持っているのが権威DNSサーバーです。

権威DNSサーバー = 公式の住所録

DNSキャッシュサーバーは住所録を一時的にメモしている人

一方、DNSキャッシュサーバーは、公式の住所録を見て一時的にメモしている人のような存在です。

DNSキャッシュサーバー = 公式の住所録を見て、一時的にメモしている人

メモが新しければ問題ありませんが、住所が変更された直後は古いメモを見ている可能性があります。

これが、DNS変更後に一部の環境で古い情報が返る理由です。

権威DNSサーバーを確認・変更するときのチェックリスト

現在の権威DNSサーバーを確認する

まず、現在どのDNSサーバーが権威DNSサーバーになっているか確認します。

dig example.com NS +short

ここで表示されたネームサーバーが、現在そのドメインの権威DNSサーバーです。

DNSレコードの管理画面を特定する

次に、表示されたネームサーバーがどのDNSサービスのものかを確認します。

たとえば、以下のように判断します。

CloudflareのNS → CloudflareでDNSレコードを変更する
Route 53のNS → AWS Route 53でDNSレコードを変更する
XserverのNS → XserverでDNSレコードを変更する
お名前.comのNS → お名前.com側でDNSレコードを変更する

DNSレコードの変更は、現在の権威DNSサーバーを提供しているDNSサービス側で行います。

変更前に既存レコードを確認する

権威DNSサーバーを変更する場合は、既存のDNSレコードを事前に確認します。

特に以下は必ず確認しましょう。

Webサイト用のA/AAAA/CNAMEレコード
メール用のMXレコード
SPF/DKIM/DMARC用のTXTレコード
SSL証明書認証用のレコード
Google Search Consoleなどの認証用TXTレコード
外部サービス連携用のレコード

必要なレコードを新しいDNSサービス側へ登録してから、ネームサーバーを切り替えるのが安全です。

切り替え後に複数のDNSで確認する

DNS変更後は、複数のDNSキャッシュサーバーで結果を確認します。

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

さらに、権威DNSサーバーへ直接問い合わせると、設定自体が正しいか確認できます。

dig @ns1.example-dns.com example.com A

これにより、以下を切り分けられます。

権威DNSサーバーでは正しい値が返っているか
Google Public DNSでは新しい値になっているか
Cloudflare DNSでは新しい値になっているか
自分の環境だけ古いキャッシュを見ていないか

まとめ

権威DNSサーバーとは、特定のDNSゾーンについて正式な回答を返すDNSサーバーです。

Webサイトの表示、メール送受信、SSL証明書の認証、Google Search Consoleの所有権確認、メール配信サービスの認証など、さまざまな場面で重要な役割を持っています。

特に重要なポイントは以下です。

権威DNSサーバーは、DNSゾーンについて正式な回答を返す
DNSキャッシュサーバー・再帰リゾルバーとは役割が違う
NSレコードによって権威DNSサーバーが示される
実際の委任では、親ゾーン側のNS情報が重要になる
DNSレコードの変更は、現在の権威DNSサーバー側で行う
DNS変更後の反映差は、主にTTLやキャッシュによって起きる
権威DNSサーバー変更時は、DNSレコードの移行漏れに注意する

実務では、DNS設定を変更する前に、まず現在の権威DNSサーバーを確認することが大切です。

dig example.com NS +short

このコマンドで現在のネームサーバーを確認し、実際にDNSレコードを編集すべき管理画面を特定できます。

権威DNSサーバーを正しく理解しておくと、サーバー移転、メール設定、CDN導入、外部サービス連携などのDNSトラブルを防ぎやすくなります。

以上、権威DNSサーバーとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。