Internet Engineering Task Force N. Kong Internet-Draft C. Wang Intended status: Standards Track X. Lee Expires: January 6, 2011 CNNIC July 5, 2010 An Automated Synchronization Mechanism for Configuration Data of DNS (Domain Name System) Name Servers draft-kong-dns-conf-auto-sync-00 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 6, 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 6, 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. Configuration Record . . . . . . . . . . . . . . . . . . . . . 4 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Standard CR . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. SERIAL CR . . . . . . . . . . . . . . . . . . . . . . 6 5. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Query and Response . . . . . . . . . . . . . . . . . . . . 6 5.1.1. Header Section . . . . . . . . . . . . . . . . . . . . 7 5.1.2. Question Section . . . . . . . . . . . . . . . . . . . 8 5.1.3. Answer, Security, and Additional Section . . . . . . . 9 5.2. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Kong, et al. Expires January 6, 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 (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. 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 6, 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 Configuration Template: A template contains a series of configuration zone whose CRs used to generate configuration data which applies to the implementation of a name server. o Access Set of CZ: A set of name servers to be allowed to access 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. Configuration Record The definition of CR complies with section 3.1 of [RFC1035]. 4.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: Kong, et al. Expires January 6, 2011 [Page 4] 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / 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. o RDATA: A variable length string of octets that describes the resource. The format of this field according to the TYPE and Kong, et al. Expires January 6, 2011 [Page 5] Internet-Draft DNS CONF AUTO SYNC July 2010 CLASS of the CR. For example, there is a clause used to specify the "test.cn" zone that the name server needs to support, and the mechanism of zone transfer for this zone is AXFR. Then the NAME of a zone for this clause is "test.cn", the CLASS of this kind of zones 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". 4.2. Standard CR 4.2.1. SERIAL CR Every CZ may has a standard CR named SERIAL, which used to indicate the version of a zone. 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. 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). 5.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: Kong, et al. Expires January 6, 2011 [Page 6] Internet-Draft DNS CONF AUTO SYNC July 2010 +---------------------+ | 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. 5.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: 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: Kong, et al. Expires January 6, 2011 [Page 7] Internet-Draft DNS CONF AUTO SYNC July 2010 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 sentence or a clause referenced in the query does not exist. * 4-5: Same meaning as [RFC1035]. * 6-15: Reserved for future use. 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. 5.1.2. Question Section The Question section contains QDCOUNT (usually 1) entries, each of the following format: Kong, et al. Expires January 6, 2011 [Page 8] 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 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / 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. 5.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. 5.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]. 6. Transport The transport of the messages is the same as the one of standard DNS Kong, et al. Expires January 6, 2011 [Page 9] Internet-Draft DNS CONF AUTO SYNC July 2010 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. 7. 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. 8. 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. 9. Acknowledgements The authors especially thanks the authors of [RFC1035] and [RFC1996], and the following ones:Feng Han, Guonian Sun. 10. 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. Kong, et al. Expires January 6, 2011 [Page 10] Internet-Draft DNS CONF AUTO SYNC July 2010 [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 (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 6, 2011 [Page 11]