Summary

  • RFC 10037, published in August 2026, lets RDAP domain and nameserver responses optionally expose DNS TTL values provisioned in a registry database through ttl0_data. It explicitly says these are not the remaining TTLs observed in live DNS queries.
  • The extension improves out-of-band diagnosis without collapsing authority. Registry policy, the accepted configuration, authoritative publication, each resolver's cache state and the final service result still require separate evidence and reconciliation.

Imagine a domain moving its delegation at noon. The change plan says to lower the NS TTL from one day to five minutes first. At 11:55, a dashboard displays 300. That number can be true in the registry database and still be too late to make noon safe. A resolver that cached the older RRset at 11:54 may retain it under the earlier value. Another may have evicted it. A third may be unable to refresh and apply a stale-answer policy.

The number is not wrong. The conclusion drawn from it is too large.

RFC 10037, published on the IETF Standards Track in August 2026, creates a standard RDAP representation for this configured value. A supporting server may place ttl0_data in a domain or nameserver object. Its values member maps uppercase, IANA-registered record-type mnemonics to JSON integers between zero and 2^31−1. If the extension is used, the response carries ttl0 in rdapConformance.

The decisive sentence is also the boundary: the value must reflect the TTL provisioned in the registry database, not the remaining TTL observed from a live DNS query. RDAP has become a witness to one administrative state. It has not become a remote control for caches.

One field, five different states

A change crosses at least five clocks and ledgers.

First, registry policy defines the permitted surface. RFC 9803 allows an EPP server to restrict which record types a sponsoring client may configure and to impose minimum, default and maximum values. The operator may disregard a requested value for security or stability, make an out-of-band change, or reset a temporary value to the default later.

Second, the registry database holds the accepted configuration. This is the state RFC 10037 exposes. It may reflect an EPP request, a portal action, a default or an operator intervention. The RDAP response does not have to disclose which path produced it.

Third, zone generation and authoritative servers publish an RRset and its TTL. Registry acceptance and authoritative appearance are separated by processing and distribution time. Only an authoritative observation can show what a particular server answered at a particular moment.

Fourth, a recursive resolver stores what it received and counts locally. RFC 9499 describes TTL as a maximum cache lifetime. A cache may shorten it for local policy or remove the RRset early. Once evicted, the remaining value is no longer available because the cached RRset no longer exists.

Fifth, the application reaches a destination and produces a useful result. A new NS or DS answer is not proof that the website, mail service or DNSSEC chain works. Configuration, reachability, validation and application canaries remain distinct.

Treating these states as one creates false certainty. Treating them as a chain makes the change governable.

ttl0_data reports; it does not grant the pen

The RDAP addition is optional. A server may omit it. A client that does not understand the member should ignore it under the extension rules of RFC 9083. A supporting client must accept all valid DNS record types in the values map and should keep its knowledge aligned with the evolving IANA DNS Parameters registry.

That design prevents a client from mistaking today's familiar set—NS, DS, A and AAAA—for a permanent ceiling. It also denies the client a convenient assumption: an unfamiliar type is not evidence of a malformed response merely because local software is old.

The IANA RDAP Extensions registry gives ttl0 a shared name. Registration establishes vocabulary, not adoption. It does not show that any particular registry emits the field, that a registrar allows customers to choose values, or that a resolver consults RDAP.

RFC 10037 is complementary to the EPP mapping but does not require it. A registry may publish its own configured TTL through RDAP while retaining all write decisions internally. Read visibility and mutation authority remain separate.

A shorter number has to arrive before the change

RFC 9803 identifies a common operational error: lowering the TTL during or after the substantive record change. Existing caches are not retroactively edited. The recommendation is to publish the lower value at least one current-TTL interval before the planned change and also account for the latency between receipt of the registry command and actual DNS publication.

That recommendation produces an evidence sequence rather than a ceremonial wait:

  1. establish the earlier TTL and the registry's current policy;
  2. submit the lower value through an authorized channel;
  3. confirm the accepted value in the registry state;
  4. observe the lower value on every applicable authoritative service;
  5. wait out the prior effective caching window from proven publication, not from button click;
  6. change the underlying NS, DS, address or other data;
  7. compare authoritative and diverse recursive answers, then test the service;
  8. restore the normal TTL only after the new state and rollback path are stable.

Even this sequence does not create a universal deadline. RFC 2181 makes the TTL an RRset property and requires equal values across its records. RFC 1035 defines the ordinary discard interval. RFC 8767 separately permits bounded stale service after a good-faith refresh fails. Expiry is therefore a duty to reconsider the source, not a guarantee that every implementation has erased every old answer.

The security trade is carried by the policy owner

Short values help planned change and rollback, but they increase query load and can improve the agility of fast-flux infrastructure. Long values reduce routine query pressure and can prolong damage if an attacker with a compromised registrar account changes delegation data and then extends its cache lifetime.

RFC 9803 therefore leaves limits and overrides with the registry operator. That local authority has to bear both sides of the choice: the registrant's need for a reversible transition and the shared DNS cost or abuse exposure created by extreme values.

The RDAP field can make that choice visible. It cannot make it prudent. Nor does transport protection prove the field correct. RFC 7481 places RDAP authentication, authorization, confidentiality and integrity in supporting protocol layers. A protected response can faithfully carry a stale, misprovisioned or operationally irrelevant value.

The useful output is a reconciled change ledger

For each delegation change, retain the actor and authorization, the policy version, the earlier TTL, the accepted registry value, the EPP transaction or equivalent confirmation, the RDAP observation time, the zone publication version, authoritative answers from each server, recursive observations from several networks, DNSSEC results, the application canary and the rollback decision.

The clocks should remain named. “TTL elapsed” is incomplete unless it says which earlier value, received by whom, from which authoritative answer, at what time and under which local cache policy. “RDAP shows 300” is incomplete unless the authoritative zone and the intended RRset match.

Heng Lu's running-code principle places the proof in this executed path. His distinction between formal and practical data control explains why the registry does not own copies already held by recursive operators. His model of a minimum shared specification with localized future decisions fits RFC 10037 closely: the standard names a narrow observation; each operator retains policy, timing and consequences.

The achievement is not a globally synchronized clock. It is a common way to say which clock the registry is showing.