要約

  • NSIDが示せるのは、あるDNS応答者が一つの応答に特定のバイト列を付けたという事実である。その値がホスト名、物理機械、所在地、ソフトウェア版、永続的な身元であることまでは証明しない。
  • 障害対応に使うには、元の問い合わせと応答、観測地点と時刻、運用者が管理する対応表、その証拠で操作してよい単位という四つの記録を結合する必要がある。

IPアドレスが一台の名前ではなくなったとき

一つのIPアドレスを一台のサーバーとみなす方法は、かつては実用的な近道だった。分散DNSでは前提が変わる。Anycastでは複数のノードが同じサービスアドレスを広告し、ルーティングが送信元とその時点の経路状態に応じて一つを選ぶ。ロードバランサーの背後にも、複数のプロセスやホストが存在し得る。

アドレスは依然として重要である。クライアントがどのサービス宛てに問い合わせたかを示すからだ。ただし、どの機械が処理したかを一意には示さない。RFC 4786は、あるanycastノードに到達する位相的な領域をcatchmentと呼ぶ。その領域は観測地点に依存し、経路変更によって動く。地理的な固定区域でも、永続的な利用者一覧でもない。

RFC 3258は、この性質が権威DNSの診断に与える影響を明記した。同じ共有アドレスへの二つの独立したDNS問い合わせが、同じサーバーへ届く保証はない。Ping、traceroute、別のTCP接続も、問題のDNS応答を処理したプロセスへ届いた証拠にはなりにくい。それぞれの観測が正しくても、対象が同じとは限らない。

Suzanne WoolfとDavid ConradがRFC 4892で扱ったのは、この証拠の隙間である。2007年にInformationalとして公開された同文書は、万能な機械識別を定義したものではない。共有アドレスの背後から古いデータや不一致なデータが返ったとき、不要な管理情報を漏らさず、応答元をどこまで絞れるかという運用上の要求を整理した。

したがって、「この観測地点からこのサービスアドレスへ送り、この応答を受け取った」と「この物理機械が応答した」は別の主張である。前者は通信記録で証明できる。後者には、アドレスの外側にある運用上の対応関係が要る。

二回目の問い合わせが対象を取り違える

BINDには以前から便利な慣行があった。CHAOSクラスのTXTとしてHOSTNAME.BIND.を問い合わせると、管理者が設定したホスト名を返せる。ID.SERVER.はBIND固有の名前を弱めながら、同じ考え方を採用した。DNSの中で完結するため、通常の問い合わせとおおむね同じファイアウォールやルーティング条件を通り、管理用アドレスを公開するかどうかも運用者が選べる。

弱点は、識別用の問い合わせが二回目だということだ。異常な応答を受けた後、anycast経路が変わることも、ロードバランサーが別のバックエンドを選ぶことも、故障したインスタンスが離脱することもある。後から得たラベルは二回目の応答者について正しくても、最初の応答者のものとは限らない。

誤結合は見抜きにくい。同じサービスIPからラベルが返り、経路ももっともらしく見える。しかし、同じIPを複数のインスタンスが共有することこそ、調査の出発点だったはずだ。IPの一致だけで二つの取引を同一視すれば、分散構成を認めながら証拠上は否定することになる。

RFC 4892が通常の業務応答そのものに識別情報を載せられることを求めた理由はここにある。専用問い合わせを残してもよいが、同じ応答に入ったラベルの代用にはならない。同一メッセージへの結合は、表示上の利便性ではなく、時間競合を閉じる条件である。

RFC 4892が残した設計条件

WoolfとConradは、ID.SERVER.の綴りを正式化するだけでは不十分だと考えた。既存方式の欠点から、よりよい仕組みの条件を引き出した。

識別はDNSの帯域内にあり、特定実装に依存せず、通常の応答に付加できなければならない。実装、利用開始、停止が容易で、問い合わせ可能な相手を制限できることも必要だった。インスタンスを区別するために、内部ホスト名や管理用の単一宛先アドレスを世界へ公開させてはならない。CHAOSクラスと専用の疑似ゾーン全体を一用途に使う負担も引き継ぐべきではない。

さらに、識別と認証を分離した。ホスト名らしい文字列は、それだけでは真正性を持たない。DNSSECは署名されたDNSデータを検証モデルの中で保護するが、応答者が付けるすべてのチャネル情報を自動的に認証するものではない。将来の方式は認証を組み込めるべきだが、読みやすさを完全性と取り違えてはならない。

RFC 4892自体はIANAの割り当てを求めず、要件で止まった。その後、Rob Austeinが執筆したRFC 5001がNSIDオプションを定義し、Woolfの貢献にも謝意を示した。RFC 5001の著者はAusteinである。この区別を守ることは、本稿の主題そのものでもある。由来を便利だからと拡張してはならない。

NSIDが実際に保証する範囲

リゾルバーはEDNS問い合わせに空のNSIDオプションを入れる。対応し、かつ回答を選んだサーバーは、同じDNS応答のNSID欄に識別用バイト列を返す。観測者は「この取引の応答者がこの値を返した」と確実に言える。後続問い合わせとの時間差はなくなる。

一方、値の意味は確定しない。RFC 5001はNSIDを不透明なバイト列とし、その構文と意味を実装者と運用者に委ねた。実ホスト名、単一宛先アドレス、永続的な乱数、動的な値、暗号化された塊、任意のオクテットのどれでもよい。ユーザーインターフェースが十六進表示を使うのは、見栄えのよい文字列よりも原データの完全な保持を優先するためだ。

同じ値が物理ホストを指す場合もあれば、プロセス、コンテナ、負荷分散プール、拠点、anycastノードを指す場合もある。再起動を越えて残るかもしれず、毎回変わるかもしれない。誤設定で全ノードが同じ値を返すこともある。これらは運用ポリシーであり、プロトコルの性質ではない。

NSIDは非推移的で、一つのDNSホップに閉じる。スタブが再帰リゾルバーへNSIDを求めた場合、返る値はその問い合わせを受けた再帰側を識別する。再帰処理の途中で使った権威サーバーを自動的に示すわけではない。再帰側が上流で別のNSID問い合わせをすれば、それは別ホップの別記録となる。EDNS自体もホップ単位である。

認証も自動ではない。RFC 5001はこのチャネル信号をDNSSECの直接の対象外とし、完全性が必要な用途ではTSIGのようなチャネル保護を求める。署名や暗号化を思わせる静的データも再送できる。暗号方式があっても、鮮度、物理位置、運用責任までは導けない。

四つの記録で意味を狭く保つ

第一は応答結合の記録である。元の問い合わせ、応答、NSIDの原バイト列を一緒に保存する。最初の問い合わせでNSIDを要求していなければ、インスタンスは未確定と記録する。後からID.SERVER.を聞いても、過去の応答者を確定したことにはならない。

第二は観測地点と経路の記録である。送信元、対象のサービスアドレス、トランスポート、時刻を残す。Anycast測定は、ある地点の利用者がその瞬間に何へ到達したかを示す。別地点の異なる結果は矛盾ではなく、catchmentの違いかもしれない。

第三は運用者の対応表である。不透明な値を運用単位へ結ぶ表に、版、生効時刻、失効時刻を持たせる。再構築後に同じ値を再利用すれば、表がない限り偽の連続性が生まれる。対応表なしのNSIDは回答をまとめるキーにはなるが、資産名にはならない。

第四は操作範囲の記録である。対応先がプロセス、コンテナ、ホスト、プール、拠点、anycastノードのどれかを明示し、誰が変更権限を持つかを結ぶ。それによって、ログ確認、一つのバックエンドの切り離し、サービス再起動、経路広告停止のどこまでが正当化されるかが変わる。

四つをそろえると、NSIDの強みはむしろ明確になる。応答を分類し、外れ値を見つけ、正しい運用チームへ調査を渡せる。同時に、プロトコルが約束していない機械の身元を作り出さずに済む。

情報源