権威DNSサーバーは、自分のドメインの「正しい答え」を世界中に返す役割を持つため、ここで問題が起きるとサイトもメールも同時に使えなくなります。リスクは大きく「止まる」「悪用される」「乗っ取られる」「設定の誤りで引けなくなる」の4つに分けられ、多くは dig で外から確かめられます。この記事では、権威DNSを自分で運用する場合と DNS 事業者に任せる場合の両方について、それぞれのリスクの中身、確認のコマンド、対策を順に説明します。
権威DNSとキャッシュDNSの役割の違いは別の記事で扱っているため、ここでは権威DNSに固有のリスクに絞ります。
リスク1：権威DNSが止まると、名前解決ができなくなる
キャッシュDNSサーバーは、受け取った答えを TTL の間だけ保持します。権威DNSサーバーがすべて応答しなくなると、TTL が切れた名前から順に引けなくなり、サイト・メール・API の通信が止まります。過去には大手の DNS 事業者が大規模な DDoS 攻撃を受け、その事業者だけに権威DNSを任せていた多くのサービスが同時に使えなくなった事例もあります。
確かめ方：ドメインの NS レコードを見て、ネームサーバーが別々のネットワークに分かれているかを確かめます。
# 登録されているネームサーバーの一覧
dig example.com NS +short
# 各ネームサーバーのアドレス（同じネットワークに偏っていないか）
dig ns1.example.net A +short
dig ns2.example.net A +short対策：
- ネームサーバーは最低2台、できれば別の場所・別のネットワークに置きます。自前運用なら、同じデータセンターの2台では冗長化として不十分です。
- 事業者に任せる場合は、その事業者が分散配置（エニーキャストなど）をしているかを確かめます。さらに高い可用性が必要なら、2つの事業者に同じゾーンを置く構成もありますが、両方のレコードを同じ内容に保つ運用の手間が増えます。
リスク2：再帰問い合わせやゾーン転送を開けたままにする
自前で権威DNSを運用するときに起きやすいのが、設定の開けすぎです。
再帰問い合わせに答えてしまう
権威DNSサーバーが、他人のドメインについての問い合わせにも答える（再帰問い合わせを受け付ける）設定になっていると、「オープンリゾルバー」として DNS の反射・増幅攻撃に使われるおそれがあります。
確かめ方：外部のネットワークから、自分の権威サーバーに無関係なドメインを問い合わせます。
dig @ns1.example.net www.example.org A応答の flags に ra（再帰が使える）が付き、答えが返ってくる場合は再帰を受け付けています。REFUSED が返るか、答えが無ければ問題ありません。
ゾーン転送（AXFR）を誰にでも許す
ゾーン転送は、セカンダリサーバーにゾーンの全レコードを渡す仕組みです。誰にでも許していると、社内向けの名前やステージング環境のホスト名など、公開するつもりのない一覧を丸ごと取得されます。
dig @ns1.example.net example.com AXFR外部から実行して Transfer failed. などで拒否されれば正常です。レコードの一覧が表示されたら、すぐに制限します。
対策（BIND の例）：権威専用のサーバーでは再帰を止め、ゾーン転送はセカンダリのアドレスだけに許します。設定を変える前に設定ファイルを控え、named-checkconf で文法を確かめてから再読み込みします。
options {
recursion no; // 権威専用なら再帰を止める
allow-transfer { 192.0.2.54; }; // セカンダリのアドレスだけに許す
rate-limit { // 応答の量を抑えて増幅に使われにくくする
responses-per-second 10;
};
};NSD や Knot DNS、PowerDNS などでも同じ考え方の設定項目があります。名前と書き方はソフトウェアと版で違うため、使っているソフトウェアのドキュメントで確かめてください（2026年10月現在）。
リスク3：アカウントや委任が乗っ取られる
DNS 事業者・レジストラのアカウントの乗っ取り
権威DNSの管理画面に入られると、A レコードや MX レコードを書き換えられ、サイトやメールを第三者のサーバーへ向けられます。レジストラのアカウントなら、ネームサーバーそのものを差し替えられます。
対策：両方のアカウントで二要素認証を設定し、管理者を必要な人に限ります。退職者のアカウントや、共有パスワードの使い回しを残さないことも大切です。API トークンを使っている場合は、権限を必要なゾーンだけに絞ります。
使われなくなった CNAME（ダングリング CNAME）
shop.example.com が外部のサービスに CNAME で向いたまま、そのサービスの契約だけを解約すると、第三者が同じ名前でそのサービスに登録し、あなたのサブドメインでコンテンツを表示できてしまう場合があります（サブドメインの乗っ取り）。
確かめ方と対策：ゾーンの CNAME を一覧にし、向け先がまだ自分の契約で使われているかを確かめます。サービスを解約するときは、先に DNS のレコードを消してから解約する順番にします。
dig shop.example.com CNAME +shortリスク4：設定の誤りで引けなくなる
委任の不一致（レームデリゲーション）
親ゾーン（.com など）に登録した NS と、権威サーバーが実際に答える NS が食い違っていたり、登録したネームサーバーがそのゾーンを持っていなかったりすると、一部の問い合わせだけが失敗する不安定な状態になります。
# 親ゾーンからたどった委任の経路を表示する
dig example.com NS +trace
# 各ネームサーバーに直接聞き、権威のある答えか（flags に aa）を確かめる
dig @ns1.example.net example.com SOA +norec
dig @ns2.example.net example.com SOA +norec各ネームサーバーの SOA のシリアル番号が違う場合は、セカンダリへの同期が止まっています。
DNSSEC の署名切れや DS の不一致
DNSSEC を有効にしたゾーンで署名の期限が切れたり、親ゾーンに登録した DS レコードと鍵が合わなくなったりすると、検証を行うキャッシュDNSサーバーは答えを返さず、利用者からは SERVFAIL に見えます。
dig example.com A +dnssec
delv example.com Adelv で検証が失敗する場合は、鍵の更新手順と DS の登録状態を見直します。DNSSEC を止める場合は、先に親ゾーンの DS を削除し、その TTL が切れてから署名をやめる順番にします。逆の順番にすると、その間ドメインが引けなくなります。
TTL が長すぎて緊急の変更が間に合わない
TTL を長くすると問い合わせは減りますが、誤ったレコードを直しても、古い答えが長く残ります。移転や切り替えの予定があるときは、数日前に TTL を短くしておき、作業が終わって安定したら元に戻します。
日頃の点検
リスクの多くは、定期的に外から確かめるだけで早く見つけられます。NS と SOA のシリアルの一致、再帰とゾーン転送の拒否、DNSSEC の検証、CNAME の向け先を、四半期ごとなど決まった間隔で確認する手順を作っておくと安心です。自前運用なら、DNS サーバーのソフトウェアの脆弱性情報を追い、更新を後回しにしないことも欠かせません。
まとめ
- 権威DNSが止まると、TTL が切れた名前から順に引けなくなります。ネームサーバーは別のネットワークに分散させます。
- 自前運用では、再帰問い合わせとゾーン転送を外部に開けないようにし、応答の量も制限します。
- 事業者とレジストラのアカウントは二要素認証で守り、解約したサービスに向いた CNAME を残さないようにします。
- 委任の不一致、DNSSEC の署名切れ、長すぎる TTL は dig と delv で外から確かめられます。変更の前には設定を控え、手順を確かめてから作業します。