要約

  • 2026年8月に公開されたRFC 10037は、RDAPのドメインおよびネームサーバーオブジェクトにttl0_dataを任意で追加し、レジストリDBに設定されたDNS TTLを示せるようにした。DNS問い合わせで見える残り時間ではない。
  • 観測可能性が増えても権限は統合されない。ポリシー、受理された設定、権威DNSの応答、各リゾルバのキャッシュ、アプリケーションの結果を個別に照合する必要がある。

NSを正午に切り替える作業を考える。レジストラは事前にTTLを一日から五分へ下げ、11時55分にRDAPで300を確認した。しかし11時54分に旧RRsetを一日のTTLで取得したリゾルバがあれば、そのコピーは新しい表示とは別の時間を持つ。管理画面の保存操作は、既存キャッシュに通知を送らない。

早めにキャッシュを捨てるリゾルバもある。更新に失敗した場合、条件を限定して期限切れデータを使うリゾルバもある。この違いは、レジストリの値が誤っていることを意味しない。値が証明する範囲を越えて読んだことが問題である。

RFC 10037は2026年8月のIETF Standards Track文書である。対応するRDAPサーバーはdomainまたはnameserverオブジェクトにttl0_dataを含められる。valuesは、IANA登録済みで大文字のDNS RRタイプ名を、0から2^31−1までの小数部を持たないJSON整数へ対応づける。使用時はrdapConformanceにttl0を入れる。

規格は証拠の境界も明記した。値はレジストリDBにprovisionされたTTLであり、実際のDNS問い合わせから得た残存TTLではない。RDAPは設定の外部証人になったが、リゾルバのタイマーにはなっていない。

読み取りの標準化は変更権限の移転ではない

ttl0_dataの提供は任意である。非対応クライアントはRFC 9083の拡張規則に従い、未知のメンバーを無視する。対応クライアントは有効な全DNSタイプを受け入れ、IANA DNS Parametersの更新に追随すべきである。古いライブラリが知らないタイプを、サーバーの異常と決めつけてはならない。

IANA RDAP Extensionsにttl0が登録されたことで、意味を共有できる。登録は実装数、利用率、特定事業者の対応を証明しない。

TTLを設定する側には別の規格がある。RFC 9803のEPP拡張では、サーバーが対象RRタイプ、最小値、既定値、最大値を決められる。安定性や安全のため要求値を使わず、帯域外で変更し、一定時間後に既定へ戻すこともできる。RFC 10037はこれと補完関係にあるが、実装を前提としない。

つまり、レジストリは自ら決めた値をRDAPで公開しつつ、外部に設定権限を与えない運用もできる。可視化された値を顧客の権利と取り違えてはならない。

一つの変更に五つの状態がある

ポリシーは、誰がどのRRsetについてどの範囲を選べるかを決める。レジストリDBは受理後の値を保持し、RDAPがそれを示す。ゾーン生成と権威サーバーは実際のRRsetを公開する。再帰リゾルバは過去に受け取ったコピーをローカルに保持する。最後にアプリケーションが、新しい宛先やDNSSEC連鎖が実用になるかを確かめる。

RFC 2181ではTTLはRRsetの属性で、同じ集合内の値は一致すべきものとされる。RFC 1035は通常のキャッシュ期間を定める。RFC 9499はTTLを最大時間として説明し、運用ポリシーによる短縮や早期削除を区別する。削除後は残り時間そのものが存在しない。

一方、通常の期限を過ぎれば必ず消えるとも限らない。RFC 8767は、適切な再取得が失敗したときに古いデータを限定的に提供する例外を定める。この判断はリゾルバの可用性対策であり、レジストリ設定を書き換えるものではない。

変更窓は権威掲載を確認してから数える

RFC 9803は、実データの変更と同時または変更後にTTLを下げる誤りを挙げる。古い値で保存済みのコピーを短縮するには遅い。短いTTLは、少なくとも以前のTTLに相当する期間だけ先行して掲載し、さらにレジストリ受付からDNS公開までの遅延を考慮する必要がある。

手順は、旧値とポリシーの確認から始まる。認可された経路で短縮を要求し、DBでの受理を確認し、すべての対象権威サーバーが短い値を返すことを観測する。その証明時刻から旧期間を待った後、NS、DS、A、AAAAなどの内容を変える。複数ネットワークの再帰観測、DNSSEC検証、サービスcanaryで結果を確かめ、rollbackの材料を保持したまま通常TTLへ戻す。

レジストラの操作時刻は事務時刻である。安全側の技術時刻は、短いTTLが権威DNSに掲載された最初の実証時刻から始まる。

値の長短は費用と攻撃面を動かす

短い値は切替えと復帰を速めるが、問い合わせ量を増やし、fast fluxの機動性を高める可能性がある。長い値は通常負荷を抑える一方、侵害されたアカウントがNSやglueを変更した場合、その影響を発見後もキャッシュに残しやすい。

この両面を負うため、レジストリ運営者が上下限とoverrideを持つ。RDAPで公開されたからといって、その判断が安全だと認証されたわけではない。RFC 7481ではRDAPの認証、認可、機密性、完全性を他層のサービスに依存させている。安全な伝送は、値がゾーンや利用結果と一致することまで保証しない。

共通の変更台帳で時系列を結ぶ

残すべきものは、実施者と認可、ポリシー版、旧TTL、EPP取引または同等の確認、時刻付きRDAP応答、ゾーン版、各権威応答、複数の再帰観測、DNSSEC結果、サービスcanary、rollback判断である。すべての時刻に対象RRsetと観測地点を付ける。

Heng LuのRunning Code優先は計画ではなく実際の経路を証拠にする。形式的なデータ主権と実務上の支配の区別は、外部リゾルバに渡ったコピーをレジストリが操作できない理由を示す。最小の初期仕様と局所的な将来判断は、共通フィールドを狭く定め、採用、制限、時系列、結果を現場に残すRFC 10037の構造と一致する。

この規格が作ったのは一斉に動く時計ではない。レジストリがどの時計を公開しているかを明示する言語である。