wdiff draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt

regext J. Latour
Internet-Draft CIRA
Intended status: Standards Track O. Gudmundsson
Expires: January 8, July 14, 2017 Cloudflare, Inc.
P. Wouters
Red Hat
M. Pounsett
Rightside Group, Ltd.
July 7, 2016
January 10, 2017

Third Party DNS operator to Registrars/Registries Protocol
draft-ietf-regext-dnsoperator-to-rrr-protocol-01.txt
draft-ietf-regext-dnsoperator-to-rrr-protocol-02.txt

Abstract

There are several problems that arise in the standard
Registrant/Registrar/Registry model when the operator of a zone is
neither the Registrant nor the Registrar for the delegation.
Historically the issues have been minor, and limited to difficulty
guiding the Registrant through the initial changes to the NS records
for the delegation. As this is usually a one time activity when the
operator first takes charge of the zone it has not been treated as a
serious issue.

When the domain on the other hand uses DNSSEC it necessary to make regular
(sometimes annual) changes to the delegation, updating DS record(s)
in order to track KSK rollover, by updating the delegation's DS record(s). rollover. Under the current model this is
prone to delays and errors. Even when errors, as the Registrant has outsourced the operation of DNS to a third party the
registrant still has to be must participate in the loop
updates to update the DS record.

There is a need for records.

This document describes a simple protocol that allows a third party
DNS operator to update DS and NS records for a delegation, in a
trusted manner for a
delegation manner, without involving the registrant Registrant for each operation.
This same protocol can be used by Registrants.

The protocol described in this draft is REST based, and when used
through an authenticated channel can be used to establish the DNSSEC
Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC
trust is established this channel can be used to trigger maintenance
of delegation records such as DS, NS, and glue records. The protocol
is kept as simple as possible.

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 http://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 January 8, July 14, 2017.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notional Conventions . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. RFC2119 Keywords . . . . . . . . . . . . . . . . . . . . 4
3. What is the goal? Process Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why DNSSEC? . . . . . . . Identifying the Registrar . . . . . . . . . . . . . . . . 4
3.2. How does Establishing a child signal its parent it wants DNSSEC Chain of Trust
Anchor? . . . . . . . . . . . . . . . . . 5
3.3. Maintaining the Chain of Trust . . . . . . . . 5
3.3. What checks are needed by parent? . . . . . 5
3.4. Other Delegation Maintenance . . . . . . . 5
4. Third Party DNS operator to Registrars/Registries RESTful API 6
4.1. Authentication . . . . . . . 5
3.5. Acceptance Processing . . . . . . . . . . . . . . 6
4.2. Authorization . . . . 5
4. API Definition . . . . . . . . . . . . . . . . . . 6
4.3. Base URL Locator . . . . . 6
4.1. Authentication . . . . . . . . . . . . . . . 6
4.4. CDS resource . . . . . . 7
4.2. RESTful Resources . . . . . . . . . . . . . . . . 6
4.4.1. Initial Trust Establishment (Enable DNSSEC
validation) . . . . 7
4.2.1. CDS resource . . . . . . . . . . . . . . . . . 6
4.4.2. Removing a DS (turn off DNSSEC) . . . 7
4.2.2. Token resource . . . . . . . . 7
4.4.3. DS Maintenance (Key roll over) . . . . . . . . . . . 8
4.5. Tokens resource 9
4.3. Customized Error Messages . . . . . . . . . . . . . . . . 10
5. Security considerations . . . . . 8
4.5.1. Setup Initial Trust Establishment with Challenge . . 8
4.6. Customized Error Messages . . . . . . . . . . . . 10
6. IANA Actions . . . . 9
4.7. How to react to 403 on POST cds . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . 10
7. Internationalization Considerations . . . . . . . . . . . 9
6. IANA Actions . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . 9
7. Internationalization Considerations . . . 11
8.1. Normative References . . . . . . . . . . 10
8. References . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 10
8.1. Normative References . 11
Appendix A. Document History . . . . . . . . . . . . . . . . . 10
8.2. Informative References . 12
A.1. regext Version 02 . . . . . . . . . . . . . . . . 10
Appendix A. Document History . . . . 12
A.2. regext Version 02 not pushed . . . . . . . . . . . . . . 11
A.1. Regex versio 12
A.3. regext Version 01 . . . . . . . . . . . . . . . . . . . . . 11
A.2. Regex version 12
A.4. regext Version 00 . . . . . . . . . . . . . . . . . . . . 11
A.3. 13
A.5. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 11
A.4. 13
A.6. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 11
A.5. 13
A.7. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 11
A.6. 13
A.8. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 11 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 13

1. Introduction

Why is this needed? DNS registration systems today are designed
around making registrations easy and fast.

After the a domain has been
registered there are really registered, one of three options on who maintains parties will
maintain the DNS zone that is loaded on the "primary" DNS servers for the domain this
can be servers: the
Registrant, the Registrar, or a third party DNS Operator.

Unfortunately operator. DNS
registration systems were originally designed around making
registrations easy and fast, however after registration the ease to make
complexity of making changes to the delegation differs for each one of
these
options. The Registrant needs to use the interface that the
registrar provides to update NS and DS records. parties. The Registrar on the
other hand can make changes directly into in the registration system.
Registry systems through some API (typically EPP [RFC5730]). The
Registrant is typically limited to using a web interface supplied by
the Registrar. A third party DNS Operator on the hand needs must to go through the
Registrant to update any delegation information.

Current

In this last case, the operator must contact and engage the
Registrant in updating NS and DS records for the delegation. New
information must be communicated to the Registrant, who must submit
that information to the Registrar. Typically this involves cutting
and pasting between email and a web interface, which is error prone.
Furthermore, involving Registrants in this way does not scale for
even moderately sized DNS operators. Tracking thousands (or
millions) of changes sent to customers, and following up if those
changes are not submitted to the Registrar, or are submitted with
errors, is itself expensive and error prone.

The current system does not work well, as there are many types of
failures that have been reported and they have been at all levels in the registration
model. The failures result in either the inability to use DNSSEC or
in validation failures that case cause the domain to become invalid and all unavailable to
users that
are behind validating resolvers will not be able to to access the
domain. resolvers.

The goal of this document is to create an automated interface a protocol for establishing a
secure chain of trust that
will involves parties not in the traditional
Registrant/Registrar/Registry (RRR) model, and to reduce the friction
in maintaining DNSSEC delegations. secured delegations in these cases. It
describes a REST-based [RFC6690] protocol which can be used to
establish DNSSEC initial trust (to enable or bootstrap DNSSEC), and
to trigger maintenance of delegation records such as DS, NS, and glue
records.

2. Notional Conventions

2.1. Definitions

For the purposes of this draft, a third-party DNS Operator is any DNS
Operator responsible for a zone zone, where the operator is neither the
Registrant nor the Registrar of record for the delegation.

Uses of "child" and "parent" refer to the relationship between DNS
zone operators. In this document, unless otherwise noted, the child
is the third-party DNS operator and the parent is the Registry.

Uses of the word 'Registrar' words "Registrar" or "Registration Entity" in this
document may also be applied to
resellers: an entity Resellers or to Registries that sells delegations through a registrar
engage in registration activities directly with
whom Registrants. Unless
otherwise noted, they are used to refer to the entity which has a reseller agreement.
direct business relationship with the Registrant.

2.2. RFC2119 Keywords

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 [RFC2119].

3. What is Process Overview

3.1. Identifying the goal?

The primary goal is to have a protocol to establish a secure chain Registrar

As of
trust that involves parties that are not in the traditional RRR EPP
model, or when EPP is not used.

In the general case publication of this document, there should be has never been a way to find
standardized or widely deployed method for easily and scalably
identifying the right
Registrar/Registry entity to talk to, but it does not exist. Whois[] Registar for a particular registration.

At this time, WHOIS [RFC3912] is the natural only widely deployed protocol to
carry such information but that protocol information, but is unreliable WHOIS responses are unstructured text,
and each implementor can lay out its text responses differently. In
addition, Registries may include referrals in this unstructured text
to the WHOIS interfaces of their Registrars, and hard those Registrar
WHOIS interface in turn have their own layouts. This presents a text
parsing problem which is infeasible to parse. Its proposed solve.

RDAP, the successor to WHOIS, described in [RFC7480], solves the
problems of unstructured responses, and a consistently implemented
referral system, however at this time RDAP
[RFC7480] has yet to be deployed on at
most TLD's.

The preferred communication Registries.

With no current mechanism is to use is to use a REST
[RFC6690] call in place to start processing of scalably discover the requested delegation
information.

3.1. Why DNSSEC?

DNSSEC [RFC4035] provides data authentication Registar
for DNS answers, having
DNSSEC enabled makes it possible to trust the answers. The biggest
obstacle in DNSSEC adoption is a particular registration, the initial configuration problem of automatic discovery of
the
DNSSEC domain trust anchor at base URL of the parent, API is considered out of scope of this document.

The authors recommend standardization of an RDAP extension to obtain
this information from the DS record. Registry.

3.2. How does Establishing a child signal its parent it wants DNSSEC Chain of Trust Anchor?

The child needs first to sign

After signing the domain, then zone, the child can "upload"
the DS record to its parent. The "normal" way operator needs to upload is to go
through registration interface, but that fails frequently. The DNS
Operator may not have access to the interface thus the registrant
needs DS
record(s) to relay the information. For large operations this does not
scale, as evident in lack of Trust Anchors for signed deployments
that are operated by third parties. parent. The child can signal its desire to have
DNSSEC validation enabled by publishing one of the special DNS
records CDS and/or CDNSKEY[RFC7344] CDNSKEY as defined in [RFC7344] and its proposed extension
[I-D.ietf-dnsop-maintain-ds].

[RFC Editor: The above I-D reference should be replaced with the
correct RFC number upon publication.]

In the case of an insecure delegation, the Registrar will normally
not be scanning the child zone for CDS/CDNSKEY records. The child
operator can use this protocol to notify the Registrar to begin such
a scan.

Once the "parent" "sees" Registrar sees these records it SHOULD start acceptance
processing. This document covers how to make the CDS records visible
to

3.3. Maintaining the right parental agent.

This document and [I-D.ogud-dnsop-maintain-ds] argue that Chain of Trust

One the
publication secure chain of CDS/CDNSKEY record trust is sufficient for established, the parent to
start Registrar SHOULD
regularly check the acceptance processing. child zone for CDS/CDNSKEY record changes. The main point is
Registrar SHOULD also accept signals via this protocol to provide
authentication thus if immediately
check the child is in "good" state then the DS
upload should be simple zone for CDS/CDNSKEY records.

Server implementations of this protocol MAY include rate limiting to accept
protect their systems and publish. If there is any
problem the systems of child operators from abuse.

Each parent does not add the DS.

In the event this protocols operator and its associated authentication
mechanism does not address the Registrant's security requirements to
create a secure Trust Anchor delegation then the Registrant always
has recourse by submitting its DS record via its Registrar interface
with EPP submission to the Registry.

3.3. What checks are needed by parent? is responsible for developing,
implementing, and communicating their DNSSEC maintenance policies.

3.4. Other Delegation Maintenance

[ Not yet defined ]

3.5. Acceptance Processing

The parent Registrar, upon receiving a signal or detecting through polling
that it check the child for desire
for DS record publication. desires to have its delegation updated, SHOULD run a
series of tests to ensure that updating the parent zone will not
create or exacerbate any problems with the child zone. The basic
tests include,

1. Is SHOULD include:

o checking that the child zone is is properly signed
2. The zone has a as per the
Registrar and parent DNSSEC policy

o if updating the DS record, checking that the child CDS signed by RRset
references a KSK referenced in the current DS,
referring to a at least one key which is present in the current child DNSKEY RRset
3. All and
signs the name-servers for CDS RRset

o ensuring all name servers in the apex NS RRset of the child zone
agree on the apex NS RRset and CDS RRset contents

Parents can perform

The Registrar SHOULD NOT make any changes to the DS RRset if the
child name servers do not agree on the CDS/CDNSKEY content.

[NOTE: Do we need a new section in the DPS for the CDS management
policy [RFC6841]?]

Registrars MAY require compliance with additional tests, defined delays, particularly
in the case of establishing a new chain of trust, such as:

o checking that all child name servers to respond with a consistent
CDS/CDNSKEY RRset for a number of queries over
TCP, ensure an extended period
of time to minimise the possibility of an attacker spoofing
responses

o requiring the child name servers to respond with identical CDS/
CDNSKEY RRsets over TCP

o ensuring zone delegation best practice as per practices (for examples, see
[I-D.wallstrom-dnsop-dns-delegation-requirements] and even ask

o requiring the
DNS Operator child operator to prove they can add data to the zone, or provide
zone (for example, by publishing a
code that is tied to the affected zone. The particular token)

4. API Definition

This protocol is partially- partially synchronous, i.e. meaning the server can elect
to hold connection connections open until
the operation has concluded operations have completed, or it can
return a status code indicating that it has received a request, and
close the
request. connection. It is up to the child to monitor the parent
for completion of the operation operation, and issue possible follow-up calls.

4. Third Party DNS operator calls
to Registrars/Registries RESTful API

The specification of this API is minimalist, but a realistic one.

Registry Lock mechanisms that prevents domain hijacking block domains
prevent certain attributes in the registry to be changed. This API Registrar.

Clients may be denied access to change the DS records for domains
that are Registry Locked (HTTP Status code 401). Registry Lock is a
mechanism provided by certain Registries or Registrars that prevents
domain hijacking by ensuring no attributes of the domain are
changeable, and no transfer or deletion transactions can be processed
against the domain name without manual intervention.

4.1. Authentication

The API does not impose any unique server authentication
requirements. The server authentication provided by TLS fully
addresses the needs. In general, the needs of this protocol. The API SHOULD MUST be provided over
TLS-protected transport (e.g., HTTPS) or VPN.

4.2. Authorization

Authorization

Client authentication is outside the considered out of scope of this document.
The CDS publication of CDS/CDNSKEY records
present in the child zone file are indications of intention to sign/unsign/
update the DS records of is an
indication that the domain child operator intends to perform DS-record-
updating activities (add/delete) in the parent zone. This means Since this
protocol is simply a signal to the Registrar that they should examine
the proceeding child zone for such intentions, additional authentication of the action is not determined by who issued
client making the
request. Therefore, authorization request is out of scope. Registries and
registrars who plan to provide this service can, however, considered unnecessary.

Registrars MAY implement their own policy to protect access to the
API, such as with IP white listing, API key, etc.

4.3. Base URL Locator

The base URL for registries or registrars who want whitelisting, client TLS certificates, etc..
Registrars SHOULD take steps to provide this ensure that a lack of additional
authentication does not open up a denial of service mechanism against
the systems of the Registrar, the Registry, or the child operator.

4.2. RESTful Resources

In the following text, "{domain}" is the child zone to DNS Operators can be made auto-discoverable as an RDAP
extension.

4.4. operated
on.

4.2.1. CDS resource

Path: /domains/{domain}/cds {domain}: is the domain name to be
operated on

4.4.1.

4.2.1.1. Establishing Initial Trust Establishment (Enable DNSSEC validation)

4.4.1.1. (Enabling DNSSEC)

4.2.1.1.1. Request

Syntax: POST /domains/{domain}/cds

Request that an initial set of DS record records based on the CDS record in
the child zone file will be inserted into the registry Registry and the parent zone file upon
the successful completion of such the request. If there are multiple CDS
records in the CDS RRset, multiple DS records will be added.

Either the CDS/CDNSKEY or the DNSKEY can be used to create the DS
record. Note: entity expecting CDNSKEY is still expected accept the
/cds command.

4.4.1.2.

4.2.1.1.2. Response

o HTTP Status code 201 indicates a success.

o HTTP Status code 400 indicates a failure due to validation.

o HTTP Status code 401 indicates an unauthorized resource access.

o HTTP Status code 403 indicates a failure due to an invalid
challenge token.

o HTTP Status code 404 indicates the domain does not exist.

o HTTP Status code 409 indicates the delegation already has a DS
RRset.

o HTTP Status code 429 indicates the client has been rate-limited.

o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.

4.4.2. Removing

This request is for setting up initial trust in the delegation. The
Registrar SHOULD return a status code 409 if it already has a DS (turn off DNSSEC)

4.4.2.1.
RRset for the child zone.

Upon receipt of a 403 response the child operator SHOULD issue a POST
for the "token" resource to fetch a challenge token to insert into
the zone.

4.2.1.2. Removing DS Records

4.2.1.2.1. Request

Syntax: DELETE /domains/{domain}/cds

Request that the Registrar check for a null CDS or CDNSKEY record mean in
the child zone, indicating a request that the entire DS RRset must be
removed.

4.4.2.2. This will make the delegation insecure.

4.2.1.2.2. Response

o HTTP Status code 200 indicates a success.

o HTTP Status code 400 indicates a failure due to validation.

o HTTP Status code 401 indicates an unauthorized resource access.

o HTTP Status code 404 indicates the domain does not exist.

o HTTP Status code 412 indicates the parent does not have a DS RRset

o HTTP Status code 429 indicates the client has been rate-limited.

o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.

4.4.3.

4.2.1.3. Modifying DS Maintenance (Key roll over)

4.4.3.1. Records

4.2.1.3.1. Request

Syntax: PUT /domains/{domain}/cds

Maintenance activities are performed

Request that the Registrar modify the DS RRset based on the CDS CDS/
CDNSKEY available in the child zone. As a result of this request the
Registrar SHOULD add or delete DS records may be added, removed. But as indicated by the CDS/
CDNSKEY RRset, but MUST NOT delete the entire DS
RRset must not be deleted.

4.4.3.2. RRset.

4.2.1.3.2. Response

o HTTP Status code 200 indicates a success.

o HTTP Status code 400 indicates a failure due to validation.

o HTTP Status code 401 indicates an unauthorized resource access.

o HTTP Status code 404 indicates the domain does not exist.

o HTTP Status code 412 indicates the parent does not have a DS RRset

o HTTP Status code 429 indicates the client has been rate-limited.

o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.

4.5. Tokens

4.2.2. Token resource

Path: /domains/{domain}/tokens {domain}: is the domain name to be
operated on

4.5.1. Setup /domains/{domain}/token

4.2.2.1. Establish Initial Trust Establishment with Challenge

4.5.1.1.

4.2.2.1.1. Request

Syntax: POST /domains/{domain}/tokens

A /domains/{domain}/token

The DNSSEC policy of the Registrar may require proof that the DNS
Operator is in control of the domain. The token API call returns a
random token to be included as a _delegate TXT record for the _delegate.@
domain name (where @ is the apex of the child zone) prior
establishing the DNSSEC initial trust.

4.5.1.2. This is an additional trust
control mechanism to establish the initial chain of trust.

Once the child operator has received a token, it SHOULD be inserted
in the zone and the operator SHOULD proceed with a POST of the cds
resource.

Note that the _delegate TXT record is publicly available and not a
secret token.

4.2.2.1.2. Response

o HTTP Status code 200 indicates a success. Token A token is included in
the body of the response, as a valid TXT record

o HTTP Status code 404 indicates the domain does not exist.

o HTTP Status code 500 indicates a failure due to unforeseeable
reasons.

4.6.

4.3. Customized Error Messages

Service providers can

Registrars MAY provide a customized error message in the response
body in addition to the HTTP status code defined in the previous
section. This can response MAY include an Identifying identifying number/string that
can be used to track the requests.

#Using request.

5. Security considerations

When zones are properly provisioned, and delegations follow standards
and best practices (e.g.
[I-D.wallstrom-dnsop-dns-delegation-requirements]), the definitions This section at Registrar or
Registry can trust the moment contains comments DNS information it receives from early implementers

4.7. How to react to 403 on POST cds

The basic reaction to a 403 on POST /domains/{domain}/cds is to issue
POST /domains/{domain}/tokens command to fetch the challenge multiple
child name servers, over time, and/or over TCP to
insert into the zone.

5. Security considerations

Supplying establish the DS record as proof
initial chain of control is not realistic since
the domain is already publicly signed and trust.

In addition, the CDS/DS is readily
available.

Open question:?? JL?: It is not recommended Registrar or Registry can require the protocol be used with
high profile domains such as TLDs and governments that are DNS
operators. This protocol is meant Operator
to allow third party DNS prove they control the zone by requiring the child operator to submit the initial DS in
navigate additional hurdles, such as adding a trusted manner without involving challenge token to the
registrant.
zone.

This protocol should increase the adoption of DNSSEC and get DNSSEC, enabling more
zones to become validated thus overall the security gain outweighs
the possible drawbacks.

TBD This will hopefully get more zones to become validated thus
overall

Registrants and DNS Operators always have the security gain out weights option to establish the possible drawbacks.

risk of takeover ? risk
chain of validation errors < declines transfer
issues trust in band via the standard Registrant/Registrar/Registry
model.

6. IANA Actions

URI ??? TBD

This document has no actions for IANA

7. Internationalization Considerations

This protocol is designed for machine to machine communications communications.
Clients and servers should use punycode [RFC3492] when operating on
internationalized domain names.

8. References

8.1. Normative References

[I-D.ietf-dnsop-maintain-ds]
Gudmundsson, O. and P. Wouters, "Managing DS records from
parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03 draft-ietf-dnsop-maintain-ds-04
(work in progress), June 2016.

[I-D.wallstrom-dnsop-dns-delegation-requirements]
Wallstrom, P. and J. Schlyter, "DNS Delegation
Requirements", draft-wallstrom-dnsop-dns-delegation-
requirements-00 (work in progress), February October 2016.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications

[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for the DNS Security
Extensions", Internationalized Domain Names in Applications
(IDNA)", RFC 4035, 3492, DOI 10.17487/RFC4035, 10.17487/RFC3492, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. 2003,
<http://www.rfc-editor.org/info/rfc3492>.

[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.

[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, DOI
10.17487/RFC7344, September 2014,
<http://www.rfc-editor.org/info/rfc7344>.

8.2. Informative References

[I-D.ogud-dnsop-maintain-ds]
Gu[eth]mundsson, O. and

[I-D.wallstrom-dnsop-dns-delegation-requirements]
Wallstrom, P. Wouters, "Managing DS records
from parent via CDS/CDNSKEY", draft-ogud-dnsop-maintain-
ds-00 and J. Schlyter, "DNS Delegation
Requirements", draft-wallstrom-dnsop-dns-delegation-
requirements-03 (work in progress), October 2015. 2016.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format",

[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 6690, 3912, DOI 10.17487/RFC6690,
10.17487/RFC3912, September 2004,
<http://www.rfc-editor.org/info/rfc3912>.

[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. 2009,
<http://www.rfc-editor.org/info/rfc5730>.

[RFC6841] Ljunggren, F., Eklund Lowinder, AM., and T. Okubo, "A
Framework for DNSSEC Policies and DNSSEC Practice
Statements", RFC 6841, DOI 10.17487/RFC6841, January 2013,
<http://www.rfc-editor.org/info/rfc6841>.

[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", RFC 7480, DOI
10.17487/RFC7480, March 2015,
<http://www.rfc-editor.org/info/rfc7480>.

Appendix A. Document History

A.1. Regex versio regext Version 02

o simplify abstract

o move all justification text to Intro

o added HTTP response codes for rate limiting (429), missing DS
RRsets (412)

o expanded on Internationalization Considerations

o corrected informative/normative document references

o clarify parent/Registrar references in the draft

o general spelling/grammar/style cleanup

A.2. regext Version 02 not pushed

o Clarified based on comments and questions from early implementors
(JL)

o Text edits and clarifications.

A.3. regext Version 01

o Rewrote Abstract and Into (MP)

o Introduced code 401 when changes are not allowed

o Text edits and clarifications.

A.2. Regex version

A.4. regext Version 00

o Working group document same as 03, just track changed to standard

A.3.

A.5. Version 03

o Clarified based on comments and questions from early implementors

A.4.

A.6. Version 02

o Reflected comments on mailing lists

A.5.

A.7. Version 01

o This version adds a full REST definition this is based on
suggestions from Jakob Schlyter.

A.6.

A.8. Version 00

o First rough version

Authors' Addresses

Jacques Latour
CIRA

Email: jacques.latour@cira.ca

Olafur Gudmundsson
Cloudflare, Inc.

Email: olafur+ietf@cloudflare.com

Paul Wouters
Red Hat

Email: paul@nohats.ca

Matthew Pounsett
Rightside Group, Ltd.

Email: matt@conundrum.com