ローカルおよびリモートのセルフホストアプリ向けSplit DNS導入ガイド

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Split DNS Deployment Guide for Local and Remote Self-Hosted Apps - Zima Store Online

安全なアプローチとは、段階的なスプリットDNS導入を、決定論的なリゾルバースコープ、TLS IDの一致、移行テスト、ロールバックを備えた一連の観測可能なゲートとして扱うことであり、単一のコマンドとして扱うことではありません。

ローカルおよびリモートのリバースプロキシ経路の背後にセルフホスト型アプリを置く場合、実際のリスクは、同じアプリのホスト名が、証明書やルーティングに予期せぬ問題を起こすことなく、意図したローカル、VPN、パブリックのエンドポイントへ解決されなければならない点にあります。現在のIDと復旧ポイントを記録し、最も影響の少ない識別要素から始め、別の変数を変更する前に成功と失敗の結果を解釈し、ストレージが不安定になった場合や、復旧可能なコピーが公開される可能性しか残っていない場合は中止します。以下のワークフローは、元のワークロードが正常に動作するか、証拠がエスカレーション境界に達するまで続きます。

名前、ビュー、信頼境界を定義する

アプリケーションごとに1つの完全修飾ホスト名を選び、信頼できるLAN、VPN、ゲスト、パブリックの各クライアントに対して期待される応答を文書化します。返されるアドレスが変わっても、アプリケーションのIDとTLS名は一定に保ちます。関連のない内部名を使うと、リダイレクト、コールバック、ブックマーク、モバイルクライアントが壊れることがよくあります。

実用的なホームラボの構成では、内部にはプライベートなプロキシアドレスを返し、外部にはパブリックプロキシまたはトンネルのエンドポイントを返します。1つの名前を使うスプリットDNS設計では、この1つの名前に対して2つの応答を返す設計を示し、DNSチャレンジ検証によって内部サービスをパブリックに到達可能にすることなく証明書を発行できる点を説明しています。

どのネットワークにプライベートレコードを決して返してはならないかを決めます。ゲストやIoTのクライアントにはパブリック経路、またはまったく応答しない設定が必要な場合があります。パブリックゾーンには、プライベートアドレスや内部専用のホスト名を公開してはいけません。

パブリック経路を変更せずにローカルビューを導入する

移行前に関連するTTLを短くし、選択したリゾルバーに内部オーバーライドを追加して、カナリアクライアントからそのリゾルバーを明示的に指定してクエリします。AレコードとAAAAレコードは個別に検証します。正しいIPv4応答であっても、古い、またはパブリックなIPv6応答によって迂回される可能性があるためです。

DHCPとVPN設定を通じて内部リゾルバーを通知し、各オペレーティングシステムで実際に使用されているリゾルバーを確認します。ブラウザーのセキュアDNS、モバイルのプライベートDNS、キャッシュされた応答、手動設定されたリゾルバーによって、ローカルゾーンが正しくても意図したビューが迂回されることがあります。

既存のZimaSpace スプリットホライズンDNS設定を設定の境界として使用し、このワークフローでは導入順序と受け入れ確認に重点を置きます。パブリックDNS、ローカルプロキシのルーティング、クライアントのリゾルバーポリシーを1つの手順で同時に変更しないでください。各レイヤーには、個別の成功またはロールバックの結果が必要です。

DNSの応答をプロキシと証明書のIDに合わせる

LANのカナリアからホスト名を開き、解決されたアドレス、経路、TLS証明書名、応答ホスト、リダイレクト、WebSocketの動作、アプリケーションが生成したURLを記録します。Webページに到達できるだけでは不十分です。リクエストが誤ったバーチャルホストに到達したり、IPアドレスへリダイレクトされたりする可能性があるためです。

Wi-Fiを無効にして、携帯電話回線または別の外部ネットワークから繰り返し確認します。アドレスは変わっても、ホスト名、証明書のID、ログイン、アプリケーションデータは一貫していなければなりません。内部と外部で意図的に異なるプロキシを使用する場合は、どちらも同じホストを正しくルーティングできる必要があります。

自宅の外部からVPNアクセスをテストします。VPNにはプライベートな応答を返すべきなのにパブリックな応答が返される場合は、別のアプリケーションオーバーライドを追加する前に、DNSの割り当てまたはスプリットルーティングを修正します。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

切り替えを検証し、ロールバックの記録を保持する

TTLの期限が切れた後のクエリ結果を記録しながら、カナリアをLAN、携帯電話回線、VPNの間で切り替えます。新しいブラウザーセッションと、既存のログイン済みセッションの両方をテストし、異なるホストに紐づいたCookie、コールバック、セッションの動作がDNSの成功によって隠れないようにします。

リゾルバーとプロキシを一度再起動し、クライアントのリースを更新して、経路マトリックスを再確認します。関係のないパブリックレコードと内部サービスが以前の応答を維持していることを確認します。欠落しているパブリックレコードをシャドーするスプリットゾーンは、未完成の導入です。

すべてのビューが決定論的になってから、他のクライアントへ展開します。クライアントを意図したリゾルバー上に維持できない場合、証明書のIDが一致しない場合、またはプライベートアドレスがパブリックに漏洩する場合は、内部オーバーライドをロールバックし、次回の試行に備えてクエリ結果とタイムスタンプを保存します。