RFC 10037

Title Block 🎀

Okay so bestie, this is RFC 10037 ✨ and its title is Registration Data Access Protocol (RDAP) Extension for DNS Time-to-Live (TTL) Values. G. Brown from ICANN wrote it, it's on the Standards Track, it's dated August 2026, and its ISSN is 2070-1721. It's an IETF document, and its title block doesn't list anything it obsoletes or updates. 💅

Abstract ✨

So this doc adds an extension to the Registration Data Access Protocol (RDAP) that lets the Time-to-Live (TTL) values for the relevant DNS record types show up in RDAP responses. 🦋

Status of This Memo 🌷

This is an Internet Standards Track document. 💖

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 🌸

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10037. 🫶

Copyright Notice 🔥

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please review those carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Revised BSD License. ⭐

Table of Contents 🧚

1.  Introduction
2.  Conventions Used in This Document
3.  RDAP Response Specification
  3.1.  DNS Record Types and TTL Values
  3.2.  RDAP Conformance
4.  Operational Considerations
  4.1.  RDAP Servers
  4.2.  RDAP Clients
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Author's Address

1. Introduction 💖

Okay so the Registration Data Access Protocol (RDAP) [STD95] gives you access to info about Internet resources: domain names, autonomous system numbers, and IP addresses. RFC 9083 [STD95] lets RDAP server operators share info about the content of the "NS", "DS", "A", and "AAAA" RRset(s) (see Section 5 of [RFC9499]) that get published in the DNS for a registry object (a domain or host object). The catch is that it has no way to include the Time-to-Live (TTL) values (see Section 5 of [RFC9499]) of those RRsets in responses. 🥺

Including these values in RDAP responses, along with nameservers, glue IP addresses, and Delegation Signer (DS) records, lets you do out-of-band debugging of the DNS configuration for troublesome domain names. That's the whole point, bestie. 🎀

This doc describes how TTL info can be included in domain and nameserver objects in RDAP responses. As per Section 5.2 of [RFC2181], TTL values apply to RRsets rather than to individual records. 💅

2. Conventions Used in This Document ✨

Here's the key word rule: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way BCP 14 [RFC2119] [RFC8174] describes. That only happens when they show up in all capitals, just like here. 🦋

This doc uses terms defined in Section 1.1 of RFC 9083 [STD95]. 🌸

3. RDAP Response Specification 🎀

Okay this is the meaty part. Servers that support this extension MAY include a "ttl0_data" member in any domain (Section 5.3 of RFC 9083 [STD95]) and nameserver (Section 5.2 of RFC 9083 [STD95]) objects included in RDAP responses. As per Section 2.1 of RFC 9083 [STD95], clients that don't implement this specification SHOULD ignore the "ttl0_data" member. 🙈

The "ttl0_data" member is an object with these members:

• A "values" member, which is an object that maps DNS record type mnemonics to TTL values; and
• An OPTIONAL "remarks" member, which is an array of remarks (see Section 4.3 of RFC 9083 [STD95]).

As specified in Section 8 of [RFC2181], a TTL value is "an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1". TTL values MUST be represented as JSON numbers with no fractional component and no exponent notation. 🔥

The TTL values included in "ttl0_data" members MUST reflect the TTL values as provisioned in the registry database. They must not reflect the remaining TTL of DNS records as observed from live DNS queries. 👑

Here's an example domain object with a valid "ttl0_data" member. Check RFC 9083 [STD95] for a description of the other objects listed in the example. 🧚

{
  "objectClassName": "domain",
  "rdapConformance": ["rdap_level_0", "ttl0"],
  "ldhName": "domain.example",
  "ttl0_data": {
    "values": {
      "NS": 3600,
      "DS": 300
    },
    "remarks": [
      {
        "description": [
          "For more information about the .example",
          " registry policy relating to DS record TTL changes,",
          "see https://domain.example"
        ],
        "links": [
          {
            "rel": "related",
            "title": ".Example Registry DNS TTL Policy",
            "href": "https://domain.example"
          }
        ]
      }
    ]
  }
}

And here's an example nameserver object with a valid "ttl0_data" member. 💖

{
  "objectClassName": "nameserver",
  "rdapConformance": ["rdap_level_0", "ttl0"],
  "ldhName": "ns1.domain.example",
  "ttl0_data": {
    "values": {
      "A": 86400,
      "AAAA": 86400
    },
    "remarks": [
      {
        "description": [
          "The .example registry does not permit TTL ",
          "values for nameservers to be changed."
        ]
      }
    ]
  }
}

3.1. DNS Record Types and TTL Values 🌷

The DNS record type mnemonics that appear as member names in "values" objects MUST be in all capitals and MUST be registered with IANA in [IANA-RRTYPES]. TTL values MUST be unsigned integers in the range 0-2147483647 as per Section 8 of [RFC2181]. 🍓

3.2. RDAP Conformance 💜

Servers returning responses that contain TTL values MUST include the string "ttl0" in the "rdapConformance" array. ✨

4. Operational Considerations 🍓

4.1. RDAP Servers 🧚

This spec is complementary to the Extensible Provisioning Protocol (EPP) [RFC5730] and the EPP Mapping for DNS Time-to-Live (TTL) Values [RFC9803]. Registry operators don't need to implement that extension in their EPP servers in order to implement this RDAP extension. 🌈

4.2. RDAP Clients 🫶

Many RDAP clients use frameworks that automatically "hydrate" objects using JSON data received in RDAP responses. As a result, RDAP clients that use these frameworks should explicitly carve out the "values" member of "ttl0_data" members. 💅

Since the list of record types appearing in "ttl0_data" members may change with time, clients that implement this extension MUST accept responses containing values for all valid DNS record types. They SHOULD also periodically update their list of valid DNS record types to align with [IANA-RRTYPES], so they don't discard a recently added record type. 🔥

Author's Address ✨

okay bestie, last stop! 🧚 the author is Gavin Brown over at ICANN, and yes, this is where you find out how to reach him 💌

Gavin Brown
ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States of America
Email: gavin.brown@icann.org

that's the whole thing, no cap 💅 if you ever need to get in touch about this doc, the address is right there. 🦋

end of the RFC, periodt! 💜