要約

  • RFC 1912は、NSであるゾーンのサーバーとして列挙されながら、実際にはそのゾーンを提供しない状態をlame delegationと説明した。
  • 委任の追加も削除も単一の時刻では完了しない。遠隔運用者の同意、ゾーンの読み込み、親子の公開、転送、キャッシュの失効が別々に進む。
  • NSレコードは問い合わせ先を示せても、現在の権威応答までは保証しない。移行の成否は各サーバーを実際に問い、古い経路が消えるまで観測して初めて分かる。

削除ボタンの後にも問い合わせは来る

あるセカンダリを廃止する日を考えてみる。子ゾーンの設定を直し、親側の委任からも名前を外した。管理画面では新しい構成しか見えない。だが、変更前のNSやアドレスを保持する再帰リゾルバは、TTLが尽きるまで旧サーバーを正規の行き先として扱う。

RFC 1912は、移転または削除されたセカンダリに古いキャッシュ経由の問い合わせが続くことを警告し、必要なキャッシュ期間は旧側でもサービスを継続するよう勧めた。変更の記録は未来を指していても、利用者の一部はまだ過去の経路を歩いている。

これは単なる伝播の遅さではない。子ゾーンの編集時刻、親ゾーンへの反映時刻、各サーバーの再読み込み時刻、ゾーン転送の成功時刻、最後の古いキャッシュが失効する時刻は、それぞれ別の出来事である。どれか一つのタイムスタンプを「完了」と呼べば、観測していない区間が残る。

追加はこの時間軸を逆向きにたどる。サーバーを用意し、ゾーンを読み込ませ、応答を確かめてから、最後に親側へNSと必要なglueを追加する。RFC 1034が親への登録を設置の最終段階に置いたのは、紹介だけを先に走らせないためだった。

親が作れるのは紹介まで

DNSのゾーンカットでは、親ゾーンがNSレコードによって子の問い合わせ先を示す。必要なら到達に使うglueも添える。リゾルバはその紹介を受け、列挙されたサーバーへ向かう。

しかし親側の運用者は、別組織のサーバーへゾーンをインストールできない。サーバー名を公開する権限と、その機械に役割を受け入れさせる権限は分かれている。紹介が正しく返り、ネットワーク上も到達できるのに、問い合わせ先が子ゾーンについて権威応答を返さない――その成功した前半と失敗した後半の組み合わせがlame delegationである。

RFC 1537は1993年、この断絶を「secondary server surprise」として記録した。登録情報によって知らないうちにセカンダリとされ、問い合わせを浴びてから初めて気づくホストがあった。管理者は依頼されていないどころか、知らされてもいなかった可能性がある。紙の上の担当割り当てが、人間同士の合意を追い越していた。

RFC 1912は1996年2月、この運用上の教訓を引き継いだInformational文書であり、RFC 1537を置き換えた。典型例では、子ゾーンのNSに外部サーバーが含まれているが、そのホストマスターは正しいセカンダリ設定を完了していない。DNSはそこにゾーンがあるべきだと述べ、実機はないと答える。

同文書は、人気のあるネームサーバーを勝手にNSへ追加すれば余分なサービスを得られると期待したサイトも報告している。ただし、これは当時の運用報告であり、特定の主体や発生率を立証するものではない。確かに分かるのは、指名が相手の同意を代行しないということだ。

一つの名前に五つの状態が重なる

NSに現れる一つのサーバー名の背後には、少なくとも五つの状態がある。その名前が掲載されていること、アドレスへ到達できること、子ゾーン用に設定されていること、十分に新しいコピーを保持すること、そして問い合わせへ権威的に応答することである。

これらは連動しても同義ではない。DNSプロセスが稼働し、他の多数のゾーンへ答えていても、対象ゾーンだけを持たないことがある。正しく開始したセカンダリも、更新失敗が続けばコピーを失効させる。親と子のNS集合が一致していても、同じ誤ったサーバーを双方が載せているだけかもしれない。

RFC 2181は、子ゾーン頂点のNSが子側の権威データであり、親側のNSはリゾルバを下へ送る委任データだという役割の違いを明確にした。RFC 8499の後年の用語でも、referralと、あるゾーンへ答えるよう設定されたauthoritative serverは別物である。

したがって集合比較だけでは監査にならない。RFC 1713がデバッグの実務で示したように、列挙された各サーバーを実際に問い、その振る舞いを調べる必要がある。名前は検査対象を決める。権威応答は稼働事実を示す。

二台という数字より、二つの稼働コピー

複数のネームサーバーを置く目的は、一つの障害で名前解決を失わないことにある。ところが二つのNSのうち一つがlameなら、記録上の二重化と実際の二重化は一致しない。

障害は一様に見えない。あるリゾルバは健全なサーバーを選び、別のリゾルバはゾーンを持たない方へ先に向かう。キャッシュ、再試行、アドレス選択、観測時刻によって、同じドメインがある場所では正常、別の場所では遅延や失敗となる。運用者が一度だけ試して健全側を引けば、問題は存在しないように見える。

RFC 1912は、良くても余計なDNSトラフィックを生み、悪ければホストを解決できずメールが戻るとした。すべての問い合わせが最悪の経路を通るとは述べていない。その間欠性こそ、紙面の冗長性が長く温存される理由だった。

証明すべき分母はNSの件数ではなく、関連ネットワークから到達でき、対象ゾーンを設定済みで、十分新しいデータを持ち、権威応答するサーバーの件数である。

記録は稼働状態の後を歩く

この小さなDNS障害では、レジストリ記録と稼働中の関係との差をそのまま観測できる。親は自分の紹介を公開できる。セカンダリ運用者は機械が役割を受けるかを決める。子はゾーン内容を管理し、リゾルバはキャッシュと再試行を選ぶ。誰も全経路を単独では支配しない。

インターネットに必要なのは、全員を一つの運用主体へまとめることではなく、最小限の共通形式と、境界ごとに確認できる証拠である。新しいNSは、相手の受諾と権威応答を得てから公開する。古いNSは、キャッシュの尾が消えるまでサービスを残す。親子の集合、転送、新鮮さ、実応答を別々に見る。

lame delegationが残した歴史的な教訓は、間違った一行を直せというだけではない。公開には開始時刻があるが、委任の完成には観測期間がある。記録が先に役割を作ったことにしてしまえば、その間の問い合わせと利用者が不一致の費用を負う。

出典