複数の DNS プロバイダーによる DNS 冗長化とは、2 社以上のプロバイダーが同じゾーンのクエリに応答し、1 社がダウンしても名前解決を続けられるようにする構成です。ただし、プロバイダー間でそのまま複製できるのは静的レコードだけで、地域別ルーティングやヘルスチェックは通常失われます。OpenResty Edge をプライマリにすれば、こうした振り分けは引き続き OpenResty Edge が担い、他の DNS プロバイダーはセカンダリとして、TSIG で認証された AXFR によって同じゾーンを取得し、OpenResty Edge とともに応答します。

2016 年 10 月 21 日、DNS プロバイダーの Dyn が Mirai ボットネットによる DDoS 攻撃を受け、Twitter、GitHub、Netflix をはじめとする多数のサイトが一時的にアクセス不能になりました。サイト自体に問題があったわけではなく、ユーザーがドメイン名からアドレスを引けなくなったのです。権威 DNS が 1 か所だけでホストされている限り、それがプロバイダーであれ自社運用のサーバーであれ、その 1 か所が利用できなくなった時点で、依存するすべてのサービスが一斉にダウンします。

本記事では、OpenResty Edge とセカンダリプロバイダーの役割分担の仕組みと、どのようなゾーンに適しているかを説明します。具体的な設定手順は OpenResty Edge のドキュメント「DNS Zone Transfer and TSIG」（英語）をご覧ください。

OpenResty Edge の試用を申請する

なぜマルチプロバイダー DNS では地域別ルーティングを手放さざるを得ないのか

フルサービスリゾルバー（キャッシュ DNS サーバー）は、ドメインの委任先として NS レコードに列挙されたネームサーバーから 1 台を選んで問い合わせます。通常は応答の速いサーバーが優先され、応答がなければ次のサーバーに切り替えます。そのため NS レコードに 2 社のプロバイダーのネームサーバーが含まれていれば、1 社がダウンしてもリゾルバーはもう 1 社に切り替え、名前解決は途切れません。ただし、この仕組みには前提があります。両社が同じレコードを返すことです。そうでなければ、同じドメイン名がタイミングやユーザーによって異なる結果に解決されてしまいます。

複数のプロバイダー間で内容を一致させる一般的な方法は 2 つあります。

  • マルチプライマリ：すべてのプロバイダーをプライマリサーバーとし、各社の API や同期ツールを使って同じレコードをそれぞれに書き込みます。問題は、レコードタイプ、独自機能、API がプロバイダーごとに異なることです。時間が経つにつれて各社の設定にずれが生じやすく、プロバイダーを 1 社追加するたびに、対応・保守すべき API も 1 つ増えます。
  • シングルプライマリ・マルチセカンダリ：書き込みは 1 か所だけで行い、他のプロバイダーはセカンダリサーバーとしてゾーン転送（AXFR）でゾーン全体を定期的に取得します。書き込み先が 1 つなので、一貫性はプロトコルによって保証されます。

どちらを選んでも、複数のプロバイダー間で一致させられるのは、各社が共通してサポートする標準的な静的レコードだけです。地域別ルーティング、ヘルスチェック、トラフィックステアリングといった機能では、サーバーがクエリを受け取った時点で、問い合わせ元とリアルタイムの状態に基づいて応答をその場で算出します。各社の実装には互換性がなく、ゾーンデータに載せられるのは算出された応答そのものだけで、「どう算出するか」というロジックまでは載せられません。たとえば IBM NS1 はドキュメントで、Filter Chain によるトラフィックステアリングの設定や ALIAS などの独自レコードは、外部へのゾーン転送に含まれないと明記しています。その結果、冗長性のために各社共通の最小限の機能まで後退し、インテリジェントな振り分けをあきらめざるを得ないケースが少なくありません。

ビジネスの観点では、これは 2 つのリスクのどちらかを選ぶことを意味します。1 社のプロバイダーだけに頼れば、そのプロバイダーがダウンしたときに名前解決がすべて止まるリスクを負います。冗長性のために静的レコードまで後退すれば、最寄りノードへの誘導や障害ノードの自動切り離しをあきらめることになり、一部のユーザーはより遠い、あるいはすでに利用できないアドレスへ誘導されてしまいます。

OpenResty Edge による DNS 冗長化：振り分けはプライマリ、フォールバックはセカンダリプロバイダー

すでに OpenResty Edge の内蔵の権威 DNS でゾーンを管理している場合、ゾーン転送を有効にすると、全体のアーキテクチャは次のようになります。

          管理者（Edge Admin コンソール：編集 → リリース）
                                  │
    OpenResty Edge（プライマリサーバー、信頼できる唯一の情報源）
                  │                            │ AXFR over TCP + TSIG 署名
                  │                  ┌─────────┴─────────┐
                  │            セカンダリ A        セカンダリ B
                  │                  │                   │
                  └──────────┬───────┴───────────────────┘
    NS レコード（委任情報）に OpenResty Edge と各セカンダリプロバイダーを併記
                             │
               フルサービスリゾルバー / ユーザー
  • レコードの追加・変更・削除は、これまでどおり OpenResty Edge 上だけで行います。セカンダリプロバイダーは AXFR でゾーン全体を取得し、転送は TSIG キーで認証できます。
  • OpenResty Edge は引き続きインターネットからのクエリに応答します。ゾーン転送を有効にしても既存の名前解決には影響しません。NS レコードには OpenResty Edge と各セカンダリプロバイダーを併記します。レジストラ側では OpenResty Edge のネームサーバーを残したまま、各セカンダリプロバイダーのネームサーバーを追加します。

この役割分担により、次のような効果が得られます。

  • インテリジェントな振り分けはそのまま機能します。 OpenResty Edge に届いたクエリには、引き続き問い合わせ元とリアルタイムの状態に基づいて、地域別ルーティング、ゲートウェイノードへの振り分け、ヘルスチェックを反映した応答が返されます。ヘルスチェックに失敗したノードは名前解決の結果から自動的に除外され、GSLB ではマシン負荷やリクエストレートなど、サービスの実際の負荷を示す指標に基づいてクラスター間のトラフィックを調整することもできます。
  • 静的レコードがマルチプロバイダーで冗長化されます。 各セカンダリプロバイダーが同じ静的レコードで応答するため、OpenResty Edge またはいずれかのプロバイダーが利用できなくなっても、他が応答を続けます。
  • セカンダリプロバイダーは必要に応じて追加・削除・入れ替えができます。 同期に必要なのは標準プロトコルである AXFR ゾーン転送だけで、特定のプロバイダーの独自 API には依存しません。セカンダリプロバイダーを乗り換える場合も、新しいプロバイダーがゾーン転送でゾーン全体を取得するだけです。
  • 地域別ルーティングのレコードにもフォールバックがあります。 地域別ルーティングのレコードにデフォルトのレコード（地域条件なし）を設定しておけば、セカンダリプロバイダーはそのデフォルトのレコードで応答できます。
  • フォールバックの猶予は十分です。 OpenResty Edge が生成する SOA の expire はデフォルトで 604800 秒（7 日間）で、必要に応じて調整できます。セカンダリサーバーは、最後にリフレッシュに成功した時点から expire の期間内であれば、OpenResty Edge が一時的に利用できなくなっても手元のコピーで応答を続けられます。

ビジネスの観点では、冗長性のためにユーザー体験を犠牲にする必要はありません。通常時は引き続きユーザーを最寄りの正常なゲートウェイクラスターへ誘導します。いずれかのプロバイダーに障害が起きても、Dyn の事例のようにビジネス全体が停止することはありません。プロバイダーの乗り換えにレコードの移行や再登録は不要なので、特定のプロバイダーに縛られることもありません。さらに OpenResty Edge 自体に障害が発生しても、チームには原因調査と復旧のための十分な時間があり、外部からの名前解決は途切れません。

信頼できる唯一の情報源（SSOT）を OpenResty Edge に置くことには、さらに 4 つの利点があります。

  1. すべての変更にアクセス制御が適用されます。 DNS アプリケーションへのアクセスはユーザーグループ単位で認可され、読み取り権限と書き込み権限を分けることができます。一般ユーザーにはデフォルトで DNS 機能が表示されず、自身のユーザーグループに認可されていない DNS アプリケーションも表示されません。詳しくは「OpenResty Edge の Admin コンソールで DNS アプリケーションのアクセス権限を管理する」をご覧ください。
  2. 変更はバージョン管理され、リリース後に初めて反映されます。 OpenResty Edge はバージョン 25.9.17 から DNS 設定をバージョン管理しており、ゾーン転送の設定もレコードと同様に、リリース後に初めてノードへ配信されます。
  3. シリアル番号は自動で管理されます。 セカンダリサーバーは SOA のシリアル番号（serial）を比較して、ゾーンが更新されたかどうかを判断します。プライマリサーバーを自前で運用する場合、この値は人手やスクリプトでインクリメントする必要があり、一度でも漏れるとセカンダリサーバーは新しいデータを取得しません。OpenResty Edge はシリアル番号を自動で管理し、転送対象の内容が実際に変わった場合にのみリリース時にインクリメントするため、セカンダリサーバーは再取得が必要かどうかを確実に判断できます。
  4. 唯一の情報源自体も保護されています。 DNS アプリケーションは他のアプリケーションの設定と同じく Edge Admin データベースに保存されます。OpenResty Edge はこのデータベースを、別ホストへの定期バックアップ、プライマリ／スタンバイ間のストリーミングレプリケーション、自動フェイルオーバーの 3 層で保護しています。詳しくは「OpenResty Edge のデータベースバックアップとフェイルオーバー」をご覧ください。

チームにとって、これは DNS を他の本番設定と同じルールで統制（ガバナンス）できるということです。複数のチームが 1 つのプラットフォームを共有していても、各チームは自分のゾーンだけを管理し、他チームのレコードを誤って変更することはありません。編集した時点で本番の名前解決に影響が出ることはなく、すべての変更を後から追跡できます。セカンダリプロバイダーが古いデータを返し続けていることに気づかない、という事態も防げるため、発見しにくい障害の要因を一つ減らせます。そして、データを 1 か所に集約しても、リスクまで 1 か所に集中するわけではありません。

マルチプロバイダー DNS 構成に適したゾーン

  • DNS プロバイダー 1 社が丸ごとダウンするリスクに備える必要があるゾーン
  • 静的レコードが中心のゾーン、または地域別ルーティングのレコードすべてにデフォルトのレコードが設定されているゾーン

まとめ：冗長性・インテリジェントな振り分け・ガバナンスを同時に実現

DNS はあらゆるサービスの入口です。これまで、この入口を冗長化するには複数のプロバイダーに共通する最小限の機能まで後退する必要があり、インテリジェントな振り分けも一元的なガバナンスも犠牲になっていました。OpenResty Edge を唯一の情報源にすれば、この前提が変わります。

  • インテリジェントな振り分けの構築は 1 か所だけで済みます。 地域別ルーティング、ヘルスチェック、GSLB はすべて OpenResty Edge に集約されます。セカンダリプロバイダーには標準的なセカンダリサーバー機能さえあればよく、各社でインテリジェント（Intelligent）DNS を重複して購入・設定する必要はありません。
  • 特定のプロバイダーに縛られません。 セカンダリプロバイダーは標準プロトコルで同期するため、レコードを移行することなく、必要に応じて追加・削除・入れ替えができます。
  • プロバイダーの数が増えてもガバナンスのコストは増えません。 何社を接続しても、変更は OpenResty Edge 上だけで行われ、同じ権限管理、バージョン管理、リリースのプロセスを経ます。
  • DNS とゲートウェイが同じプラットフォーム上にあります。 レコードはゲートウェイクラスターに直接解決され、ノードのヘルス状態はそのまま名前解決の結果に反映され、DNS フラッド対策も組み込まれています。そのため、DNS とゲートウェイという別々のシステムの間で整合性を取り続ける必要はありません。

このアーキテクチャは、特に次のようなケースに適しています。

  • 名前解決の停止がそのまま売上の停止につながるオンラインビジネス（EC、オンライン決済、ゲームなど）：プロバイダー単位の障害が起きても他のネームサーバーが応答を続け、通常時は最寄りノードへのアクセスを維持できます。
  • 複数リージョン・複数クラスターにデプロイされたサービス：地域別ルーティングとクラスター間のディザスタリカバリは中核機能であり、冗長化のために手放すことはできません。
  • 自社でプライベート CDN を構築している企業：OpenResty Edge が権威 DNS としてプライベート CDN の前段を担うため、マルチプロバイダー冗長化が守るのは、まさにエッジネットワーク全体の入口です。
  • 複数のチームでプラットフォームを共有し、変更監査が求められる組織（金融機関や公共機関など）：各チームは自分のゾーンだけを管理し、すべての変更が記録され、追跡できます。

まずは静的レコードが中心でトラフィックの少ないゾーンを 1 つ選び、セカンダリプロバイダーを 1 社接続することをお勧めします。ドキュメント（英語）に従って設定を完了したら、dig で OpenResty Edge とセカンダリプロバイダーの応答を比較し、一致することを確認してから、レジストラでセカンダリプロバイダーを NS レコードに追加してください。

よくある質問

OpenResty Edge は Cloudflare Secondary DNS のプライマリサーバーになれますか？

はい。OpenResty Edge はバージョン 26.9.1-1 から AXFR ゾーン転送と TSIG 認証をサポートしており、Cloudflare Secondary DNS などのセカンダリプロバイダーのプライマリサーバーとして機能します。なお、Cloudflare のゾーン転送機能は Enterprise プランでのみ提供されています。

セカンダリプロバイダーを接続した後も、OpenResty Edge の地域別ルーティングと GSLB は使えますか？

はい。OpenResty Edge は引き続き NS レコードに含まれ、地域別ルーティングのレコード、ゲートウェイノードに解決されるレコード、ヘルスチェック対象のレコードへのクエリに、問い合わせ元とリアルタイムの状態に基づいて通常どおり応答します。セカンダリプロバイダーはゾーン内の静的レコードを同期して OpenResty Edge とともに応答するため、いずれかのプロバイダーが利用できなくなっても、残りのネームサーバーが応答を続けます。

なぜ地域別ルーティングのルールはセカンダリ DNS プロバイダーに転送されないのですか？

地域別ルーティングやヘルスチェックの応答は、クエリを受け取った時点で、問い合わせ元とリアルタイムの状態に基づいて算出されるためです。ゾーンデータに載せられるのは応答そのものであり、それを算出するロジックではありません。各社の実装にも互換性がなく、たとえば IBM NS1 のドキュメントは、Filter Chain の設定や ALIAS レコードが外部へのゾーン転送に含まれないと明記しています。そのため、セカンダリプロバイダーが応答できるのは静的レコードとデフォルトのレコードです。

セカンダリプロバイダーを接続したら、OpenResty Edge をヒドゥンマスター（hidden master）にする必要がありますか？

いいえ。ヒドゥンマスター構成にすると、インターネットからのクエリにはすべてセカンダリプロバイダーが応答することになり、返せるのは静的レコードとデフォルトのレコードだけなので、地域別ルーティングやヘルスチェックの効果が失われます。OpenResty Edge とセカンダリプロバイダーを NS レコードに併記しておけば、OpenResty Edge に届いたクエリには最寄りの正常なノードへの振り分け結果が返り、いずれかが利用できなくなったときは他が応答を続けます。

OpenResty Edge について

OpenResty Edge は、マイクロサービスと分散トラフィックアーキテクチャ向けに設計された統合型ゲートウェイソフトウェアで、弊社が独自開発しました。トラフィック管理、プライベート CDN 構築、API ゲートウェイ、セキュリティ対策などを一つにまとめ、現代のアプリケーションの構築・運用・保護を支援します。OpenResty Edge は業界トップクラスの性能とスケーラビリティを備え、同時接続数が多い高負荷環境でも厳しい要求に応えます。Kubernetes などコンテナ化されたアプリケーショントラフィックのスケジューリングにも対応し、大規模なドメイン運用を支え、大規模ウェブサイトや複雑な業務アプリケーションの要件も満たします。

→ 権威 DNS は OpenResty Edge の機能の一つに過ぎません。その他の機能は OpenResty Edge 徹底解説をご覧ください。

OpenResty Edge の試用を申請する

著者について

章亦春（Zhang Yichun）は、オープンソースの OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。

章亦春（GitHub ID: agentzh）は中国江蘇省の出身で、現在は米国ベイエリアに在住しています。中国における初期のオープンソース技術と文化の提唱者・リーダーの一人であり、Cloudflare、Yahoo!、Alibaba などの国際的なハイテクノロジー企業に勤務した経験があります。「エッジコンピューティング」「動的トレーシング」「マシンプログラミング」の先駆者でもあり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を有します。世界で 4,000 万以上のドメインに採用されているオープンソースプロジェクトのリーダーとして、OpenResty® を基盤に、米国シリコンバレーの中心部に OpenResty Inc. を創設しました。同社の主力製品である OpenResty XRay（動的トレーシング 技術を活用した非侵入型のプロファイリングおよびトラブルシューティングツール）と OpenResty Edge（マイクロサービスおよび分散トラフィック向けの統合ゲートウェイソフトウェア）は、世界各地の上場企業および大企業に広く採用されています。OpenResty 以外にも、Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、多数のオープンソースプロジェクトに累計 100 万行超のコードを寄与し、60 件を超えるオープンソースソフトウェアライブラリを手がけています。

翻訳

英語版の原文と日本語訳版（本文）をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます！