One document matched: draft-daley-updatezones-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1035 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2136 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2136.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-daley-updatezones-00" ipr="trust200902">
<front>
<title abbrev="updatezones">Extending DNS UPDATE for 'whole of zone' operations</title>
<author fullname="Jay Daley" initials="J."
surname="Daley">
<organization>.nz Registry Services</organization>
<address>
<postal>
<street>PO Box 24361, Manners Street</street>
<city>Wellington</city>
<region/>
<code>6142</code>
<country>New Zealand</country>
</postal>
<phone>+64 4 931 6970</phone>
<email>jay@nzrs.net.nz</email>
</address>
</author>
<date month="November" year="2013" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>dns</keyword>
<keyword>provisioning</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section title="Definitions">
<t>This memo uses the following DNS server roles in a manner
consistent with <xref target="RFC2136">RFC 2136</xref>:
<list hangIndent="8" style="hanging">
<t hangText="Slave">An authoritative server that uses AXFR
or IXFR to retrieve the zone and is named in the zone's
NS RRset.</t>
<t hangText="Master">An authoritative server configured to
be the source of AXFR or IXFR data for one or more slave
servers.</t>
</list></t>
<t>This memo uses the term "catalog of zones" in the spirit of
<xref target="RFC1035">RFC 1035</xref> to describe the
set of zones that a server is authoritative for.</t>
</section>
<section title="Introduction">
<t>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.</t>
<t>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
<xref target="RFC2136">RFC 2136</xref>. However
no similar operation exists to update the list of zones
that a server serves.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="message" title="Extending the DNS UPDATE message">
<t><xref target="RFC2136">RFC 2136</xref> defines the
DNS UPDATE message which enables the remote provisioning
of data within existing zones. The operations enabled by
<xref target="RFC2136">RFC 2136</xref> are now
referred to as 'in zone' operations.</t>
<t>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.</t>
<t>Two 'whole of zone' operations are defined in this memo:
<list style="numbers">
<t>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.</t>
<t>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.</t>
</list>
</t>
<t>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.</t>
<section anchor="operationtypes" title="'in zone' vs 'whole of zone' operations">
<t>'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:
<list style="symbols">
<t>For 'in zone' operations the ZTYPE of all of the zones
in the Zone section MUST be SOA.</t>
<t>For 'whole of zone' operations the ZTYPE of all of the
zones in the Zone section MUST be NS.</t>
</list>
</t>
<t>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.
</t>
<t>'whole of zone' operations interpret the data in the
Prerequisite, Update and Additional sections differently from
'in zone' operations.</t>
</section>
<section anchor="addoperation" title="Adding zones">
<t>The operation to add new authoritative zones can come in one of
two forms:
<list style="numbers">
<t>Add a master zone. Instructing the receiving server to
add a new zone and serve that zone as a master.</t>
<t>Adding slave zones. Instructing the receiving server to add
one or more new zones and serve those as a slave.</t>
</list>
</t>
<section anchor="addmaster" title="Adding a master zone">
<t>To add a master zone the DNS UPDATE is constructed as follows:</t>
<t>One zone and only one zone MUST be listed in the Zone section.
and the ZTYPE of that zone MUST be set to NS.</t>
<t>The Prerequisitie section MUST be empty.</t>
<t>The Update section MUST contain the SOA record for the new zone.
The class of the SOA record MUST NOT be ANY.</t>
<t>The Update section MAY contain any other resource records that
are to be added to the zone.</t>
<t>The receiving server MUST add the SOA record and any records
in the Update section to the zone before serving the zone.</t>
<t>The Additional section MUST be empty.</t>
</section>
<section anchor="addslave" title="Adding slave zones">
<t>To add slave zones the DNS UPDATE is constructed as follows:</t>
<t>One or more zones MUST be listed in the Zone section.
and the ZTYPE of those zone MUST be set to NS.</t>
<t>The Prerequisitie section MUST be empty.</t>
<t>The Update section MUST be empty.</t>
<t>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.</t>
<t>The Additional section MAY contain a TKEY record that
the receiving server should use to authenticate itself
when it pulls the zones.</t>
<t>The resource records in the Additional section MUST NOT be
added to the zones.</t>
</section>
</section>
<section anchor="removezone" title="Removing zones">
<t>To remove zones the DNS UPDATE is constructed as follows:</t>
<t>One or more zones MUST be listed in the Zone section.
and the ZTYPE of those zones MUST be set to NS.</t>
<t>The Prerequisitie section MUST be empty.</t>
<t>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 <xref target="RFC2136">RFC 2136</xref></t>
<t>The Additional section MUST be empty.</t>
<t></t>
</section>
<section title="Response">
<t>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 <xref target="RFC2136">RFC 2136</xref>
with the addition of the following specific error conditions:
<list style="numbers">
<t>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 ignore the entire request and return an error response with
RCode=YXDOMAIN.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section title="Processing 'whole of zone' operations">
<section title="Dynamic serving">
<t>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.</t>
</section>
<section title="Atomicity">
<t>This memo does not change the requirements for serialisation of
UPDATE operations the depend on each other, as specified in
section 3.7 of <xref target="RFC2136">RFC 2136</xref>, which
apply equally to 'whole of zone' operations as they do to
'in zone' operations.</t>
</section>
<section title="Provisioning order">
<t>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:
<list style="numbers">
<t>When adding slave zones, rejecting the operation if
the master servers specified are unreachable or do
not serve the required zone.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The author thanks Mark Andrews for his input.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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:
<list style="symbols">
<t>DNS UPDATE messages that contain 'whole of zone'
operations are protected by TSIG and implementors
allow adminstrators to require this protection.</t>
<t>Implementors do not enable processing of 'whole of zone'
operations by default.</t>
</list>
</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2136;
</references>
<references title="Informative References">
&RFC1035;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:59:31 |