要約

  • 委任のNS情報は親ゾーンと子ゾーンの両方にあり、TTLが一致するとは限らない。子側のTTLを短くしても、すでに親側の長い値で満たされたキャッシュは消せない。
  • RFC 9199が紹介する測定では、およそ90%が子側のTTLを、約10%が親側を基準にするように見えた。ネームサーバーのアドレスも、bailiwickの内外で保持のされ方が異なる。
  • 旧基盤は少なくとも親・子TTLの大きい方まで稼働させる必要がある。停止の判断には、最後のキャッシュ投入時刻、A/AAAAの寿命、リゾルバー群ごとの最終旧経路観測も必要になる。

設定変更と利用者の現在は同時ではない

ゾーン運用者が新しいNSを公開すると、管理面では変更が完了したように見える。子ゾーンの短いTTLを一回待ち、新サーバーの応答を確認し、旧サーバーのトラフィックが減れば、停止ボタンを押す根拠はそろったように思える。

しかし、委任情報には二つの掲載場所がある。親ゾーンは子へ向かうNSを示し、到着した先の子ゾーンも自分のNSを返す。名前は整合しているべきだが、キャッシュ時間まで同じとは限らない。子の運用者が変えられるのは、原則として自分が公開する値だけである。

RFC 9199は、ルートにあるTLDのNSが48時間である一方、TLD自身が一時間という短い値を出す例を挙げる。どちらもそれぞれの権限面で有効だ。再帰リゾルバーがどちらをキャッシュ寿命の基準にするかで、同じ変更に対する「現在」が分かれる。

Giovane Moura、Wes Hardaker、John Heidemann、Marco Davidsによる調査では、観測されたリゾルバーのおよそ九割が子中心、一割が親中心に見えたとRFC 9199はまとめている。この比率を現在の全世界に固定してはならない。それでも、少数派を切り捨てた停止計画が危険だという結論は変わらない。

短くしたTTLは過去のキャッシュに届かない

TTLは遠隔消去命令ではない。データを受け取った時点でキャッシュに与えられる寿命であり、権威サーバー側から残り時間を縮める手段はDNSにはない。今日一時間へ下げても、昨日48時間で取得された委任はそのまま期限まで生きる。

予定変更の前にTTLを下げる手法は、順序を守れば有効だ。まず小さい値を関係する各面で実際に公開し、以前の大きい値による最後の投入が失効し得るまで待つ。その後に切り替える。子だけを短くし、親の長い値を放置したまま子の一時間だけ待つのは、この手順を半分しか行っていない。

RFC 9199は、旧基盤を親と子のTTLの最大値まで少なくとも稼働させるよう求める。最大値は安全の証明ではなく、計画の下限である。親での実際の反映時刻、旧値が最後にキャッシュへ入った可能性、さらにネームサーバーアドレスの別の期限を確かめなければならない。

長いTTLには、キャッシュ応答の速さ、権威への問い合わせ削減、費用低下、短い障害への耐性という利点がある。短いTTLには移行や負荷分散の機動性がある。どちらかが常に正しいのではない。問題は、子の機動性を親や再帰側にも自動で適用されたものとして扱うことだ。

名前とアドレスには別々の余命がある

NSが示すのはネームサーバー名であり、実際に問い合わせるにはAまたはAAAAが要る。そのアドレスをどの経路で得たかが、停止可能時刻をもう一度分岐させる。

ネームサーバーが子ゾーンのbailiwick内にある場合、循環参照を避けるため親がglueを添えることがある。RFC 9199が扱う観測では、NSが先に期限切れになると、多くのリゾルバーはin-bailiwickのアドレスについてglueが必要な時点で再取得した。元のアドレスTTLが長く見えても、NS更新に伴って新しいアドレスへ移ることがある。

out-of-bailiwickの名前は、通常は別のDNS解決でアドレスを得て独立にキャッシュする。そのためNSが失効しても、古いA/AAAAの残り寿命が保たれ得る。新しいNSを見たことと、新しい宛先へ送ったことは同じ証拠ではない。

変更記録には、親・子双方の新旧NS RRset、全アドレス、各TTL、bailiwick区分、低い値が権威データとして有効になった時刻、旧値が最後に投入され得た時刻を残す必要がある。「NS TTLは一時間」という一行だけでは、判断に必要なアドレス経路が消えてしまう。

RFC 2181はDNSデータの出所に応じた信頼度を整理しているが、それは子の回答で全キャッシュを上書きする仕組みではない。親は親ゾーンと委任に対して権威を持ち、子は子ゾーンのデータに対して権威を持つ。再帰リゾルバーは、受け取った文脈と残り寿命に従って保持する。

「新が見えた」ではなく「旧が最後に見えた」を記録する

証拠作りは切り替え前に始める。両面のRRset、TTL、アドレス、公開時刻を保存し、各旧値による最終投入の境界を求める。旧サーバーは単に電源が入っているだけでなく、その期間を通じて正しく権威応答できなければならない。

観測点は複数の再帰実装とネットワークに分ける。分かる範囲で実装・版、時刻、回答元、残TTL、最終的に到達した権威エンドポイントを記録する。最初の新経路は、新しい選択肢が存在することしか示さない。必要なのは、各リゾルバー類型とアドレス経路で旧値が最後に観測された時点である。

旧サーバーの問い合わせがゼロになっても、世界中のキャッシュが空だとは証明できない。観測範囲に該当する問い合わせがなかっただけかもしれない。大手パブリックリゾルバー一社も全実装の代理ではない。親側を確認できない、キャッシュ方針が不明、期限切れ回答を許す、といった条件は不確実性として残す。

停止後には別の受入試験を行う。対象とした再帰経路が委任を取得し、アドレスを解決し、有効な権威サーバーへ到達できることを確かめる。新レコードの公開は指示であり、旧経路の不使用を観測した記録が停止の受領証になる。

功績の範囲と権限の範囲を混ぜない

RFC 9199の著者はMoura、Hardaker、Heidemann、Davidsの四人である。Independent StreamのInformational文書であり、IETFの合意やInternet Standardではない。保存時点のIETFプロフィールは、Wes HardakerのDNS研究、長年のIETF活動、B-root運用への関与を示す。これは問題設定との関係を説明するが、共同研究を単独の功績にはしない。

Heng Luのagencyの考え方で見ると、親は委任を、子は自分のコピーを、再帰実装と運用者はキャッシュ動作を、権威基盤チームは旧設備の撤去を決める。各主体の判断が正しくても、他者の時計を消した瞬間に全体では事故になり得る。

初期DNS仕様は、委任・キャッシュ・TTLという最小限の共通機構を定め、将来の運用判断を一つの中央へ集めなかった。局所的な選択を残す設計だからこそ、実際のコードとログで結果を確認する必要がある。

台帳は主体を支配するものではない。親、子、アドレス、停止という別々の決定を同じ証跡へ結びつける道具である。旧サーバーを残すのは変化を恐れるからではない。まだ有効な過去を持つキャッシュに、到達可能な行き先を約束するためだ。

出典