要約

  • 2007年8月のRFC 5001はDNSのNSIDオプションを定めた。リゾルバーは空のEDNSオプションで識別子を求め、応じるサーバーはその応答に識別バイト列を添える。
  • 仕組みは一回のやり取り、一つのホップに限られる。識別子の書式は決められておらず、運用者は実名、仮名、変化する値などを選べる。
  • L-Rootの2014年の運用記録は、応答したノードの完全なホスト名をNSIDとして返す実例を示す。IANAのDNS登録簿ではNSIDはEDNSオプション番号3だ。

再試行が無実の機械に当たる

DNSの障害報告にIPアドレスが載っている。担当者は同じアドレスに再送して正常な応答を得る。「再現しない」で終わらせたくなる。しかしanycastのアドレスは一台の機械の表札ではない。複数のノードが同じサービスアドレスを使い、経路によって問い合わせ先が変わる。ロードバランサーの背後でも似たことが起こる。再試行の成功は、最初の応答を出した機械の状態を示していない。

2006年のanycast運用指針は、障害の診断にノードの識別が役立つと説明した。後続の特別な問い合わせでサーバー名を聞く方法はある。だが最初の問題が出てからその問い合わせまでの間に経路が変われば、名乗るのは別のノードだ。犯行時刻の目撃者を探して、翌朝の当番に話を聞いているようなものだ。

RFC 5001の着眼点は、識別を問題の応答と同じ往復に入れたことだった。文書はanycastや負荷分散によって一つのIPを複数のDNSサーバーが共有する状況を挙げる。DNS問い合わせには、後の再試行を元の機械に縛るセッション状態がない。その応答を送るサーバー自身が、識別情報を同じ応答に添えれば、時刻と結果と名乗りが一組になる。

空の質問に返る不透明な値

リゾルバーはEDNSのOPT疑似レコードに空のNSIDオプションを入れる。問い合わせ側は識別データを入れてはならない。IANA登録簿が示すオプション番号は3。対応するネームサーバーがその要求を受け入れれば、応答のOPTに識別バイト列を入れる。問い合わせに余計なNSIDデータがあれば無視する。求めていないリゾルバーへ勝手にNSIDを送り返すこともできない。

返す値はホスト名に限定されない。RFCは不透明なバイト列として扱い、実際の機械名、保守用IP、安定した乱数、動的な値、署名または暗号化したデータまで選択肢として挙げる。共通仕様は「どこで尋ね、どこで返すか」を揃える。何を公開するかは運用者が決める。外部の障害報告をすぐ読める名前にするか、内部台帳でだけ意味が分かる印にするかで、調査の進み方が変わる。

隠したい保守アドレスをそのまま返すと、共通アドレスの陰に置いたノードの一覧を外へ渡すことになる。安定した仮名なら比較には使え、実体との対応は内部に残せる。頻繁に変わる値は外部からの追跡を難しくする一方、数時間後に届く報告を内部ログに結び付けにくくする。RFC 5001の安全性の節は、NSIDをDNSSECが保護するDNSデータとは別の通信路上の信号と位置付ける。名乗りの真正性を争うなら、通信路の保護か運用記録による照合が要る。

L-Rootは読める名前を返した

L-Rootの運用者は2014年、anycastノードを外部から識別するために配備した仕組みを記録した。その一つがNSIDで、応答ノードの完全なホスト名を返していた。文書に載るdigの出力では、十六進数の列がytz01.l.root-servers.orgという名前に読める。不透明なフィールドの中身を、運用者が公開可能な名称にした例だ。

同じ記録にはHOSTNAME.BINDやID.SERVERを使う別の識別方法もある。これらはその追加の問い合わせに答えたノードを示す。経路が変われば、問題の応答を出したノードとは違う。問題を起こした問い合わせ自体にNSIDを付けると、その時の答えと名乗りを同じ記録として残せる。復旧後に別ノードへ何度問い合わせても、元の一組は変わらない。

文書が示すのは2014年に公表されたL-Rootの運用であり、現在の全ルートサーバーの一覧ではない。個別の障害では、元のクエリ、応答、NSIDの生データ、送信元、転送方式、時刻を保存する。識別子から実際のノードやプロセスを引くには運用者の台帳が必要だ。ノード名は調査の索引であり、故障原因そのものではない。

再帰サーバーは自分の名を答える

NSIDはホップごとの仕組みだ。端末が再帰リゾルバーにNSIDを要求すれば、その再帰リゾルバーが自分を識別する。再帰リゾルバーが権威サーバーへ別のNSID要求を送ることはできるが、そちらは別の問い合わせだ。端末へ戻るNSIDが上流の権威ノードの名に化けることはない。端末が求めなかった場合には、サーバーがNSIDを自発的に付けることも禁止される。

再帰応答の背後でどの権威サーバーが答えたか知りたければ、再帰側の上流通信を採取する。下流の一つの印には、経路全体の足跡は入っていない。これは責任分担の線でもある。再帰サーバーの標識を見て、根拠なく上流の機械を責めることはできない。実際の上流通信と各ノードのログが、答えの出所をつなぐ。

共通アドレスの後ろに名前が戻った

RFC 5001はサービスアドレスを分割しなかった。特定の応答に、応答した機械が選ぶ印を添える小さな場所を作った。IANAが番号を管理し、運用者が印の意味を決め、リゾルバーが要求と保存を担当する。故障調査の一番厄介な隙間に、それぞれの仕事が割り当てられた。

サーバーには回答を控える自由もある。NSIDの追加バイトで大きなDNS応答が切り詰められる可能性があるため、返送は常に任意だ。NSIDのない採取結果から分かるのは、そのやり取りで印が返らなかったことだけ。どの機械だったかは別の記録から探す必要がある。

一つのIPが多数の機械の代わりに応対するのは、サービスを届けるうえで便利だ。壊れた答えを調べる時には、その共同名義が邪魔になる。2007年の仕様は、返事をした機械にその返事の横で名乗らせた。次の問い合わせが別のノードに着いても、最初の応答の証拠は取り違えずに済む。