DNSの冗長化について

DNSの冗長化とは、名前解決の仕組みが1台・1系統・1事業者に依存しないようにして、障害時でも継続して名前解決できるようにする設計のことです。

Webサイト、API、メール、社内システムなどは、最終的にDNSで名前解決できてはじめて目的のサーバーへ到達できます。

そのため、アプリケーションやサーバー本体が正常でも、DNSに障害が起きると、利用者からは「サービスに接続できない」状態に近く見えることがあります。

DNSの冗長化で重要なのは、単にDNSサーバーを複数台にすることではありません。

本質は、単一障害点をなくし、同時に止まる原因を減らすことにあります。

DNS冗長化の主な対象

DNSの冗長化は、大きく分けると次の2つの観点があります。

権威DNSの冗長化

権威DNSは、自社ドメインに対する正しいDNS情報を返すサーバーです。

たとえば example.com のAレコード、AAAAレコード、MXレコード、TXTレコードなどを管理します。

外部公開サービスで「DNSの冗長化」という場合、多くはこの権威DNSの冗長化を指します。

通常は、1つのドメインに対して複数のネームサーバーを登録し、そのいずれかに障害が起きても、他のネームサーバーが応答できるように構成します。

再帰DNSの冗長化

再帰DNSは、利用者端末や社内サーバーが名前解決のために参照するDNSリゾルバです。

たとえば、PCやサーバーのネットワーク設定で指定されるDNSサーバーがこれにあたります。

権威DNSが冗長化されていても、利用者側が参照する再帰DNSが1台しかなく、その1台が障害を起こせば、実際には名前解決できません。

そのため、公開サービスだけでなく、社内環境や基盤設計では再帰DNSの冗長化も重要です。

なぜDNSの冗長化が必要なのか

DNS冗長化の目的は、名前解決を止めないことです。

特に次のような障害に備えるために必要です。

単一障害点をなくすため

DNSサーバーが1台だけだと、そのサーバー障害、OS障害、設定ミス、ネットワーク断、クラウド障害などで名前解決が停止するおそれがあります。

DNSは多くのサービスの入口にあるため、影響範囲が広くなりやすいのが特徴です。

ネットワーク障害や経路障害に備えるため

サーバー自体が稼働していても、回線障害やルーティング障害で到達できなくなることがあります。

そのため、DNS冗長化ではサーバー台数だけでなく、拠点、回線、クラウドリージョン、ネットワーク事業者などの分散も重要になります。

DDoSや高負荷への耐性を高めるため

DNSは攻撃対象になりやすい基盤です。

複数拠点構成やAnycast対応のDNSサービスを利用すると、負荷分散や耐障害性の向上が期待できます。

メンテナンスしやすくするため

1台構成だと、メンテナンス中にそのままサービス影響が出る可能性があります。

冗長構成であれば、一部を停止しても継続運用しやすくなります。

権威DNS冗長化の基本的な考え方

もっとも基本的なのは、1つのドメインに対して複数の権威ネームサーバーを持つことです。

たとえば、次のように複数のNSレコードを登録します。

• ns1.example-dns.net
• ns2.example-dns.net
• ns3.example-dns.net

ここで重要なのは、見た目上サーバーが複数あるだけでは不十分だという点です。

複数のネームサーバーがあっても、実際には同じデータセンター、同じクラウドリージョン、同じネットワーク事業者、同じ運用系統に依存しているなら、広い意味では同じ障害で同時に止まる可能性があります。

つまり、DNS冗長化は台数の冗長化ではなく、障害要因の分離として考える必要があります。

「Primary / Secondary」はどう理解すべきか

DNSの説明では、よく Primary DNS と Secondary DNS という言い方が使われます。

一般的には次のような意味です。

• Primary: ゾーン情報を編集する元のサーバー
• Secondary: ゾーン転送によって同期されるサーバー

ただし、外部から見れば、どちらも権威DNSサーバーとして問い合わせに応答します。

つまり、Primary / Secondary という区別は、主に運用や同期の関係を示すものであって、利用者が見る公開上の役割をそのまま示すものではありません。

最近では、公開権威DNSの背後に編集専用の hidden primary を置き、外部には複数の公開権威DNSだけを見せる構成もよく使われます。

実際にどこへ問い合わせるのか

「複数の権威DNSがあるなら、クライアントはそのどれかに問い合わせる」と説明されることがありますが、厳密には少し単純化しすぎです。

多くの利用者端末は、直接権威DNSへ問い合わせるわけではありません。

通常は次のような流れです。

• 利用者端末のスタブリゾルバ
• 再帰DNSリゾルバ
• 権威DNSサーバー

そのため、実際に複数の権威DNSのうちどれへ問い合わせるかは、主に再帰リゾルバ側の実装やキャッシュ状況に依存します。

この点を理解しておくと、「NSが複数ある＝利用者が均等に使い分ける」という誤解を避けやすくなります。

権威DNS冗長化の代表的な方法

マネージドDNSサービスを使う

もっとも一般的な方法です。

多くのマネージドDNSサービスでは、複数の権威ネームサーバーが標準で提供され、背後で分散や可用性対策が行われています。

メリット

• 導入が容易
• 運用負荷が低い
• AnycastやDDoS耐性を持つことが多い
• 監視やインフラ管理を自前で抱えにくい

注意点

• その事業者自体の広域障害には影響を受ける可能性がある
• ベンダーロックインになりやすい
• 設定変更ミスやアカウント管理不備までは自動では防げない

自前でPrimary / Secondary構成を組む

BIND、NSD、Knot DNS、PowerDNSなどを使い、PrimaryからSecondaryへゾーン転送を行う方法です。

メリット

• 柔軟な設計ができる
• 詳細な制御が可能
• 要件次第ではコストを抑えられる

注意点

• 運用負荷が高い
• セキュリティ対策、監視、同期、障害対応を自前で整える必要がある
• DDoS耐性やグローバル分散は確保しにくい

マルチプロバイダDNS

異なるDNS事業者に同じゾーン情報を持たせる方式です。

1社の障害でドメイン全体が見えなくなるリスクを下げたい場合に有効です。

メリット

• 単一事業者障害への耐性が上がる
• 可用性設計の自由度が高い
• 重要サービスでは有力な選択肢になる

注意点

• 事業者ごとの機能差がある
• ゾーン情報の同期が難しい
• DNSSEC、ALIAS/ANAME、ヘルスチェック連携などで差異が出やすい
• 可用性は上がりやすいが、運用の複雑性も上がる

ゾーン転送と同期で注意すべきこと

自前でPrimary / Secondary構成を取る場合、ゾーン転送の設計が重要です。

主な転送方式は次の2つです。

• AXFR: ゾーン全体を転送
• IXFR: 差分のみ転送

Primaryでレコードを更新すると、SecondaryはSOAレコードのシリアル番号を確認し、更新が必要であればゾーンを取り込みます。

ここで特に重要なのが次の点です。

SOAシリアル管理

シリアル番号が正しく更新されないと、Secondaryが変更を取り込めません。

このミスは意外と多く、片系だけ古い情報を返す原因になります。

NOTIFY

PrimaryからSecondaryへ更新通知を送る仕組みです。

これにより、変更反映を早められます。

転送先制御

ゾーン転送を無制限に許可すると、不要な情報漏えいにつながることがあります。

転送は許可したSecondaryのみに限定するのが基本です。

TTLとDNS冗長化の関係

TTLは、DNS応答が再帰リゾルバなどにキャッシュされる時間です。

DNS冗長化やフェイルオーバー設計では非常に重要です。

TTLが長い場合

利点

• DNSサーバーへの問い合わせ回数を減らせる
• すでに正しい情報をキャッシュしている経路では、一時的な権威DNS障害の影響を緩和できる場合がある

注意点

• 切替時に新しい情報が反映されるまで時間がかかる
• 誤った情報を長く保持させてしまう可能性がある
• そもそも未キャッシュの利用者には効果がない

TTLが短い場合

利点

• レコード変更後の反映を早めやすい
• 切替後の情報が利用されるまでの時間を短縮しやすい

注意点

• DNSクエリ数が増える
• DNS基盤への依存が強くなる
• 実際の反映速度は再帰リゾルバの挙動やクライアント実装にも左右される

つまり、TTLを短くすれば何でも解決するわけではありません。

適切なTTLは、レコードの用途、変更頻度、障害時の切替要件に応じて設計する必要があります。

DNSサーバーの冗長化とフェイルオーバーは別物

ここは非常に重要です。

DNSサーバー自体の冗長化

これは、権威DNSが複数あり、そのうち一部が落ちても名前解決を継続できる状態を指します。

配信先のフェイルオーバー

これは、DNSレコードが指す先のIPアドレスやホストを障害時に切り替えることです。

たとえば、WebサーバーAが障害を起こしたら、Aレコードの向き先を待機系へ変更するような運用です。

この2つは別問題です。

DNS自体を冗長化しても、その先にあるWebサーバーやAPI基盤が単一構成なら、サービス全体としては高可用性になりません。

DNSベースのフェイルオーバーの限界

DNSによるフェイルオーバーは有効な場面もありますが、万能ではありません。

主な理由は次の通りです。

キャッシュが残る

レコードを書き換えても、再帰リゾルバに古い情報が残っていれば、すぐには切り替わりません。

検知と反映に時間がかかる

ヘルスチェックで障害を検知し、判定し、DNSを書き換え、その結果が各地に反映されるまでには時間差があります。

再帰リゾルバやクライアントの挙動差がある

TTLの扱い、prefetch、負のキャッシュなどにより、理論通りの時間で切り替わらないことがあります。

既存接続はそのまま救えない

DNSが新しいIPを返すようになっても、すでに張られている接続や失敗した通信が自動的に正常化するわけではありません。

このため、厳密な高可用性が必要なら、DNSだけでなく、ロードバランサ、CDN、Anycast、マルチリージョン構成、アプリケーション側の冗長化などを組み合わせるのが一般的です。

AnycastはなぜDNSでよく使われるのか

Anycastは、同じIPアドレスを複数拠点から広告し、ネットワーク上の経路に応じて到達先が決まる方式です。

DNSサービスでAnycastがよく使われる理由は次の通りです。

• 地理的・経路的に近い拠点へ到達しやすい
• 応答遅延を抑えやすい
• 負荷や攻撃を分散しやすい
• 一部拠点障害に対する耐性向上が期待できる

ただし、実際の到達先はBGP経路制御に依存するため、挙動が常に一定とは限りません。

それでも、大規模なDNS基盤で可用性と性能を両立しやすい技術として広く使われています。

DNSSECと冗長化の関係

DNSSECは、DNS応答の正当性を検証するための仕組みです。

冗長化とは別テーマですが、実運用では強く関係します。

複数の権威DNSや複数のDNS事業者で運用する場合、DNSSECの署名や鍵管理に不整合があると、単なる片系障害より深刻な名前解決失敗を起こすことがあります。

特に注意したいのは次の点です。

• 鍵管理の整合性
• 署名タイミングの差
• DSレコードと実際の鍵の整合
• プロバイダごとの実装差異

高可用性を高めるつもりで構成を複雑にした結果、DNSSEC運用ミスで全面障害になることもありえます。

そのため、冗長化ではインフラ構成だけでなく、運用の一貫性も極めて重要です。

Glueレコードにも注意が必要

ネームサーバー名が自ドメイン配下にある場合、たとえば次のような構成では注意が必要です。

• ns1.example.com
• ns2.example.com

この場合、親ゾーン側に登録されるGlueレコードが関係します。

Glueが不整合だったり、正しく登録・更新されていなかったりすると、権威DNSにたどり着く前の段階で問題が起きることがあります。

DNS冗長化を考える際は、権威DNSそのものだけでなく、親子委任やGlueの整合性まで確認することが重要です。

再帰DNSの冗長化で注意すること

社内環境やサーバー環境では、再帰DNSの冗長化も欠かせません。

ただし、「DNSサーバーを2台設定すれば自動できれいに冗長化される」と考えるのは危険です。

多くのクライアントOSは、複数のDNSサーバーを必ずしも均等に使うわけではなく、順次フォールバック的に扱うことがあります。

そのため、次のような観点で設計・確認する必要があります。

• 2台以上のリゾルバを用意する
• 可能なら別ホスト、別ハイパーバイザ、別拠点に分散する
• 応答遅延やキャッシュ効率も監視する
• DHCPやネットワーク設定が実質片系依存になっていないか確認する

よくある誤解

NSが2つあれば安全

必ずしもそうではありません。

同じ事業者、同じ拠点、同じ設定ミスの影響を受けるなら、本質的には同じ障害要因を共有しています。

TTLを短くすれば即時切替できる

TTLを短くすると反映を早めやすくはなりますが、再帰リゾルバやクライアントの挙動、検知時間、既存接続の状態などに左右されます。

即時切替を保証するものではありません。

DNS冗長化をすればサービス全体が冗長化される

DNSが引けても、その先のアプリケーションやネットワークが単一構成なら停止します。

DNS冗長化は、あくまで可用性の一部です。

マネージドDNSを使えば完全に安全

自前運用より強いことは多いですが、事業者障害、設定ミス、権限管理不備、運用事故まですべて解決してくれるわけではありません。

実務での考え方

小〜中規模サイト

• 信頼できるマネージドDNSを利用する
• 複数NSが提供される構成を選ぶ
• DNS変更手順を整理する
• 極端すぎるTTL設定を避ける
• 外形監視とレコード監視を入れる

この規模では、自前で権威DNSを構築するより、実績のあるマネージドDNSを使う方が現実的なことが多いです。

中〜大規模サービス

• マネージドDNSと監視、自動化を組み合わせる
• 重要レコードの整合性チェックを行う
• 必要に応じてマルチプロバイダDNSを検討する
• DNSSEC運用の手順を整備する
• レジストラ設定や権限管理も含めて設計する

ミッションクリティカルな用途

• マルチDNSプロバイダ
• 複数リージョン、複数回線、複数事業者
• 定期的なフェイルオーバー訓練
• 親子委任やDNSSEC検証を含む監視
• ドメイン管理権限の厳格な統制

監視で見るべきポイント

DNSの冗長化は、構成しただけでは不十分です。

監視も重要です。

見るべき項目としては、少なくとも次があります。

• 権威DNSが応答しているか
• 期待するレコードが返っているか
• 全NSで同じ内容が返るか
• 親ゾーンと子ゾーンの委任が整合しているか
• DNSSEC検証が正常に通るか
• レジストラ設定やネームサーバー設定に意図しない変更がないか

単に「53番ポートに応答するか」だけを見るのではなく、内容の整合性まで監視することが大切です。

まとめ

DNSの冗長化とは、単にDNSサーバーを複数台にすることではありません。

本質は、名前解決を止めないために、障害要因を分散し、継続運用できる状態を作ることです。

重要なポイントをまとめると、次の通りです。

• 権威DNSと再帰DNSの両方で冗長化を考える
• 台数ではなく、障害要因の分離を重視する
• DNSサーバーの冗長化と配信先フェイルオーバーは別問題として扱う
• TTL、キャッシュ、同期、DNSSEC、Glue、親子委任まで含めて設計する
• 監視と運用手順まで含めてはじめて実用的な冗長化になる

つまり、DNS冗長化で本当に大切なのは、「2台あること」ではなく、「同時に止まる理由を減らせていること」です。

以上、DNSの冗長化についてでした。

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