Internet DRAFT - draft-daley-updatezones
draft-daley-updatezones
Internet Engineering Task Force J. Daley
Internet-Draft .nz Registry Services
Intended status: Standards Track November 12, 2013
Expires: May 16, 2014
Extending DNS UPDATE for 'whole of zone' operations
draft-daley-updatezones-00
Abstract
This memo describes an extension to the DNS protocol that support the
remote provisioning of zones on authoritative servers. This addition
is complementary to the existing mechanisms for provisioning zone
data using the DNS protocol.
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 May 16, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Daley Expires May 16, 2014 [Page 1]
Internet-Draft updatezones November 2013
Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Extending the DNS UPDATE message . . . . . . . . . . . . . . 3
3.1. 'in zone' vs 'whole of zone' operations . . . . . . . . . 3
3.2. Adding zones . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Adding a master zone . . . . . . . . . . . . . . . . 4
3.2.2. Adding slave zones . . . . . . . . . . . . . . . . . 5
3.3. Removing zones . . . . . . . . . . . . . . . . . . . . . 5
3.4. Response . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Processing 'whole of zone' operations . . . . . . . . . . . . 6
4.1. Dynamic serving . . . . . . . . . . . . . . . . . . . . . 6
4.2. Atomicity . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Provisioning order . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Definitions
This memo uses the following DNS server roles in a manner consistent
with RFC 2136 [RFC2136]:
Slave An authoritative server that uses AXFR or IXFR to retrieve
the zone and is named in the zone's NS RRset.
Master An authoritative server configured to be the source of AXFR
or IXFR data for one or more slave servers.
This memo uses the term "catalog of zones" in the spirit of RFC 1035
[RFC1035] to describe the set of zones that a server is authoritative
for.
2. Introduction
It is common practice for Internet service providers and domain name
registrars to operate DNS servers that are simultaneously
authoritative for many zones. In some case a single DNS server may
be authoritative for hundreds of thousands of zones. Despite the
large number of zones served, the server is unlikely to also be
authoritative for a common parent of these zones and so must operate
each zone independently.
Daley Expires May 16, 2014 [Page 2]
Internet-Draft updatezones November 2013
The DNS protocol supports the provisioning of resource records in
zones already being served by an authoritative DNS server using the
DNS UPDATE message described in RFC 2136 [RFC2136]. However no
similar operation exists to update the list of zones that a server
serves.
This memo describes an extension to the DNS UPDATE message that
allows it to be used to instruct an authoritative DNS server to start
serving or stop serving zones. This extension supports the remote
provisioning of zones in the same manner that DNS UPDATE supports the
remote provisioning of Resource Records.
2.1. Requirements Language
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 [RFC2119].
3. Extending the DNS UPDATE message
RFC 2136 [RFC2136] defines the DNS UPDATE message which enables the
remote provisioning of data within existing zones. The operations
enabled by RFC 2136 [RFC2136] are now referred to as 'in zone'
operations.
This memo extends the definition of the DNS UPDATE message to enable
the remote provisioning of zones. The operations enabled by this
memo are referred to as 'whole of zone' operations.
Two 'whole of zone' operations are defined in this memo:
1. Adding zones. Instructing the receiving server to add one or
more zones to the catalog of authoritative zones that it serves
and start serving these zone, either as a master or a slave.
2. Removing zones. Instructing the receiving server to stop serving
one or more authoritative zones and remove them from the catalog
of zones that it serves.
The operations described in this memo operate on the catalog of zones
irrespective of whether or not the server is currently responding to
queries for a specific zone as a server may at any point time be
actively serving only some of the zones in its catalog for
operational reasons.
3.1. 'in zone' vs 'whole of zone' operations
Daley Expires May 16, 2014 [Page 3]
Internet-Draft updatezones November 2013
'in zone' operations are distinguished from 'whole of zone'
operations by the ZTYPE of the zones in the Zone section of the DNS
UPDATE message:
o For 'in zone' operations the ZTYPE of all of the zones in the Zone
section MUST be SOA.
o For 'whole of zone' operations the ZTYPE of all of the zones in
the Zone section MUST be NS.
It is not possible to have both 'in zone' and 'whole of zone'
operations in the same DNS UPDATE message and so the zones in the
Zone section MUST NOT have different ZTYPES.
'whole of zone' operations interpret the data in the Prerequisite,
Update and Additional sections differently from 'in zone' operations.
3.2. Adding zones
The operation to add new authoritative zones can come in one of two
forms:
1. Add a master zone. Instructing the receiving server to add a new
zone and serve that zone as a master.
2. Adding slave zones. Instructing the receiving server to add one
or more new zones and serve those as a slave.
3.2.1. Adding a master zone
To add a master zone the DNS UPDATE is constructed as follows:
One zone and only one zone MUST be listed in the Zone section. and
the ZTYPE of that zone MUST be set to NS.
The Prerequisitie section MUST be empty.
The Update section MUST contain the SOA record for the new zone. The
class of the SOA record MUST NOT be ANY.
The Update section MAY contain any other resource records that are to
be added to the zone.
The receiving server MUST add the SOA record and any records in the
Update section to the zone before serving the zone.
The Additional section MUST be empty.
Daley Expires May 16, 2014 [Page 4]
Internet-Draft updatezones November 2013
3.2.2. Adding slave zones
To add slave zones the DNS UPDATE is constructed as follows:
One or more zones MUST be listed in the Zone section. and the ZTYPE
of those zone MUST be set to NS.
The Prerequisitie section MUST be empty.
The Update section MUST be empty.
The Additional section MUST contain at least one A or AAAA resource
record. All A and AAAA records are used by the receiving server to
identify the servers it should contact to pull the zones from.
The Additional section MAY contain a TKEY record that the receiving
server should use to authenticate itself when it pulls the zones.
The resource records in the Additional section MUST NOT be added to
the zones.
3.3. Removing zones
To remove zones the DNS UPDATE is constructed as follows:
One or more zones MUST be listed in the Zone section. and the ZTYPE
of those zones MUST be set to NS.
The Prerequisitie section MUST be empty.
The Update section MUST contain a SOA record for the zone to be
deleted and the class of the SOA record MUST be ANY. This use of a
class of ANY to signal the removal of a zone matches the way that a
resource record that is to be deleted is identified in RFC 2136
[RFC2136]
The Additional section MUST be empty.
3.4. Response
The response sent to acknowledge receipt and processing of a 'whole
of zone' operation is the same as specified for an 'in zone'
operation in RFC 2136 [RFC2136] with the addition of the following
specific error conditions:
1. When adding zones, If any of the zones listed are already in the
catalog of authoritative zones served by the receiving server,
whether or not it is currently being served, then the server MUST
Daley Expires May 16, 2014 [Page 5]
Internet-Draft updatezones November 2013
ignore the entire request and return an error response with
RCode=YXDOMAIN.
2. When adding zones if both the Update and Additional sections are
empty then the receiving server MUST ignore the entire request
and return an error response with RCode=FORMERROR.
3. When adding zones if both the Update and Additional sections
contain data then the receiving server MUST ignore the entire
request and return an error response with RCode=FORMERROR.
4. When adding a master zone, if initial zone data is provided and
the domains names of those resource records are not within the
zone being added (i.e. they are 'out of bailiwick') then the
receiving server SHOULD ignore the entire operation and return an
error response with RCode=FORMERROR.
5. When removing zones, if any of the zones listed are not in the
catalog of zones served by the receiving server then it MUST
ignore the entire request and return an error response with
RCode=NXDOMAIN.
4. Processing 'whole of zone' operations
4.1. Dynamic serving
It is recognised that not all authoritative nameservers are capable
of dynamically loading new zones to serve or dynamically ceasing to
serve zones. It is left to the implementor to decide whether to load
/unload the zones dynamically; wait for a server restart or to
initiate a restart itself.
4.2. Atomicity
This memo does not change the requirements for serialisation of
UPDATE operations the depend on each other, as specified in section
3.7 of RFC 2136 [RFC2136], which apply equally to 'whole of zone'
operations as they do to 'in zone' operations.
4.3. Provisioning order
A server receiving a 'whole of zone' operation SHOULD NOT assume any
particular order to the provisioning of zones and reject the
operation as a result. Examples of erroneous rejections include:
1. When adding slave zones, rejecting the operation if the master
servers specified are unreachable or do not serve the required
zone.
Daley Expires May 16, 2014 [Page 6]
Internet-Draft updatezones November 2013
2. When adding or removing zones, rejecting the operation if it
would leave an incorrect or inconsistent set of nameservers for
that zone specified in that zone or in the parent delegation.
5. Acknowledgements
The author thanks Mark Andrews for his input.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
Clearly unrestricted access to 'whole of zone' operations is a
significant threat and misuse would be likely to cause considerable
issues. It is therefore RECOMMENDED that:
o DNS UPDATE messages that contain 'whole of zone' operations are
protected by TSIG and implementors allow adminstrators to require
this protection.
o Implementors do not enable processing of 'whole of zone'
operations by default.
The provision of a TKEY record is a significant vulnerability if the
DNS UPDATE message containing it is transmitted in clear over the
wire. It is therefore RECOMMENDED that such messages are encrypted.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
8.2. Informative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Author's Address
Daley Expires May 16, 2014 [Page 7]
Internet-Draft updatezones November 2013
Jay Daley
.nz Registry Services
PO Box 24361, Manners Street
Wellington 6142
New Zealand
Phone: +64 4 931 6970
Email: jay@nzrs.net.nz
Daley Expires May 16, 2014 [Page 8]
