要約

  • RFC 10037は、RDAPのドメインおよびネームサーバーオブジェクトに任意のttl0_dataメンバーを追加する。
  • 公開されるTTLはレジストリで設定された値であり、DNS問い合わせで観測した残存時間ではない。

数字が答える問いを取り違えない

RDAPは以前から、ドメインに関係するネームサーバー、グルーアドレス、DSレコードを示せた。しかし、それらのRRsetに設定されたTTLは伝えられなかった。TTLは単なる数字ではない。リゾルバーが次の問い合わせまでどれだけ長く同じ集合を再利用できるかという運用意図を表す。

RFC 10037のttl0_dataでは、valuesがDNSタイプのニーモニックとTTLを対応づけ、必要ならRDAPの備考も付けられる。サーバーがこの情報を公開するかは任意だ。ただし公開する応答は、rdapConformanceでttl0を宣言しなければならない。

最も重要なのは値の出所である。TTLはレジストリのデータベースにプロビジョニングされた値でなければならず、ライブDNS問い合わせで減少中の残存時間ではない。3,600という表示は、そのRRsetについて一時間が登録されていることを示すだけだ。すべての権威サーバーが同じ値を返すこと、各キャッシュに変更が届いたこと、あるキャッシュの期限がちょうど3,600秒後であることまでは証明しない。

この区別が障害対応を助ける。運用者は、レジストリの設定、権威応答、再帰リゾルバーのキャッシュを別々の事実として比較できる。食い違いがあれば、プロビジョニング、公開、伝播、キャッシュのどこを調べるべきか絞り込める。RDAPは帯域外の照合点であって、リアルタイム監視ではない。

公開の裁量と標準化された意味

拡張が任意である以上、公開する権限はレジストリに残る。一方、公開したデータの意味は標準に従う。タイプ名はIANA登録済みの大文字ニーモニックでなければならない。TTLは個々のレコードではなくRRsetに適用される。JSON値は小数や指数表記を使わない整数で、範囲は0から2,147,483,647までだ。

標準は語彙、形式、適合性の合図を管理する。レジストリは情報を出すかどうかと、データベースで表す値を管理する。クライアントは実装方法を選ぶ。設定値を共有しても、誰かがライブDNSの支配権を得るわけではない。

受益者は、内部のプロビジョニング環境へ入れないレジストラ、登録者、DNS事業者、インシデント対応者だ。ただしRFC 10037は、データベースの鮮度、変更の権限、実際のDNSとの一致を保証しない。

開かれた型はクライアントに負担を移す

クライアントは、将来追加されるものを含め、すべての有効なDNSタイプをvaluesで受け入れる必要がある。JSONを固定クラスへ自動変換する仕組みは、正しい新タイプを不正な応答として捨てるおそれがある。そのため実装者は動的な表を切り分け、IANAの登録内容を追う必要がある。

RDAPでの公開と、RFC 9803によるEPPでの設定も別の判断だ。EPP拡張を実装せずにRDAP拡張だけを実装できる。値が見えても、誰が選び、どの方針が制約し、誰が変更できるかは分からない。RFC 10037は、TTLの決定、割り当て、変更に伴う安全上の問題を対象外としている。

根拠、反実仮想、未確認事項

この拡張がなければ、RDAPは関連するDNSレコードを示せても、レジストリで設定されたTTLは示せない。運用者は稼働中のDNSかレジストリ固有の経路に頼り、標準化された帯域外の照合点を持てない。これは仕様の機能から導く反実仮想であり、測定結果ではない。

一次資料は、ttl0_dataを導入したレジストリ数、障害時間の短縮、オブジェクト間での一様な公開、顧客やレジストリの行動変化を示していない。特定実装がある時点で正確かどうかも未確認である。これらは標準本文から推定せず、別途測定すべきだ。

情報源