要約

  • RFC 1794は、DNSの通信方式を変えずに、サーバー負荷に応じてアドレスの順序を変えようとした1995年の議論を伝える。
  • 権威サーバーは優先順位を示せても、キャッシュ、セカンダリの更新、クライアント側の並べ替えを制御できず、接続先の確定までは担わなかった。

順序付きの応答は接続命令ではない

同じ役割を果たすサーバーが複数あるなら、空いている機械を先頭に置きたいと考えるのは自然だ。しかしDNSが返すのはレコードであり、アプリケーションの接続を代行するものではない。RFC 1794の議論は、この二つを分けている。応答の順番には意味を持たせられるが、クライアントがその順番を守る保証はない。

1995年4月に出たこの文書はInformationalで、「Internet標準を定めない」と明記する。著者はDNSワーキンググループでの検討と代替案を記録しようとした一方、経緯の一部が欠けている可能性も認めていた。したがって、これは設計議論の記録であり、導入件数や性能を示す統計ではない。

アドレスの交替から負荷の観測へ

RFCの著者は、BINDのアドレス順を変える改造が現れた時期をおよそ1986年と記す。Bryan BeecherのShuffle Address改造やMarshall RoseのRound Robinコードを、広く配布された可能性のある例に挙げる。年代も普及度も、独立した調査結果ではなく後年の回顧として読む必要がある。

順番を交替させれば先頭のアドレスは変わるが、各サーバーの実負荷は測れない。RFC 1794は、TGVのMatt Madisonによる改造を別の例として紹介する。VMS固有の機能を使って負荷を調べ、最も軽いホストから順にAレコードを返す方法だった。実態を反映しやすい反面、特定OSへの依存とDNSレコード処理の変更が必要だった。単純な輪番は移植しやすいが負荷を見ず、負荷計測型は詳しいが汎用性に欠けた。

互換性を守るため、動的処理を別の場所へ

RFCが記したワーキンググループの条件は、既存DNSとの後方互換、頻繁な情報更新、複数アドレスの返却、他のレコード種別との整合、さまざまな負荷指標への対応、短い計算時間だった。通常の更新間隔は5分とされ、60秒も想定されたが、これは実測された性能ではない。優先ホストがTTLの期限前に故障した場合に備え、複数の候補を返す考えも記されている。ただし、それは復旧保証ではない。

プロトコルや新しいレコード種別を変えると、既存実装との互換性を損なう恐れがある。そこでRFCは、Rob Austeinの提案として、ゾーン転送プログラムを賢くする案を説明する。プログラムが負荷情報を取得し、ゾーン情報を並べ替えてネームサーバーに渡せば、DNSメッセージ形式を変えずに済む。変化するのは照会の経路ではなく、ゾーン情報を準備する段階だった。

複雑さは移動しただけでもある。ゾーン転送が更新するのはセカンダリで、プライマリは転送を介して自分の照会に答えるわけではない。短期間で変化するサブゾーンには刷新間隔の設定が必要で、解析器へ配るTTLも短くする必要があった。新しい順位を計算する時間が、その情報の有効期間を超えてもいけない。権威側で新しく作った順序が、キャッシュを通る間に古くなることもある。

最後に選ぶのはクライアント

RFC 1794はDNSが応答順を保証しないと述べる。著者は順序に一定の予測可能性がある一方、クライアントがsortlistなどのローカル設定でアドレスを並べ替える場合もあると説明する。ゾーン転送プログラムは、遠隔クライアントの選び方を予測できない。複数アドレスが返っても、全候補を試すこと、次のホストが健全であること、アプリケーションの処理が完了することまでは証明しない。

ここでの歴史的な焦点は、DNSが負荷分散装置になったことではなく、制御範囲を分けて考えたことにある。運用者は順位を計算して公開できる。セカンダリとキャッシュは情報の伝わる時期を決め、クライアントは実際の接続先を選ぶ。RFC 1794はその境界内での方法を記すが、普及の規模や運用成果は示していない。

出典