CDNがアドレスを変えるとVPNのドメインルールは壊れる

ある照会から取ったアドレスをルーティングルールに写すと、サイトは動き、一週間後には動かなくなる。ルールのどこも変わっていない。サービスが別のエッジアドレスへ移ったか、クライアントが別のホスト名を解決したか、セッションがIPv6に切り替わったのだ。目の前の判断は、名前ベースのルールと明示的な範囲のどちらがこのサービスに適した道具かであり、三つの条件がそれを決める。安定しているのは片方だけだから、以下では名前とアドレスを分けて扱う。

一回の照会が台帳にならない理由

コンテンツ配信ネットワークは、リゾルバー、地域、その瞬間に合わせて選んだアドレスで応答する。別のネットワークから二度尋ねれば、違う答えが返ることがある。一度だけ尋ね、その答えをサービスのアドレス一覧として扱えば、書いたルールはルールではなくスナップショットになる。DNSの応答を設定として扱うことの根本的な問題はそこにある。

第二の隙間がある。見えているホスト名ひとつでアプリケーション全体を覆えることはまれで、ログイン、メディア、APIの通信はしばしば別の名前を使う。アドレスバーのホスト名から作ったルールはページを覆っても動画を取り逃がし、それはルーティングの誤りではなく部分的な障害として読まれる。

第三の隙間はアドレスファミリーだ。v4だけのルールは、クライアントが好むかもしれないAAAAレコードについて何も言わない。

ドメインルールか範囲かを決める三つの条件

第一に、サービスは所有し文書化できる安定したプレフィックスの集合を公開しているか。しているなら、明示的な範囲は正直で安価だ。していないなら、ドメインルールだけがサービスに追随できる仕組みだ。

第二に、クライアントのドメイン機構は更新されるか。接続時に一度だけ解決して二度と更新しないルールは、より良いブランディングをまとったスナップショットだ。第三に、その機構はサブドメインと両方のアドレスファミリーを覆うのか、入力した名前だけを覆うのか。

この三つに答えれば、選択はたいてい明らかだ。当て推量は、試験では動き本番では失敗するルールを生む。

ページではなくセッションを試す

ページを読み込み、次にサインインし、再生を始め、ファイルをアップロードするという重要な操作を行う。どれも別のホストに届きうるし、失敗するのはルールが取り逃がしたものだ。

ページが表示するものではなく、セッションが実際に接続するものを列挙する：

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

あるリゾルバーでは動き別のリゾルバーでは失敗するルールはトンネルではなくCDNの応答について語るのだから、比較の間はリゾルバーを見える状態にしておく。短いTTLは、記録した応答に賞味期限があることも意味する。

各機構が実際に覆う範囲

二つの機構は設定画面では入れ替え可能に見え、内側では違う振る舞いをする。

カーネルのアドレスルートはプレフィックスを照合する。ホスト名が何かを知らないので、アドレスを変えるサービスには追随できない。ドメインルールは名前を解決して結果をルーティングするが、サービスには追随するものの、リゾルバー、更新の挙動、クライアントのサブドメイン処理に依存するので、名前を追うルールはクライアントが実際に使うリゾルバーで試さなければならない。

どちらも他方の上位集合ではないので、注記なしで混ぜると後で混乱を生む。

サービスが変わったら再確認する

クライアントの更新やサービスの変更のあと、同じセッションテストをもう一度実行する。以前に動いていたアドレス一覧はその期間の証拠であって、サービス基盤の恒久的な台帳ではない。

どの機構がどのホスト名を覆うのか、最後に確認した日付とともに書き留める。

その注記が、擁護できるルールと誰も触れようとしないルールの差になる。サービスが自前のプレフィックス一覧を公開しているなら、それを使い日付を添える。していないなら、そう書いたうえで、ドメインルールとその更新の挙動を並べて記しておく。