]> ICANN

terry.manderson@icann.org

General Internet Engineering Task Force This document defines an Extensible Markup Language (XML) Schema for Reverse DNS Management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" based system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an X.509 certificate mediated HTTPS transaction.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

This document defines an Extensible Markup Language (XML) Schema for Reverse DNS Management in a tightly controlled Representational State Transfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" based system since 2011 and is being used by the registries responsible for reverse DNS (rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through an X.509 certificate mediated HTTPS transaction. As DNSSEC adoption progresses the necessity to interact with a delegation in the IN-ADDR.ARPA and IP6.APRA zones becomes more frequent given that updates to DS records in the parent zone for child delegations follow the key rollover and expiry of the child zone. The modification of such critical areas at a relative high frequency requires a system that allows the administrative holders of such delegations to make such changes in a secure and trustworthy manner where the chain of trust for submitting the necessary information remains unbroken between the IN-ADDR.ARPA and IP6.APRA zone maintainers and the zone customers. At the request of the Regional Internet Registries to automate reverse DNS updates with ICANN, a REST based HTTPS service was deployed that: Provides for a secure authenticated mechanism to update zone data (NS and DS records) Provides a well-formed data structure for both the IN-ADDR.ARPA and IP6.ARPA zones Allows for "out of band" acknowledgement and notification of updates

The implemented system allows the entity responsible for its rDNS delegations to effect changes in the reverse DNS zones IN-ADDR.ARPA and IP6.ARPA by submitting an XML document to an atomic RESTful service via a HTTPS connection. In this service the HTTPS layer provides the end-to-end security of the transaction and it further provides authentication by use of mandatory X.509 client certificates with a known server certificate issued by a Certificate Authority administered by the service operator. Certificates for use in this system, issued by the system operator, are specific to the entity responsible for the delegations in the zone. Updates are made to the system by using the HTTP GET, PUT, and DELETE operations over HTTP 1.1 via HTTPS only. These operations are sent to a resource Uniform Resource Identifier (URI) in the form of:

/ ]]>

A synthetic example of an XML document submitted to the deployed system might take the following form (including all optional attributes) as per the schema in .

BLACKHOLE-1.IANA.ORG. BLACKHOLE-2.IANA.ORG. 33682 5 1 ea8afb5fce7caf381ab101039 33682 5 2 7d44874f1d93aaceb793a88001739a ]]>

When PUT and DELETE operations are used, the well formed XML is required to be sent with the appropriate content-length headers. The GET operation requires only the URI. One requirement of the system was to allow the separation of update and approval with an out of band notification mechanism. When such options are configured for a customer of the service, submitted updates may be queued for later approval. When a customer has queued updates pending approval, the customer may submit a GET request to retrieve either an individual entry, or a full listing of all queued entries. To fetch a listing of the customer's queue the customer would GET a URI in the form of:

To fetch an individual queue entry the customer would GET the canonical URL (as per the schema) for this queue record:

]]>

Were <identifier> is a system generated and system specific value that identifies this particular queue entry. All XML returned from from queue based operations ('queue' and 'queuelist') would return an XML document following the specification in . A synthetic example from a GET of 'queuelist' would be:

BLACKHOLE-1.IANA.ORG. BLACKHOLE-2.IANA.ORG. 33682 5 1 ea8afb5fce7caf381ab101039 33682 5 2 7d44874f1d93aaceb793a88001739a ]]>

This memo includes no request to IANA. This section may be removed by the RFC Editor prior to publication.

This document provides an XML schema for facilitating the management of reverse DNS delegations in the IN-ADDR.ARPA and IP6.APRA zones. The schema itself contains no authentication data and all other information contained is considered public data as it is either published in DNS, or propagated to other public information sources like WHOIS. The system which implements this XML schema requires HTTPS to be used and also uses known server and client X.509 certificates for authentication to protect against message modification, message insertion/deletion, man-in-the-middle, and replay attacks. Authorisation for which delegations the X.509 certificate authentication sessions can affect are out of scope of this document, along with any denial of service type attack vectors.

An XML schema was initially provided by APNIC, however necessity required a branch and as such a new namespace and schema has been created. Recognition goes to APNIC for prior efforts in this area. The author acknowledges feedback from a collective made up of various RIR technical folk, however heartfelt thanks goes to Anand Buddhdev of the RIPE-NCC and Robert Loomans of APNIC for being both alpha and beta testers and providing valuable feedback.

&RFC2119; &RFC2818; &RFC5280; &RFC2616; &RFC1034; &RFC3152; &RFC4033; &RFC4034; The Organization for the Advancement of Structured Information Standards [OASIS]

The following Schema, used for PUT, GET, and DELETE operations, is an XML document using the RelaxNG Compact specification.

| | | # as per RFC4034 # element rdata { text } } # A single name server nserver = element nserver { # An nserver entry MUST contain a DNS FQDN # for a NS RR (RFC 1035) element fqdn { text } } ]]>

The XML schema definition below, in RelaxNG Compact form is used for queue interaction operations.