[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                  N. Kong
Internet-Draft                                                   C. Wang
Intended status: Standards Track                                  X. Lee
Expires: January 13, 2011                                          CNNIC
                                                           July 12, 2010


  An Automated Synchronization Mechanism for Configuration Data of DNS
                   (Domain Name  System) Name Servers
                    draft-kong-dns-conf-auto-sync-01

Abstract

   This document proposes an in-band synchronization mechanism to
   automatically synchronize configuration data among multiple DNS
   (Domain Name System) name servers.  Using this mechanism, any part of
   configuration data of a name server can be constructed as a similar
   DNS zone file, and be automatically synchronized by DNS messaging and
   notifying mechanisms.

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 13, 2011.

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



Kong, et al.            Expires January 13, 2011                [Page 1]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


   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.

   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Configuration Record . . . . . . . . . . . . . . . . . . . . .  4
     5.1.  Format . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     5.2.  Standard CRs . . . . . . . . . . . . . . . . . . . . . . .  6
       5.2.1.  SERIAL CR  . . . . . . . . . . . . . . . . . . . . . .  6
       5.2.2.  Other CRs  . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Query and Response . . . . . . . . . . . . . . . . . . . .  7
       6.1.1.  Header Section . . . . . . . . . . . . . . . . . . . .  7
       6.1.2.  Question Section . . . . . . . . . . . . . . . . . . .  9
       6.1.3.  Answer, Security, and Additional Section . . . . . . .  9
     6.2.  NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Transport  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 10
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   11. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11
     11.1. draft-kong-dns-conf-auto-sync: Version 00  . . . . . . . . 11
     11.2. draft-kong-dns-conf-auto-sync: Version 01  . . . . . . . . 11
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12








Kong, et al.            Expires January 13, 2011                [Page 2]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


1.  Introduction

   The Domain Name System (DNS) [RFC1034] is a hierarchical naming
   system, which requires that more than one name server exist for every
   delegated domain (zone).  Each name server needs to be instructed by
   some configuration data, which is normally used to configure the
   behavior and functionality of the name server, e.g. the zones that
   the name server needs to support, the access control list of the
   hosts or users that is permitted to access the name server's zone
   files, or the mechanism of zone transfer.  Normally, these
   configuration data are manually managed by a local system
   administrator [RFC1033].

   However, in order to enhance the Service Level Agreement (SLA) for
   DNS services, most registries, registrars and providers of the
   managed DNS service have implemented a fair number of name servers
   for their zones.  Every time the policy of configuration changes,
   e.g. a new zone needs to be added, or DNSSEC needs to be supported,
   administrators needs to modify a lot of configuration data of name
   servers within a period of time.  Obviously, the manual operations of
   the configuration data turn into heavy burden for administrators.

   This document proposes an in-band synchronization mechanism to
   automatically synchronize configuration data among multiple DNS name
   servers.  Using this mechanism, any part of configuration data of a
   name server can be constructed as a similar DNS zone file, and be
   automatically synchronized by DNS messaging and notifying mechanisms.
   By this way, administrators don't need to manually modify every
   configuration files, and registries, registrars and providers of the
   managed DNS service don't need to develop some out-of-band softwares
   to realize the automatic management of configuration files for name
   servers.


2.  Terminology

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

   The following definitions are used in this document:

   o  Configuration data: Some information used to control the behavior
      and functionality of a name server.  By now, its syntax depends on
      the implementation of the name server.



Kong, et al.            Expires January 13, 2011                [Page 3]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


   o  Clause of Configuration: A clause which contains a serial of
      configuration items used to control some kind of behavior or
      functionality of a name server.  For example, a clause is used to
      specify the zones that the name server needs to support, and
      another clause is used to confirm the access control list of the
      hosts or users that is permitted to access a name server's zone
      files.  A clause of configuration is the smartest unit of
      synchronization.

   o  Sentence of Configuration: A sentence which contains a specific
      configuration item used to control one behavior or functionality
      of a name server.

   o  Configuration Record (CR): A data record used to contain the
      configuration data of a sentence with the similar format of DNS
      resource record.

   o  Configuration Zone (CZ): A zone contains a series of CRs related
      to a clause.

   o  Access Set of CZ: A set of name servers to be allowed to access
      (acquire) the zone data of a CZ.

   o  Synchronization Set of CZ: A set of name servers to be allowed to
      synchronize (modify) the zone data of a CZ.

   o  Notify Set of CZ: A set of name servers to be notified of changes
      of a CZ's zone data.


4.  Overview

   According to the proposed mechanism, whenever synchronization is to
   be done from one name server to others, several CZ files which is
   similar to DNS zone files are constructed and CRs are included in the
   files in the formats specified in this document.

   Once a CZ file has been changed, the performing name server will
   advises a set of other name servers within a predefined Notify Set of
   the change.  If the identity of the notification could be verified,
   the notified name servers could request the new data via the current
   DNS messaging mechanism and do the re-configuration according to the
   obtained configuration data.


5.  Configuration Record

   The definition of CR complies with section 3.1 of [RFC1035].



Kong, et al.            Expires January 13, 2011                [Page 4]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


5.1.  Format

   All CRs have the same top level format which is defined in section
   3.2.1 of [RFC1035], with some fields redefined as follows:

                                             1  1  1  1  1  1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                                               /
             /                      NAME                     /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                                               /
             /                      TYPE                     /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                                               /
             /                      CLASS                    /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                       TTL                     |
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    RDLENGTH                   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
             /                      RDATA                    /
             /                                               /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   o  NAME: A name of the CZ to which this CR pertains.  This fields are
      represented as a sequence of labels, where each label consists of
      a length octet followed by that number of octets.

   o  TYPE: A type of the requested CR.  This fields are represented as
      a sequence of labels, where each label consists of a length octet
      followed by that number of octets.

   o  CLASS: A class of the CZ to which this CR pertains.  This fields
      are represented as a sequence of labels, where each label consists
      of a length octet followed by that number of octets.

   o  TTL: Same meaning as [RFC1035].

   o  RDLENGTH: An unsigned 16 bit integer that specifies the length in
      octets of the CRDATA field.




Kong, et al.            Expires January 13, 2011                [Page 5]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


   o  RDATA: A variable length string of octets that describes the
      resource.  The format of this field according to the TYPE and
      CLASS of the CR.

   For example, there is a clause used to specify the "example.com" zone
   that the name server needs to support, and the mechanism of zone
   transfer for this zone is AXFR.  Then the NAME of a CZ for this
   clause is "example.com", the CLASS of this kind of CZs can be defined
   as "Zone", the type of a CR for the mechanism of zone transfer can be
   defined as "zone_transfer", and the RDATA will contain the following
   characters "AXFR".

5.2.  Standard CRs

5.2.1.  SERIAL CR

   Every CZ SHOULD has a standard CR named SERIAL, which used to
   indicate the version of a CZ.

   The value of the TYPE field of a SERIAL CR must be SERIAL.

   The format of the RDATA filed is defined as follows:

             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                   SERIAL                      |
             |                                               |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   Where:

   o  SERIAL: An unsigned 32 bit version number of a CR.  CR transfers
      preserve this value.  This value wraps and should be compared
      using sequence space arithmetic.

5.2.2.  Other CRs

   The definitions of other CRs should be expected, which are used to
   express specific configuration items used to control some kind of
   behavior or functionality of a name server.

   Note that the list of other CRs which are necessary to be defined
   here need to be discussed, e.g. the CR used to contain configuration
   data for DNS zones, the CR used to contain configuration data for
   access control list, and the CR used to contain configuration data
   for DNS logging, and so on.  Then the new TYPE, CLASS and RDATA
   formats of these CRs should be defined here later.





Kong, et al.            Expires January 13, 2011                [Page 6]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


6.  Messages

   This automated synchronization mechanism for the configuration data
   of multiple DNS name servers uses the DNS message format defined by
   [RFC1035], although it makes some extensions and overload some
   fields.  Fields not otherwise described herein are to be filled with
   binary zero (0).

6.1.  Query and Response

   The overall format of a query message or a response message is
   divided into 5 sections (some of which are empty in certain cases)
   shown below:

                          +---------------------+
                          |        Header       |
                          +---------------------+
                          |       Question      |
                          +---------------------+
                          |        Answer       |
                          +---------------------+
                          |       Security      |
                          +---------------------+
                          |      Additional     |
                          +---------------------+

   The Header Section specifies that this message is a query or a
   response of the automated synchronization mechanism for the
   configuration data of multiple DNS name servers, and describes the
   size of the other sections.  The Question Section contains fields
   that describe a question to a name server.  The Answer Section
   contains CRs that answer the question.  The Security Section contains
   some security information for authentication.  The Additional Section
   contains some additional information which relate to the query, but
   are not strictly answers for the question.

6.1.1.  Header Section

   The header for queries or responses is based on the DNS message
   format which is defined in section 4.1.1 of [RFC1035], with some
   fields redefined as follows:










Kong, et al.            Expires January 13, 2011                [Page 7]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


                                            1  1  1  1  1  1
              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                      ID                       |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |QR|   OpCode  |        Z           |   RCODE   |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    QDCOUNT                    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    ANCOUNT                    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    SCCOUNT                    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                    ARCOUNT                    |
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   These fields are used as follows:

   o  ID: Same meaning as [RFC1035].

   o  QR: A one bit field that specifies whether this message is a query
      (0), or a response (1).

   o  OpCode: A four bit field that specifies the kind of request in
      this message.  This value is set by the originator of a request
      and copied into the response.  The OpCode value that identifies a
      queries or responses message of the automated synchronization
      mechanism for the configuration data of multiple DNS name servers
      is six (6).

   o  Z: Reserved for future use.  Must be zero in all queries and
      responses.

   o  RCODE: this four bit field is undefined in queries and set in
      responses.  The values and meanings of this field within responses
      are as follows:

      *  0-2: Same meaning as [RFC1035].

      *  3: Name Error - the name of a CZ referenced in the query does
         not exist.

      *  4-5: Same meaning as [RFC1035].

      *  6-15: Reserved for future use.






Kong, et al.            Expires January 13, 2011                [Page 8]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


   o  QDCOUNT: Same meaning as [RFC1035].

   o  ANCOUNT: Same meaning as [RFC1035].

   o  SCCOUNT: an unsigned 16 bit integer specifying the number of
      configuration records used for authentication in the Security
      section.

   o  ARCOUNT: an unsigned 16 bit integer specifying the number of
      configuration records in the Additional section.

6.1.2.  Question Section

   The Question section contains QDCOUNT (usually 1) entries, each of
   the following format:

                                             1  1  1  1  1  1
               0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                     QNAME                     /
             /                                               /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                     QTYPE                     /
             /                                               /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
             |                                               |
             /                     QCLASS                    /
             /                                               /
             +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   o  QNAME: the same as the NAME field of CRs.

   o  QTYPE: the same as the TYPE field of CRs.

   o  QCLASS: the same as the CLASS field of CRs.

6.1.3.  Answer, Security, and Additional Section

   The answer, authority, and additional sections all share the same
   format: a variable number of configuration records, where the number
   of records is specified in the corresponding count field in the
   header.





Kong, et al.            Expires January 13, 2011                [Page 9]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


6.2.  NOTIFY

   By the function of NOTIFY, a name server may advises a set of other
   name servers within a predefined Notify Set of a CZ that the CZ's
   data has been changed and that a query should be initiated to request
   the new data.

   The message format of NOTIFY is the same as the query and response.
   The OpCode value of NOTIFY is seven (7).

   The mechanism of NOTIFY is the same as DNS NOTIFY defined by
   [RFC1996].


7.  Transport

   The transport of the messages is the same as the one of standard DNS
   message defined by section 4.2 of [RFC1035].  Both UDP and TCP are
   acceptable, but TCP is recommended.

   The mechanisms for DNS zone transfer (AXFR [RFC5936] and IXFR
   [RFC1995]) could be used for CZ transfer.


8.  IANA Considerations

   IANA is requested to assignment the OpCode 6 to the query and
   response of the automated synchronization mechanism for the
   configuration data of multiple DNS name servers, and the OpCode 7 to
   the NOTIFY of this mechanism.


9.  Security considerations

   Because the configuration data of a name server can be synchronized
   by other name servers using this automated synchronization mechanism,
   it's possible that the behavior and functionality of a name server
   will be maliciously modified by other name server.  So any
   implementation of this document is strongly suggested to realize the
   Access Set of CZs and the Synchronization Set of CZs.  Moreover, TSIG
   [RFC2845] is supposed to be used for authentication.


10.  Acknowledgements

   The authors especially thanks the authors of [RFC1035] and [RFC1996],
   and the following ones:Feng Han, Guonian Sun.




Kong, et al.            Expires January 13, 2011               [Page 10]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


11.  Change History

   RFC Editor: Please remove this section.

11.1.  draft-kong-dns-conf-auto-sync: Version 00

   o  First draft

11.2.  draft-kong-dns-conf-auto-sync: Version 01

   o  Improved the text.

   o  Added the "Overview" section.

   o  Updated the "Definitions" section.  Deleted the definition of
      "Configuration Template".

   o  Modified the example of the "Configuration Record" section.
      Changed "test.cn" into "example.com".

   o  Added the "Other CRs" sub section in the "Configuration Record"
      section.

   o  Added the "Change History" section.


12.  Normative References

   [RFC1033]  Lottor, M., "Domain administrators operations guide",
              RFC 1033, November 1987.

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

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS



Kong, et al.            Expires January 13, 2011               [Page 11]


Internet-Draft             DNS CONF AUTO SYNC                  July 2010


              (TSIG)", RFC 2845, May 2000.

   [RFC5936]  Lewis, E. and A. Hoenes, "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, June 2010.


Authors' Addresses

   Ning Kong
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3147
   Email: nkong@cnnic.cn


   Cindy Wang
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3074
   Email: wangxin@cnnic.cn


   Xiaodong Lee
   CNNIC
   4 South 4th Street,Zhongguancun,Haidian District
   Beijing, Beijing  100190
   China

   Phone: +86 10 5881 3020
   Email: lee@cnnic.cn















Kong, et al.            Expires January 13, 2011               [Page 12]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/