要約

  • 同じ DNS アドレスに後から識別用の問い合わせを送っても、先ほどと同じ実体が答える保証はない。NSID は調査対象の応答そのものに識別子を添える。
  • 識別子の意味は運用者が決める。受け取る側に必要なのは、意味を推測して書き換えることではなく、バイト列を欠落なく保存して渡すことだ。
  • 再帰リゾルバーが返す NSID はそのリゾルバー自身を指す。上流の権威サーバーや再帰処理全体の来歴を証明する仕組みではない。

平均値には、答えた相手が見えない

一つのサービスアドレスについて応答時間を測れば、一覧はきれいにまとまる。しかし、そのアドレスの背後に複数の実体がある場合、数値だけではどの実体が答えたのか分からない。ある場所からの遅延と別の場所からの正常な応答を、同じ一台の振る舞いとして扱ってしまう可能性がある。

これは特定の障害を再現した記録ではなく、観測単位をどう選ぶかという問題だ。2006年12月の運用文書RFC 4786は、任播サービスを複数の観測地点から監視し、性能や可用性とともにノードの識別情報を記録するよう勧めていた。サービスが動いているかに加え、どのノードを観測したかが重要になる。

任播では、複数の独立したノードが共通のサービスアドレスへの到達性を経路制御に知らせる。どこへ届くかは経路選択に左右される。必ず地理的に最も近い場所へ届くという意味でも、パケットごとに必ず行き先が変わるという意味でもない。宛先が変わらないことだけを根拠に、応答者も同一だと断定できないのである。

後から聞いた名前は、前の回答者の名前か

異常な DNS 応答を受け取った後、同じアドレスへ「あなたは誰か」と問い合わせる。返ってきた名前のサーバーを調べると正常で、最初の問い合わせの記録もない。このような状況は、最初と次の問い合わせが別の実体に届いただけでも起こり得る。

2007年6月のRFC 4892は、この結び付けの弱さを要件として整理した。任播や負荷分散の下では、同一 IP アドレスへの複数の DNS 問い合わせが別のサーバーへ届く可能性がある。別のプロトコルを使った調査なら、元の問い合わせを扱った装置に届いたという確実性はさらに得にくい。

RFC 4786も、traceroute が役立つ場合はあっても、実行するまでに条件が変わる可能性を指摘していた。そこでサービスのプロトコル内で識別できるようにすることを勧めた。同文書が言及した NSID は当時進行中の作業であり、翌年の完成した仕様がすでに存在していたわけではない。

問題は、識別用の二回目の回答が虚偽であることではない。正しい名前が返っても、それを一回目の出来事に結び付ける根拠が足りない。診断に必要なのは、読みやすい名前より先に、回答と識別情報の対応だった。

従来の問い合わせを否定する話ではない

DNS には以前から、CHAOS クラスの TXT 問い合わせで HOSTNAME.BIND.を調べる慣行があった。管理者が設定した識別情報を返せる。ID.SERVER.は実装名を含まない形を提供し、VERSION.BIND.は別の目的である版情報を扱った。

これらは設定しやすく、DNS 自身を使い、何を公開するかを管理者が選べるという利点を持っていた。NSID の登場で使用禁止になったわけではない。ただし追加の問い合わせが必要なので、別の実体に到達する可能性を取り除けなかった。

RFC 4892が求めたのは、普通の業務上の問い合わせの中で識別を依頼できる方式だった。診断だけのために別クラスや専用の名前空間を用意せず、実装に依存せず、管理者が有効化や停止、公開範囲を選べること。保守用の名前やユニキャストアドレスを公開しなくても、調査に役立つ情報を返せることも重要だった。

空の欄で、相手自身の情報を求める

R. Austein による2007年8月のRFC 5001は、EDNS の OPT 疑似リソースレコードに NSID オプションを載せる方法を定めた。要求側が送る NSID は空でなければならない。余分な内容を入れてきても、サーバーはそれを無視しなければならない。

したがって、これは相手に同じ値を返させるチャレンジではない。特定のサーバーを選べという経路制御の命令でもない。実際に問い合わせを受け取った相手に、この応答へ自分の識別子を添えてほしいと依頼するだけだ。

対応するサーバーにも返さない選択がある。一方、要求されていない NSID を勝手に返してはならない。NSID が見つからないことを、そのまま DNS 障害や任播不使用の証拠にできない理由はここにある。機能があること、設定されていること、要求が送られたこと、実際に返されたことは別々に確認する必要がある。

IANA の DNS パラメーター登録簿では、EDNS オプション番号3が NSID に割り当てられている。共通化されたのは情報を載せる場所であり、各サーバーの識別子そのものではない。世界共通の機器番号や所在地コードを発行する制度ではなかった。

再帰の履歴は、この欄には入らない

クライアントが再帰リゾルバーに NSID を求めたなら、尋ねているのはそのリゾルバーの識別子だ。リゾルバーが権威サーバーへ問い合わせる際に NSID を求めることはできるが、それは独立した別の取引になる。上流から受け取った値を、クライアントが求めた自分の識別情報として転送するものではない。

仕様はこの非伝達性を明確にしている。「ホップごと」という説明のホップは DNS のやり取りの両端であり、途中の IP ルーターが順に記録を残すという意味ではない。再帰処理に関与したサーバーの一覧も生成されない。

2013年4月の EDNS 仕様RFC 6891では、OPT は特定の問い合わせと応答に関する制御情報であり、DNS データではないと整理された。通常のレコードとしてキャッシュしたり、転送したり、ゾーンのマスターファイルへ保存したりしてはならない。

この規則と NSID の範囲を合わせると、キャッシュ済みのデータを返すリゾルバーが今回の自分の識別子を返すことは矛盾しない。データを以前取得したときの権威サーバーを示しているわけではないからだ。現在の応答者とデータの過去を混同しないことが、識別情報の価値を保つ。

意味より先に、欠けない保存

NSID の中身は不透明なバイト列である。人が読める名前に見えても、その解釈は共通仕様では保証されない。運用者の内部台帳を参照して初めて意味が分かる値でもよい。

RFC 5001が求める表示は、1オクテットにつき2桁の十六進数である。比較は元の二進データで行い、コピーの際にゼロバイトを文字列の終端と見なしてはならない。先頭のゼロも途中のゼロも削除できない。

文字列らしく見えるからといって DNS 名として処理したり、内容の大文字小文字や Unicode 表現を正規化したりすると、識別子を変えてしまう可能性がある。十六進表示の英字の大小が違っても同じバイト列を表せることとは区別すべきだ。読みやすいプレビューは補助にはなるが、元の値の代わりにはならない。

利用者はその値を理解せずに問い合わせ票へ貼り付けられる。運用者は受け取った値から調査対象を探せる。この役割分担を成立させるのは、全員が同じ名前の意味を共有することではなく、誰も途中で証拠を削らないことだった。

隠した名前が安全とは限らない

運用者は名前、保守用アドレス、乱数、変化する値などを選べる。保守用アドレスの公開は、個別ノードを見えにくくする設計の一部を損なうかもしれない。IPv4 アドレスをハッシュしても、入力空間は32ビットのままである。予測しやすい名前のハッシュも、自動的な秘密にはならない。

持続的なランダム値には対応表が必要で、全ノードへ同じ設定値を複製すれば識別能力はなくなる。値の変化が機器交換や経路変更を意味するかどうかは、割当てや更新の方針次第だ。NSID だけから物理装置の恒久的な同一性を証明することはできない。

署名や暗号化した内容についても、RFC 5001は完全な安全設計を提供していない。静的な値は再送され得る。NSID は通信路のシグナリングであり、DNSSEC がそれ自体を保護するわけではない。リソースレコード集合が検証できても、隣の NSID が認証済みになるとは限らない。同文書が TSIG などの通信路保護に触れるのは、この境界を示すためである。

実装の二つの設定が示す分担

今回保存したBIND の設定資料は9.20.27と表示されている。自分が返す値を決めるserver-idは既定値がnoneで、ホスト名を利用する選択肢もある。上流への反復問い合わせで空の NSID 要求を送るrequest-nsidは別設定で、既定では無効だ。返された値はnsidカテゴリに記録できる。

自分を公開することと、相手の情報を収集することは一つの設定ではない。BIND のツール説明にあるdig +nsidも、要求を加える機能であって、返答を強制したり内容の真実性を検証したりするものではない。資料に機能が載っていることから、個別の本番環境で有効だとは判断できない。

追加のバイトは応答サイズにも関係する。ただし NSID は切り詰めの規則を変更せず、この任意情報を入れるためだけに切り詰めを必須にもしない。診断情報を得ることと、通常の名前解決を届けることを取り違えてはならない。

NSID はサービスの入口を変えずに、そこで得た回答を調べるための手掛かりを増やした。全世界のサーバーを名付け直す必要はなかった。同じ回答の中に必要な証拠を置くという、小さな約束で十分だったのである。