One document matched: draft-daley-servezones-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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-servezones-00" ipr="trust200902">
   <front>
     
    <title abbrev="SERVEZONES">DNS SERVEZONES message</title>
     <author fullname="Jay Daley" initials="J." role="editor"
       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="August" 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 addition 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>
    </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 the SERVEZONES message that instructs an 
         authoritative DNS server to start serving or stop serving 
         zones. This message 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="The SERVEZONES message">
      <t>When a DNS server or provisioning system chooses to instruct
        an authoritative DNS server to start serving or stop serving 
        one or more zones then it does so by sending a SERVEZONES 
        message. SERVEZONES uses the DNS message format, although it 
        uses only a subset of the available fields.</t>
      <t>SERVEZONES is similar to NOTIFY in that it has a request 
        message with the header QR=0 and a response message with 
        QR=1.  The response message contains no useful information,
        but its reception is an indication that the server has 
        received the SERVEZONES message.</t>
      <t>SERVEZONES is similar to UPDATE in that the contents of the 
         QTYPE field are used to differentiate between a request to
         start serving a specified zone or to stop serving a specified 
         zone.</t>
      <t>The SERVEZONES message is signalled by Opcode=6.</t>
      <t>Except where specified, all DNS header fields are set as
         for a normal DNS query or response.</t>
      
      <section title="SERVEZONES request">
        <t>A SERVEZONES request contains one or more zones included as
           a QNAME in the QUERY section of the SERVEZONES message.</t>
        <t>A single SERVEZONES request can instruct the receiving 
           server to both start serving one or more zones and to stop 
           serving one or more zones.</t>
        <t>Each zone for which serving is to start is included as a
           QNAME in the QUERY section with the QTYPE set to SOA.</t>
        <t>Each zone for which serving is to stop is included as a 
            QNAME in the QUERY section with the QTYPE set to ANY.</t>
        <t>For all SERVEZONES requests: 
          <list style="symbols">
            <t>The QCLASS for each entry in the QUERY section is set as 
               required</t>
            <t>QDCOUNT is set to the number of zones in the QUERY section.</t>  
            <t>ANCOUNT is set to zero (0).</t>
          </list>
        </t>
                
        <section title="Specifying master servers">
          <t>If the server receiving the message is intended to act as a
             slave server then the AUTHORITY section MAY include a list
             of master servers. NSCOUNT is set to the number of master 
             servers listed in the AUTHORITY section.</t>
          <t>If a list of master servers is provided then it applies to
             all the zones listed in the SERVEZONES message for whom 
             serving is to start (QTYPE is set to SOA).</t>
          <t>The receiving server MUST fetch the zone data from one of 
             the listed master servers before serving the zone.</t>
        </section>
        
        <section title="Specifying initial zone data">
          <t>If the server receiving the message is intended to act as a
             master then the ADDITIONAL section MUST include the initial
             zone data.  ARCOUNT is set to the number of entries in the
             ADDITIONAL section.</t>
          <t>If initial zone data is included in the ADDITIONAL section
             then it applies to all the zones listed in the SERVEZONES
             message for whom serving is to start (QTYPE is set to SOA).  
             If multiple zones are listed then the initial zone data MUST 
             NOT contain any fully qualified domain names (FQDNs).</t>
          <t>The receiving server MUST add the initial zone data before
             serving the zone.</t>
        </section>
      </section>
            
      <section title="SERVEZONES response">
        <t>A SERVEZONES response is sent to acknowledge receipt of the
           SERVEZONES request to the same source that sent the 
           original request.</t>
        <t>QDCOUNT, ANCOUNT, NSCOUNT and  ARCOUNT are all set to zero
           (0).</t>
        <t>If the SERVEZONES request is processed correctly then the
           receiving server SHOULD respond with a SERVEZONES response
           with RCode=NOERROR.</t>
        <t>The following specific error conditions apply:
          <list style="numbers">
            <t>If any of the zones listed in the request to start serving 
               are already being served by the receiving server then it 
               MUST ignore the entire request and return an error response 
               with RCode=YXDOMAIN.</t>
            <t>If any zones are listed in the request to start serving and 
               neither the AUTHORITY or ADDITIONAL sections appear
               in the request then the receiving server MUST ignore
               the entire request and return an error response with
               RCode=FORMERROR.</t>
            <t>If any zones are listed in the request to start serving and 
               both the AUTHORITY and ADDITIONAL sections contain 
               data then the receiving server MUST ignore the entire 
               request and return an error response with 
               RCode=FORMERROR.</t>
            <t>If FQDNs are included in the initial zone data and the 
               SERVEZONES message lists multiple zones to start serving 
               then the receiving server SHOULD return an error response with
               RCode=FORMERROR.</t>
            <t>If any of the zones listed in the request to stop serving are 
               not being 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 the SERVEZONES messages">
      <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 anchor="Acknowledgements" title="Acknowledgements">
      <t>The author thanks Sebastian Castro for his input and review.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo requests that IANA assigns the following values in
         the DNS Opcode registry:</t>
      <texttable>
        <ttcol align="center">Opcode</ttcol>
        <ttcol align="center">Mnemonic</ttcol>
        <c>6</c>
        <c>SERVEZONES</c>
      </texttable>      
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Clearly the SERVEZONES message has the 
        potential to be misused and such misuse would be likely to 
        cause considerable issues.  It is therefore RECOMMENDED that:
        <list style="symbols">
          <t>SERVEZONES messages are always 
             protected by TSIG and implementors allow adminstrators to
             require this protection.</t>
          <t>Implementors do not enable processing of SERVEZONES
             messages by default.</t>
        </list>
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
    </references>

    <references title="Informative References">
      &RFC2136;
    </references>
  </back>
</rfc>