Internet DRAFT - draft-wang-dns-newzone-notify

draft-wang-dns-newzone-notify



DNS Operations Working Group                                 Cindy WANG                        
Internet Draft                                                 Jian JIN
Intended status: Standard Track                                Feng HAN
                                                           Xiaodong LEE
                                                                  CNNIC
Expires: September 19, 2010                                Mar 20, 2010



  A mechanism for synchronization across name servers on zone creation
                  draft-wang-dns-newzone-notify-00.txt


Status of this Memo

      This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.



      Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.



      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."



      The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.



      The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



      This Internet-Draft will expire on September 19, 2010.





WANG et al             Expires September 19, 2010                [Page 1]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 17, 2010.

Copyright Notice

      Copyright (c) 2010 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 BSD License.



      This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.

      Without obtaining an adequate license from the person(s)
   controlling the copyright in such materials, this document may not
   be modified outside the IETF Standards Process, and derivative works
   of it may not be created outside the IETF Standards Process, except
   to format it for publication as an RFC or to translate it into
   languages other than English.





WANG, et al.           Expires September 19, 2010                [Page 2]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


Abstract

   This memo describes the NEWZONE_NOTIFY opcode for DNS, by which a
   primary master server advises a set of slave servers that there are
   zones that has been created and that queries should be initiated to
   discover the new zone data.

   This draft also specifies a mechanism for the slave servers to
   achieve authenticated synchronization of zone data as well as zone
   synchronization information with the primary when zones are created
   on the primary.




Table of Contents


   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. Definitions and Invariants.....................................4
   4. NEWZONE_NOTIFY message.........................................5
   5. Automating the synchronization on zone creation across multiple
   name servers......................................................6
   6. Security Considerations........................................9
   7. References.....................................................9
      _Toc251598545

1. Introduction

   For large and busy domain name registrars, the zone creation
   operations resulted from frequent domain name registrations are
   almost daily routines. However, for these operations there are no
   technical specifications for automatic zone synchronization across
   multiple name servers. Moreover, the manual operations turn into
   heavy burden for administrators when there is large number of
   authoritative name servers for the zones.

   The major obstacle to the synchronization in the above situation is
   that, specified by the original design of DNS, when authority zones
   are created, they must be declared to have one or more authoritative
   name servers, usually consisting of one primary name server and
   several secondary name servers. The configuration of the
   synchronization relationships among the name servers depends upon
   out of band information and manual processes, which are normally
   specified with the zone creation.


WANG, et al.           Expires September 19, 2010                [Page 3]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


   This draft specifies a mechanism for the slave servers to achieve
   authenticated synchronization of both zone data and dependency
   configuration with the master servers when several (up to 16) zones
   are created.


2. Conventions used in this document

   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.



3. Definitions and Invariants

   The following definitions are used in this document, and intended to
   be consistent with [RFC1996] and [RFC2136]:

   o Slave: an authoritative server which uses zone transfer to
      retrieve the zone. All slave servers are named in the NS RRs for
      the zone.

   o Master: an authoritative server configured to be the source of
      zone transfer for one or more slave servers.

   o Primary Master: the master server at the root of the zone
      synchronization dependency graph. The primary master is named in
      the zone's SOA MNAME field and optionally by an NS RR. There is
      by definition only one primary master server per zone and the
      source of zone creation for one or more slave servers.

   o Notify Set: set of servers to be notified of changes to some new
      zone.  Default is all servers named in the NS RRset of the zone,
      except for any server also named in the SOA MNAME field. Some
      implementations will permit the name server administrator to
      override this set or add elements to it (such as, for example,
      the "also-notify" implemented in BIND [DNS_BIND]).  TSIG [RFC2845]
      Secret keys are supposed to be distributed across the Notify Set
      in some way.








WANG, et al.           Expires September 19, 2010                [Page 4]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


   o Dependency graph: organization of the zone's name servers, such
      that there is a primary master, and all other servers must
      request zone replication either from the primary master or from
      some slave which is also a master. NO loops are permitted in the
      dependency graph. The dependency graph is created with the zone
      on the primary master. For example, the set of servers for a zone
      is {p, s1, s2, s3, s4, s5, s6, s7}, where p is the address of the
      primary and {s1... s7} addresses of the slaves. The dependency
      graph could be defined as {{p->s1}, {p->s2}, {p->s3}, {s1->s2},
      {s2->s3}, {s2->s4}, {s2->s5}, {s3->s6}, {s3->s7}}, where "->"
      denotes "is the master of". An example of the "master of"
      relationship would look like, {1.2.3.4->5.6.7.8}.

4. NEWZONE_NOTIFY message

4.1. When a primary master has new zones, the master may send the
   created zones' name, class, type, and the name of the master from
   which to request the zone data, to each known slave server using a
   protocol based on the NEWZONE_NOTIFY opcode.

4.2. NEWZONE_NOTIFY employs the DNS Message Format [RFC 1034], although
   it uses only a subset of the fields. Fields not otherwise described
   herein are to be filled with binary zero (0).

4.3. NEWZONE_NOTIFY is similar to QUERY in that it has a request
   message with the header QR flag clear and a response message with QR
   set. The response message contains only an indication that the slave
   has received the NEWZONE_NOTIFY request and that the master can
   either remove the slave from any retry queue with respect to this
   NEWZONE_NOTIFY event or start another retry timer.

4.4. TSIG MUST be enabled between parties exchanging the NEWZONE_NOTIFY
   messages.

4.5. The NEWZONE_NOTIFY request has the following characteristics:

    Header:
          query ID:     (new)
          opcode:        NEWZONE_NOTIFY  (5)
          resp:          NOERROR
          flags:         AA
          qdcount:      n (number of zone names in the Question
    Section, n<16)


WANG, et al.           Expires September 19, 2010                [Page 5]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


          ancount:      1
         arcount:      1
    Question Section:
         zone_1:     <name_1, class_1, *>
         zone_2:     <name_2, class_2, *>
          ...  :          ...         zone_n:     <name_n, class_n, *>
    Answer Section:
          Name of a master m which satisfies m->s, where s is the
          notified slave.
    Additional Section:
          TSIG RR on (request + TSIG Variables).

   The defined NEWZONE_NOTIFY event in this situation is that n (n<16)
   zones have been created (QTYPE=*) on the primary master server.

4.6. Automating the synchronization on zone creation across multiple
   name servers

4.7. Zones created on the primary master server

   1.   The primary master should launch a NEWZONE_NOTIFY request
      appended with the TSIG data, to all the servers in the dependency
      graph except for itself. It performs the message digest operation
      and appends a TSIG record to the additional data section and
      transmits the request.

      For each encapsulated NEWZONE_NOTIFY request, a REFRESH timer is
      started on issuing the message. Whenever the timer expires, the
      message is issued again.

   2.   The notifying order should be decided by the distances (number
      of other masters between the primary and the slave to be notified).
      A slave CANNOT be notified until at least one of its masters
      responds back to the primary master with success.

   3.   For any slave with more than one master, the primary master
      MUST send multiple notification requests, one for each master.




WANG, et al.           Expires September 19, 2010                [Page 6]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


4.8. Slave Receives a NEWZONE_NOTIFY Request from the Primary Master

   Upon receipt of a NEWZONE_NOTIFY message on the slave side, the
   notification MUST be verified using the TSIG [RFC2845] mechanism.
   The slave then extracts the TSIG RR, adjusts the ARCOUNT, and
   calculates the keyed digest in the same way as the sending party. If
   the notification is justified by comparing the computed digest with
   the one stored in the TSIG RR, the slave should behave as though the
   zone given in the QNAME had been created on the primary master. It
   should respond to the NEWZONE_NOTIFY request with the following
   actions,

   1.   Firstly, for each of the n zones,

   o The slave requests the SOA record of the named zone locally to
      determine whether the zone exists or not.

   o If the zone exists already, then the zone data has been obtained
      from another master of the slave; otherwise, a zone transfer
      (AXFR) [AXFR_clarify] should be initiated to the master specified
      in the answer section of the NEWZONE_NOTIFY message.

   2.   In both cases of Step 1, the master appearing in the answer
      section is configured locally to be one of the masters of the
      slave.

   3.   Finally, whether the AXFR succeeds or not, the slave will send
      a NEWZONE_NOTIFY response back with the corresponding TSIG data to
      the primary, with the following characteristics:

       Header:
             query ID:   (same)
             opcode:                              NEWZONE_NOTIFY  (5)
             RCODE:     NOERROR (all the AXFRs succeed) or Server
       failure (some AXFRs fail)
             flags:     QR AA
             qdcount:    k (number of zone names in the Question
       Section whose AXFRs fail, kn)
             arcount:    1
       Question Section:
             zone_1:     <zname_1, zclass_1, *>


WANG, et al.           Expires September 19, 2010                [Page 7]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


             zone_2:     <zname_2, zclass_2, *>
              ...  :       ...      zone_k:     <zname_k, zclass_k, *>
       Answer Section:
             MUST be EMPTY
       Additional Section:
             TSIG RR on (response + request MAC + TSIG Variables) using
            the same algorithm and key.

     The query ID of the response must be the same as the one received
     in the request.
4.9. Primary Master Receives a NEWZONE_NOTIFY Response from a Slave

   1.   Similarly, the response needs to be verified by extracting the
      TSIG RR and the NEWZONE_NOTIFY response from the message and
      following the normal verification routine.

   2.   If RCODE = "Server fail", the primary master copies both the
      Question section and the qdcount field and keeps the
      NEWZONE_NOTIFY query in the retry queue and starts the RETRY timer.
      Whenever the timer expires, the NEWZONE_NOTIFY request is sent
      again.

   3.   Otherwise, if RCODE = "NOERROR", the primary initiates the
      notification process to all the slaves of that slave about all the
      n new zones. Next it deletes the successful query and completes
      the notification process of the zone creation change to the
      responding slave.

4.10. Re-notification mechanism: the primary master keeps two timers,
   REFRESH and RETRY for each pending NEWZONE_NOTIFY request, whose
   values are specified in the SOA record of the zone. Normally, RETRY
   timer is smaller than REFRESH as described in [RFC 2136]. Whichever
   timer elapses, the primary master re-launches the notification to
   the slave. The parameters involved are:

   REFRESH: number of seconds between NEWZONE_NOTIFY requests from the
   primary master server to the same slave server. On issuing a
   NEWZONE_NOTIFY request, the primary server starts the REFRESH timer.
   The request will be sent again if no response comes within the
   interval of REFRESH.


WANG, et al.           Expires September 19, 2010                [Page 8]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


   RETRY: number of seconds the primary master server will wait before
   retrying when the last NEWZONE_NOTIFY attempt has failed. On
   receiving a response whose RCODE = "Server fail", the primary server
   will send the NEWZONE_NOTIFY request again after an interval of
   RETRY.

   Re-notification will be kept until all the outstanding requests
   close with success.

4.11. NEWZONE_NOTIFY interleaved with the UPDATE [RFC 2136] requests.
   If the new zones on the primary server are updated during the
   process of NEWZONE_NOTIFY, both the primary and the slave will treat
   them as separate events and follow the normal routines respectively.

5. Security Considerations

   This document is believed to introduce no additional security
   problems to the current DNS protocol.



6. IANA Considerations

   TBD.

7. References

   [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
             STD 13, RFC 1034, November 1987.

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specifications", STD 13, RFC 1035, November 1987.

   [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
             Changes (DNS NOTIFY)", RFC 1996, August 1996.

   [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
             "Dynamic Updates in the Domain Name System (DNS UPDATE)",
             RFC 2136, April 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and Wellington,
             B., "Secret Key Transaction Authentication for DNS (TSIG)
             ", RFC 2845, May 2000.
   [RFC2930] D. Eastlake, 3rd. Secret Key Establishment for DNS (TKEY
             RR), RFC 2930, 2000.



WANG, et al.           Expires September 19, 2010                [Page 9]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


   [AXFR_clarify] DNS Zone Transfer Protocol (AXFR). draft-ietf-dnsext-
             axfr-clarify-12.

   [DNS_BIND] DNS and BIND, 5th Edition.

   [PDNS] PowerDNS manual. Chapter 13. Master/Slave operation &
             replication.









































WANG, et al.           Expires September 19, 2010               [Page 10]

Internet-Draft draft-wang-dns-newzone-notify-00.txt       March 2010


Authors' Addresses

   Cindy WANG
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: wangxin@cnnic.cn

   Jian Jin
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: jinjian@cnnic.cn

   Feng Han
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: hanfeng@cnnic.cn

   Xiaodong LEE
   CNNIC
   4, South 4th Street, Zhongguancun
   Beijing 100190
   P.R. China
   Email: lee@cnnic.cn



















WANG, et al.           Expires September 19, 2010               [Page 11]