Summary

  • APNICに寄せた実測記録で、Geoff HustonはキャッシュのないBIND 9.20.23からwww.potaroo.netを引き、4回の問い合わせでアドレスに届いた。
  • teams.microsoft.comではHustonのBIND 9.20が94回。別の条件で報告された9.16の247回、9.21の29回は、製品の速度比較ではなく、初回照会がたどる依存関係の手掛かりだ。

DNSの説明図では、矢印はたいてい一本で済む。ブラウザーが名前を尋ね、答えが返る。Hustonはその矢印の内側を見た。APNICの主任科学者である彼が使ったローカルのBINDには、以前の問い合わせから残った情報がない。www.potaroo.netを引くと、ルート、.net、potaroo.net、最後のアドレスという順に4回質問した。ここまでは素直な道のりだ。

ところが別名が重なると、一本の矢印は何度も描き直される。Hustonの報告には、Ondřej SurýがBIND 9.16でteams.microsoft.comを引いた際の247回、Hustonが9.20で見た94回、Surýが9.21で見た29回が並ぶ。環境を揃えた競争の結果として読めば間違える。むしろ注目すべきは、利用者には一つの名前でも、解析器には一連の探索が渡されることだ。

この例にはCNAMEが4段ある。別名に出会うたび、解析器は別の名前の解決を始める。手元に残った委任情報を使える段階もあれば、.netまで戻る段階もある。権威サーバーの名前が分かっただけでは、そのサーバーへ送るためのIPアドレスは得られない。委任先の区域内にあるサーバーならglueが橋を架ける。ほかのドメインやトップレベルドメインに名前を散らせば、橋を探すための質問も増える。

DNSSECによる検証は鍵の取得を加える。障害への備えとして候補サーバーを先に調べる解析器は、正常時にも追加の問い合わせを払う。発行者は別名と委任先を配置できるが、その初回の作業を行うのは各地の解析器だ。温まったキャッシュは、その分担を見えにくくする。

Hustonの記録から、世界全体の遅延や障害件数は算出できない。運用上の影響を数えるには、同じ設定で経過時間と障害時の動きを測る必要がある。それでも設計会議で問うべきことは明快だ。新しい別名を一つ足すと、初めて来た解析器はどこまで歩かされるのか。