ICANN

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

OPS regext Registrar Registry Internet resource domain name DNS configuration resource record validity This document specifies an extension to the Registration Data Access Protocol (RDAP), which allows the Time-to-Live (TTL) values for relevant DNS record types to be included in RDAP responses.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Conventions Used in This Document
• .  RDAP Response Specification
  • .  DNS Record Types and TTL Values
  • .  RDAP Conformance
• .  Operational Considerations
  • .  RDAP Servers
  • .  RDAP Clients
• .  IANA Considerations
• .  Security Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Author's Address

Introduction The Registration Data Access Protocol (RDAP) provides access to information about Internet resources (domain names, autonomous system numbers, and IP addresses). While RFC 9083 allows RDAP server operators to provide information about the content of the "NS", "DS", "A", and "AAAA" RRset(s) (see ), which are published in the DNS for a given registry object (domain or host object), it does not provide a mechanism to allow the Time-to-Live (TTL) values (see ) of those RRsets to be included in responses. Inclusion of these values in RDAP responses (in addition to nameservers, glue IP addresses, and Delegation Signer (DS) records) allows out-of-band debugging of the DNS configuration of troublesome domain names. This document describes how TTL information can be included in domain and nameserver objects in RDAP responses. As per , TTL values are applicable to RRsets rather than individual records.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses terms defined in Section of RFC 9083 .

RDAP Response Specification Servers that support this extension MAY include a "ttl0_data" member in any domain (Section of RFC 9083 ) and nameserver (Section of RFC 9083 ) objects included in RDAP responses. As per Section of RFC 9083 , clients that do not implement this specification SHOULD ignore the "ttl0_data" member. The "ttl0_data" member is an object that has the following 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 of RFC 9083 ).

As specified in , 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, not the remaining TTL of DNS records as observed from live DNS queries. An example domain object with a valid "ttl0_data" member is provided below. Readers should refer to RFC 9083 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" } ] } ] } } An example nameserver object with a valid "ttl0_data" member is provided below. { "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." ] } ] } }

DNS Record Types and TTL Values The DNS record type mnemonics that appear as the member names in "values" objects MUST be in all capitals and MUST be registered with IANA in . TTL values MUST be unsigned integers in the range 0-2147483647 as per .

RDAP Conformance Servers returning responses containing TTL values MUST include the string "ttl0" in the "rdapConformance" array.

Operational Considerations

RDAP Servers This specification is complementary to the Extensible Provisioning Protocol (EPP) and the EPP Mapping for DNS Time-to-Live (TTL) Values , but registry operators do not need to implement that extension in their EPP servers in order to implement this RDAP extension.

RDAP Clients Many RDAP clients make use of frameworks, which 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 and SHOULD periodically update the list of valid DNS record types to align with , to avoid discarding a recently added record type.

IANA Considerations IANA has registered the following value in the "RDAP Extensions" registry :

Extension Identifier:

ttl0

Registry Operator:

Any

Specification:

RFC 10037

Contact:

IETF

Intended Usage:

This extension describes how DNS TTL values can be included in RDAP responses.

Security Considerations Security services for the extension specified in this document are described in RFC 7481 . This document only concerns itself with the representation of configured TTL values for domain and host objects. The security implications of how those TTL values are determined, assigned, or modified within a registry system are out of scope. Readers are referred to for further discussion.

References Normative References IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application. The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from Domain Name and Regional Internet Registries. This document describes information security services, including access control, authentication, authorization, availability, data confidentiality, and data integrity for RDAP. This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP). This document obsoletes RFC 7482. This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483. This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or Autonomous System numbers. This document obsoletes RFC 7484. Informative References This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] This document describes an extension to the Extensible Provisioning Protocol (EPP) that allows EPP clients to manage the Time-to-Live (TTL) value for domain name delegation records.

Acknowledgements The author wishes to thank the following for their constructive feedback and advice during the development of this document: , , , , , , , , , , , and .

Author's Address ICANN

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