]> RDAP Extension for DNS Time-To-Live (TTL Values) ICANN
12025 Waterfront Drive, Suite 300 Los Angeles 90094-2536 US CA gavin.brown@icann.org
Internet Registration Extensions (REGEXT) This document specifies an extension to the Registration Data Access Protocol which allows the Time-To-Live (TTL) values for relevant DNS record types to be included in RDAP responses. The source for this draft, and an issue tracker, may can be found at .
Introduction While 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) (see ) values of those RRsets to be included in responses. Inclusion of these values in RDAP responses, in addition to nameservers, glue IP addresses, and 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 makes use of the terms defined in .
RDAP Response Specification Servers that support this extension MAY include a "ttl0_data" property in any domain () and nameserver () objects included in RDAP responses. As per , clients which do not implement this specification SHOULD ignore the "ttl0_data" member. 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 ).
As specified in , a TTL value is a "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 are represented as JSON numbers. An example domain object with valid "ttl0_data" attribute is provided below. Readers should refer to for a description of the other objects listed in the example. An example nameserver object with valid "ttl0_data" attribute is provided below.
DNS record Types and TTL Values The DNS record type mnemonics that appear as the property 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) Mapping for DNS Time-to-Live (TTL) Values, but registry operators do not need to implement that extension in their EPP server 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 which use these frameworks may need to explicitly carve out the "values" property of "ttl0_data" elements. Since the list of record types appearing in "ttl0_data" elements may change with time, clients which 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 .
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.
Security Considerations Security services for the extension specified in this document are described in . This document only concerns itself with the representation of configured TTL values for domain and host objects. Such configuration is out of scope. Readers may refer to for the security implications of configuring those values.
Implementation status
ICANN RDAP Organization: ICANN Name: ICANN RDAP Description: ICANN RDAP contains an RDAP client, server, and common libraries. Level of maturity: Mature Coverage: All aspects of the protocol are implemented. Licensing: Apache License, Version 2.0 or MIT License. Contact: globalsupport@icann.org URL: https://github.com/icann/icann-rdap
Net::RDAP Name: Net::RDAP Description: An RDAP library for Perl. Level of maturity: Mature Coverage: All aspects of the protocol are implemented. Licensing: Perl (Artistic License or GPL). Contact: gavin.brown@fastmail.uk URL: https://metacpan.org/pod/Net::RDAP
rdapper Name: rdapper Description: A command-line RDAP client that uses Net::RDAP. Level of maturity: Mature Coverage: All aspects of the protocol are implemented. Licensing: Perl (Artistic License or GPL). Contact: gavin.brown@fastmail.uk URL: https://metacpan.org/pod/App::rdapper
Change Log
Changes from 07 to 08 Updates as per AD review:
  1. Added .
  2. Move the last paragraph of to .
  3. Remove most of , moved some of it to .
  4. Backfilled the change log immediately below.
Changes from 06 to 07
  1. Correct reference to .
Changes from 05 to 06
  1. Add missing change log entries to assist in IESG review.
  2. Added .
Changes from 04 to 05
  1. Clarify that TTL values are represented using JSON numbers.
Changes from 03 to 04 Updates based on feedback during WGLC:
  1. Remove the xref in the Abstract to avoid issues when rendered as plaintext;
  2. Refer to RRsets instead of resource records since requires the TTL of all the records in an RRset to be the same;
  3. Reference which defines what a TTL is.
  4. Clarify that clients need to handle (even if to ignore) unexpected record types.
Changes from 02 to 03
  1. Switch to array model to object model, based on WG feedback.
  2. Added .
Changes from 01 to 02
  1. Include reference to in (thanks Jasdip Singh).
  2. Removed the value member of the link object in the example domain object so that it conforms with web linking practice (also thanks Jasdip Singh).
Changes from 00 to 01
  1. Updated the extension identifier and extension property name to align with the current best practices in .
  2. Added .
  3. Changed MUST to MAY in the first paragraph of .
  4. Reduce ambiguity around the repetition of DNS record types in responses.
Changes from draft-brown-rdap-ttl-extension-03 to draft-ietf-regext-rdap-ttl-extension-00
  1. Name change only.
Changes from 02 to 03
  1. Update reference to .
Changes from 01 to 02
  1. Update reference to the EPP extension.
Changes from 00 to 01
  1. Extension property name renamed to ttl.
  2. The extension data structure is now an array allowing common TTL values, remarks and events to be mapped to multiple DNS record types.
  3. The extension data structure may now include remarks and events.
  4. Added normative text regarding the value of DNS record mnemonics and TTL values.
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.
Normative References &RFC2119; &RFC2181; &RFC7481; &RFC8174; &RFC9083; Resource Record (RR) TYPEs IANA RDAP Extensions IANA Informative References &RFC5730; &RFC9499; &RFC9803; &draft-ietf-regext-rdap-extensions;