DNS data representation for use in RESTful Provisioning Protocol (RPP)

Introduction The Extensible Provisioning Protocol (EPP) manages DNS delegation data using distinct object types and extensions. Host Objects are used for name servers (NS records) and their associated addresses (glue A/AAAA records), while DNSSEC data is handled via a separate security extension . Name server information can be also directly attached to a domain name as a set of Host Attributes . More recently, control over Time-to-Live (TTL) values was added through another extension . While functional, this segmented approach creates complexity. The DNS landscape itself is evolving, with new transport protocols like DNS-over-HTTPS and DNS-over-QUIC driving the need for more sophisticated delegation information, such as the proposed DELEG record type . Some registry operators have developed their own proprietary solutions. These include grouping name servers into "sets" for easier management or allowing domains to be provisioned with arbitrary DNS resource records (RR) without formal delegation, which is expanding on Host Attribute model with other resource record types. The development of the RESTful Provisioning Protocol (RPP) provides an opportunity to address this fragmentation. This document proposes a unified data representation for all DNS-related information, specified in a format that directly mirrors DNS resource records. This approach is not intended to influence existing registry data models, but rather to offer a flexible and consistent structure for the data in the protocol. By unifying the representation of delegation data (NS, A/AAAA glue), DNSSEC information, and other record types, this model can be applied across various contexts. It is designed to be equally applicable whether a registry uses separate host objects, host attributes within a domain, or more abstract concepts like name server sets, thereby simplifying implementation and ensuring adaptability for future developments in the DNS.

Domain Names in DNS DNS domain names are hierarchically ordered label separated by a dot ".". Each label represent the delegation of a subordinate namespace or a host name. DNS resource records are expressed as a dataset containing: "NAME" "CLASS" "TYPE" "TTL" "RDLENGTH" "RDATA" A set of resource records describes the behavior of a namespace. Each resource record shares the same top level format. NAME The owner name of the DNS entry which MAY be the domain itself or a subordinate hostname. CLASS The RR CLASS TYPE The RR TYPE of data present in the RDATA field. TTL Time interval a RR may be cached by name servers RDLENGTH The length of the RDATA field. RDLENGTH will be safely ignored in RPP RDATA The actual payload data. Structures defer for each type.

JSON representation

Rules

DNS data extending an domain object Delegation data, as well as DNSSEC data, is intended to find it's way into the parent side DNS servers. Because of the strong connection to the provisioned domain object and DNS servers both aspects should be visible in the RPP data model. Therefore the domain object is extended by an array of DNS entries. The properties of an object in this array MUST be a representation of the top level format as described in section 3.2.1 of . All keys MUST be lowercase. Whitespaces MUST be translated to underscores ("_").

DNS record structure representation

name The owner name of the DNS entry which MAY be the domain itself or a subordinate hostname. A server MUST NOT accept a NAME which is not a subordinate label to the provisioned domain name. A server MUST accept values as "@", "relative names" and fully qualified domain names (FQDN). "@" MUST be interpreted as the provisioned domain name. "relative names" MUST be appended by the server with the provisioned domain name. "FQDN" identified by a trailing dot (".") MUST NOT be interpreted by the server. A server MUST check if the provided name is a subordinate to the provisioned domain, or the domain itself. Example:

The above example implies three resulting records: An "A" RR for "example.com" ("@") set to 192.0.2.1. An "A" RR for "www.example.com" ("www" relative) set to 192.0.2.2. An "A" RR for "web.example.com" (FQDN) set to 192.0.2.3.

class A client SHOULD omit the class. The server MUST assume "IN" as class of a transferred dataset and MAY decline other values. If present the value MUST be chosen from section 3.2.4. (CLASS values) of .

type The TYPE of data present in the RDATA. This also implies the expected fields in RDATA. If present the value MUST chosen from section 3.2.2. (TYPE values) of or other RFC describing the RR type. Values MUST be converted to lower case.

ttl TTL is considered a operational control (see section 3.1.3 and section 4.3.1 of this document). A server MUST set a default value as TTL and MAY ignore other values send by a client.

rdlength RDLENGTH specifies the length of the RDATA field and will be ignored in RPP. A client MUST NOT include this field. A server MUST ignore this field if present.

rdata The RDATA structure depends on the TYPE and MUST be expressed as a JSON object. Property names MUST follow the definition of the RDATA described by the corresponding RFC. Property names MUST be translated to lowercase. Whitespaces MUST be translated to underscores ("_"). Example: Section 3.3.11 (NS RDATA format) of describes the RDATA of a NS RR having a field named "NSDNAME". Section 3.3.9 (MX RDATA format) of describes the RDATA of a MX RR having the field named "PREFERENCE", "EXCHANGE". The resulting structure is therefore:

Operational controls In addition to the regular data a server MAY allow clients to control specific operational behavior. A client MAY add an JSON object with a number of "dns_controls" to the domain object.

", "type": "", "rdata": { "rdata_key": "" } } ], "dns_controls": { "": "" } } ]]>

Future DNS record types With respect to an evolving DNS landscape new record types - including delegation - may emerge. Usually these record type will be defined and standardized for the DNS in first. Adopting future record types MUST be done using the rules described in section 3.1.2.6 of this document.

Use cases

Domain delegation (Host Attribute) To enable domain delegation a server MUST support the "NS", "A" and "AAAA" record types (, ). In this delegation model the delegation information and corresponding DNS configuration is attached directly to a domain object. This is corresponding to Host Attribute delegation model of . A minimal delegation can be expressed by adding an array of name servers to the DNS data of a domain:

If GLUE records are needed the client may add records of type "A" or "AAAA" :

Host Object specifies how domain delegation can be expressed as a relation to a separate provisioning object (Host Object), which carries the DNS configuration (name and glue records), with details specified in . To enable specification of Host Objexts, similar to direct domain delegation, a server MUST support the "NS", "A" and "AAAA" record types (, ). DNS configuration of Host Object is specified by NS, A and AAAA configuration within "dns" data structure:

DNSSEC To enable DNSSEC provisioning a server SHOULD support either "DS" or "DNSKEY" or both record types. The records MUST be added to the "dns" array of the domain. If provided with only "DNSKEY" a server MUST calculate the DS record. If both record types are provided a server MAY use the DNSKEY to validate the DS record.

Operational controls

TTL The TTL controls the caching behavior of DNS resource records (see Section 5 of ). Typically a default TTL is defined by the registry operator. In some use cases it is desirable for a client to change the TTL value. A client MAY assign "ttl" to the dns_controls of an RR set which is intended to be present in the parent sides DNS. A server MAY ignore these values e.g. for policy reasons. Example:

Maximum signature lifetime Maximum signature lifetime (maximum_signature_lifetime) describes the maximum number of seconds after signature generation a parents signature on signed DNS information should expire. The maximum_signature_lifetime value applies to the RRSIG resource record over the signed DNS RR. See Section 3 of for information on the RRSIG resource record. A client MAY assign "maximum_signature_lifetime" to the dns_controls of an RR set which is intended to be signed on the parent side. A server MAY ignore these values, e.g. for policy reasons. Example:

Authoritative DNS data A server MAY support additional RR types, e.g. to support delegation-less provisioning. By doing this the registry operators name servers becomes authoritative for the registered domain. A server MUST consider resource records designed for delegation - including DNSSEC - and resource records representing authoritative data - except for GLUE RR - mutual exclusive.

Discoverability The server MUST provide the following information per profile in the discovery document in section 10 of : A list of supported resource record types A list of applicable dns_controls Minimum, maximum and default values for dns_controls TODO: Needs rewrite after definition of the discovery document

EPP compatibility considerations TODO

Conventions and Definitions 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.

Security Considerations

Authoritative data Allowing to store authoritative resource records (see section 4.4 of this document) in the registry provides faster resolution. However, if not done properly situations may occur where the data served authoritative should have been delegated. RPP servers MUST take precautions to not store authoritative and non-authoritative data at the same time. The types and number of authoritative records can result in uncontrolled growth of the registries zone file and eventually exhaust the hardware resources of the registries name server. RPP servers SHOULD consider limiting the amount of authoritative records and carefully choose which record types are allowed.

Host references within the rdata field Some RR types (NS, MX and others) use references to host names which can be categorized into three categories: Domain internal references are references to a subordinate host name of the domain. E.g. "ns.example.com" is an domain internal reference when used as a name server for "example.com". Registry internal references are references to a host name within the same registry. E.g. "ns.example.com" is an domain internal reference when used as a name server for "example2.com". Registry external references are references to a host name outside of the registry. E.g. "ns.example.net" is an domain internal reference when used as a name server for "example.com". Deletion of a host name while still being referenced may lead to severe security risks for the referencing domain.

IANA Considerations This document has no IANA actions.

Appendix A. Examples from current implementations

EPP

Create domain using host attributes example EPP XML:

example.com 1 ns1.example.com 192.0.2.1 2001:db8::1 ns2.example.com 192.0.2.2 registrantID adminID techID 604800 12345 13 2 BE74359954660069D5C632B56F120EE9F3A86764247 3600 clTRID-1234 ]]> RPP JSON representation:

Create domain using host object example EPP XML:

example.com 1 ns1.example.net ns2.example.net registrantID adminID techID 604800 12345 13 2 BE74359954660069D5C632B56F120EE9F3A86764247C 3600 clTRID-1234 ]]> RPP JSON representation:

Create host object example EPP XML:

ns1.example.com 192.0.2.2 192.0.2.29 1080:0:0:0:8:800:200C:417A ABC-12345 ]]> RPP JSON representation:

Free Registry for ENUM and Domains (FRED) FRED is an open source registry software developed by CZ.NIC

Create domain example EPP XML:

example.cz registrantID adminID nssetID keysetID clTRID-1234 ]]>

Create nsset example EPP XML:

nssetID ns1.example.cz 192.0.2.1 192.0.2.2 nameserver-example.cz techID 1 clTRID-1234 ]]>

Create keyset example EPP XML:

keysetID 257 3 5 AwEAAddt2AkL4RJ9Ao6LCWheg8 257 3 5 AwEAAddt2AkL4RJ9Ao6LCWheg9 techID clTRID-1234 ]]> RPP JSON representation: TODO

Realtime Registry Interface (RRI) RRI is a proprietary protocol developed by DENIC

Create domain with name servers example RRI XML:

example.de registrantID example.de ns1.example.com example.de ns1.example.de 192.0.2.1 example.de. 257 3 5 AwEAAddt2AkL4RJ9Ao6LCWheg8 clTRID-1234 ]]> RPP JSON representation:

Create domain without delegation example RRI XML:

example.de registrantID example.de 192.0.2.1 clTRID-1234 ]]> RPP JSON representation:

RDAP

Domain object Registration Data Access Protocol (RDAP) is described in . An extention proposing Time-to-Live (TTL) values is described in and is close to adoption in the regext working group. RDAP JSON: