RDAP Extension for DNS Time-To-Live (TTL Values)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 June 2026.¶

Copyright Notice

Copyright (c) 2025 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 (https://trustee.ietf.org/license-info) 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

1. Introduction

While [RFC9083] allows RDAP server operators to provide information about the content of the NS, DS, A and AAAA record(s) 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 of those records to be included in responses.¶

This document describes how TTL information can be included in domain and nameserver objects in RDAP responses.¶

This document is complementary to the Extensible Provisioning Protocol [RFC5730] (EPP) Mapping for DNS Time-to-Live (TTL) Values [RFC9803], but registry operators do not need to implement that extension in their EPP server in order to implement this RDAP extension.¶

3. RDAP Response Specification

Servers which support this extension MAY include a ttl0_data property in any domain and nameserver objects included in RDAP responses.¶

The ttl0_data property is an object which has the following properties:¶

• A values property, which is an object which maps DNS record type mnemonics to TTL values;¶
• An OPTIONAL remarks property, which is an array of remarks (see Section 4.3 of [RFC9083]).¶

Example domain object:¶

{
  "objectClassName": "domain",
  "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"
          }
        ]
      }
    ]
  }
}

Example nameserver object:¶

{
  "objectClassName": "nameserver",
  "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."
        ]
      }
    ]
  }
}

4. IANA Considerations

IANA is requested to register the following value in the RDAP Extensions Registry:¶

Extension identifier: ttl0¶

Registry operator: Any¶

Published specification: this document¶

Contact: IETF <iesg@ietf.org>¶

Intended usage: this extension describes how DNS TTL values can be included in RDAP responses.¶

5. Security Considerations

Security services for the extension specified in this document are described in [RFC7481].¶

This document only concerns itself with the representation of configure TTL values for domain and host objects. The security implications of those values are described further in Section 6 of [RFC9803].¶

6. Change Log

This section is to be removed before publishing as an RFC.¶

7. Acknowledgements

The author wishes to thank Andy Newton, Pawel Kowalik, and Maarten Wullink for their constructive feedback and advice during the development of this document.¶

Author's Address