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

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. 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. This document 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.

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.

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 ).

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. Example domain object: Example nameserver object:

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 . 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 set of possible DNS record mnemonics is not static, as new DNS record types are added to regularly. In practice, the number of DNS record types that are likely to observed "in the wild" is small, and will only change as the result of a significant evolution to the DNS protocol itself, similar to that brought about by , or which might result from . For domain objects, the list of expected DNS record types is NS, DS, A and AAAA. For nameserver objects, the list of expected DNS record types is just A and AAAA. Since the list of expected record types may change with time, clients which implement this extension MUST accept responses containing other DNS record types, but MAY ignore unexpected record types.

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

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 configure TTL values for domain and host objects. The security implications of those values are described further in .

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 05 to 06

Add missing change log entries to assist in IESG review.
Added .

Changes from 04 to 05

Clarify that TTL values are represented using JSON numbers.

Changes from 03 to 04 Updates based on feedback during WGLC:

Remove the xref in the Abstract to avoid issues when rendered as plaintext;
Refer to RRsets instead of resource records since requires the TTL of all the records in an RRset to be the same;
Reference which defines what a TTL is.
Clarify that clients need to handle (even if to ignore) unexpected record types.

Changes from 02 to 03

Switch to array model to object model, based on WG feedback.
Added .

Changes from 01 to 02

Include reference to in (thanks Jasdip Singh).
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

Updated the extension identifier and extension property name to align with the current best practices in .
Added .
Changed MUST to MAY in the first paragraph of .
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

Name change only.

Changes from 02 to 03

Update reference to .

Changes from 01 to 02

Update reference to the EPP extension.

Changes from 00 to 01

Extension property name renamed to ttl.
The extension data structure is now an array allowing common TTL values, remarks and events to be mapped to multiple DNS record types.
The extension data structure may now include remarks and events.
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.