dnsop WG C. Wang Internet-Draft W. Meng Intended status: Standards Track S. Huang Expires: January 3, 2016 ZTE Corporation July 2, 2015 Synchroniztion between resolvers and servers draft-huang-dnsop-synchronization-resolver-server-00 Abstract This document proposes how to synchronize the RRs in the resolvers along with the RRs in the authoritative servers when changes are occurred on the RRs in the authoritative servers. 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 3, 2016. Copyright Notice Copyright (c) 2015 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 Simplified BSD License. Wang, et al. Expires January 3, 2016 [Page 1] Internet-Draft SYNC July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 3. an analysis on DNS . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Authoritative DNS servers . . . . . . . . . . . . . . . . 5 4. Definition of the Cache-Sync RRType . . . . . . . . . . . . . 7 5. Definition of the Notification Message . . . . . . . . . . . . 8 6. Definition of the session table of the cached RRs information on resolvers . . . . . . . . . . . . . . . . . . . 9 7. operational considerations . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Wang, et al. Expires January 3, 2016 [Page 2] Internet-Draft SYNC July 2015 1. Introduction DNS is defined in [RFC1034] and [RFC1035]. It has been a challenge that how to steer the traffic to the correct destination when the RRs in the authoritative servers have changed, while the cached RRs information locally in the resolvers is still alive. This document tries to describe how to synchronize automatically the cached RRs in the resolvers along with the RRs information in the authoritative servers when changes are occurred on the RRs information in the authoritative servers. Specifically, this document tries to provide: In section 3, In section 3, an analysis on DNS In section 4, definition of the Cache-Sync RRType In section 5, definition of the Notification Message In section 6, definition of the session table of the cached RRs information on resolvers In section 7, operational considerations In section 8, security considerations Wang, et al. Expires January 3, 2016 [Page 3] Internet-Draft SYNC July 2015 2. Convention and 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]. The terms about DNS are all defined in [RFC1034] and [RFC1035]. Wang, et al. Expires January 3, 2016 [Page 4] Internet-Draft SYNC July 2015 3. an analysis on DNS 3.1. Resolvers According to the description in [RFC1034], resolvers are programs that extract information from name servers in response to client requests. Resolvers must be able to access at least one name server and retrieve the RRs information from name servers!_ responses, and then store RRs information in the local cache, and use this RRs information to answer a query directly, or pursue the query using referrals to other name servers. How long the RRs information would be cached in resolvers is decided by the Time To Live field in the DNS response messages. Before it is expired, the resolver use this cached RRs information to answer a query directly if the QNAME/QTYPE/ QCLASS in the query is matched. Sometimes, the resolver is located on the same machine as the program that requests the resolver!_s services. And sometimes, the resolver is located on an unauthorized name server which supports recursive queries. In the latter case, it is widely used to centralize the cache for a whole local network or organization. Conventionally, the RRs information in the authoritative name servers is authoritative, while the cached RRs information in the resolvers is unauthorized. When changes occur on the authoritative RRs information, how these changes are notified to the resolvers to update the cached RRs information before this information is expired is an open issue. If the cached RRs information doesn!_t update immediately, the resolver would use the old cached RRs information to answer the client instead of the recently changed RRs information, which may mislead the client!_s traffic to the old and wrong destination. This document tries to propose a mechanism which can eliminate this issue. After caching the RRs information from the authoritative name server, the resolver sends a notification message to that name server. Then, that name server updates the session table of the cached RRs information with corresponding resolvers. Once changes occur on the cached RRs information in the authoritative name severs, this name server sends update messages to the corresponding resolvers which cache this changed RR information. 3.2. Authoritative DNS servers According to description in [RFC1034], name servers are programs which hold information about the domain name space and associated RRs. A name server may cache domain name space or associated RRs information about any part of the domain tree, but in general a Wang, et al. Expires January 3, 2016 [Page 5] Internet-Draft SYNC July 2015 particular name server has complete information about a subset of the domain space, and pointers to other name servers that can be used to lead to information from any part of the domain space. Name servers know the parts of domain space for which they have complete information; a name server is said to be an AUTHORITY for these parts of the name space. Authoritative information is organized into units called ZONES, and how these zones synchronize cached name space and associated RRs information is out of scope. This document focuses on how to synchronize this RRs information between resolvers and these name servers. In fact, after receiving the query from the resolver, if the query is matched in local cache, the DNS name server answers the authoritative RRs information in the response message to the resolver. Meanwhile, if the name server supports the control of caching notification, the name server carries the caching notification control information in the response message together. After receiving the response message, the resolver caches the RRs information in the response message and decides whether to send a notification message or not according to whether there is caching notification control information carried in the response message. If there is caching notification control information, then the resolver sends a notification message, otherwise, do nothing. In some situation, instead of managing the cached RRs information on resolvers in a distributed manner, there is a central caching manager, which can manage all the cached RRs on resolvers and corresponding resolvers. When authoritative name server sends the response message with the caching notification control information, the central caching manager's address can be carried together in the response message to the resolver. Then, the resolver knows where the notification message is send to. Wang, et al. Expires January 3, 2016 [Page 6] Internet-Draft SYNC July 2015 4. Definition of the Cache-Sync RRType As for the caching notification control information, here tries to extend an new RRType to carry them. The new Cache-Sync RRType contains, in its RDATA component, a flag which identifies whether the resolver need to send notification message, and an address where the notification message is sent to. In Figure 1, there is a guideline about the Cache-Sync RRType format. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flag | Address | +-+-+-+-+-+-+-+-+ + ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Cache-Sync RDATA format Flag: identifies whether the resolver need to send notification message. By default, this field is set to zero, which means do not need to send notification message; Address: identifies where the notification message is sent to. By default, it is the address of the name server who responses the DNS query. When there is a central caching manager, it is the address of the central caching manager.Address: identifies where the notification message is sent to. By default, it is the address of the name server who responses the DNS query. When there is a central caching manager, it is the address of the central caching manager. Wang, et al. Expires January 3, 2016 [Page 7] Internet-Draft SYNC July 2015 5. Definition of the Notification Message TBD Wang, et al. Expires January 3, 2016 [Page 8] Internet-Draft SYNC July 2015 6. Definition of the session table of the cached RRs information on resolvers When DNS name server has no session table of the cached RRs information on resolvers, they need create this session table first when receiving the first notification message from the resolver. In this session table, it includes: the cached RRs information and corresponding resolver who caches this RRs information, caching timestamp, TTL, and caching status as well. After this session table is created, the following notification messages trigger to update the session items in this session table as well as add session items in this session table. When the TTL is expired, the corresponding session item would be discarded in the session table. When a RR information in the authoritative name server is changed proactively, the DNS name server sends update message to the corresponding resolver according to the session item stored in the session table. Wang, et al. Expires January 3, 2016 [Page 9] Internet-Draft SYNC July 2015 7. operational considerations TBD Wang, et al. Expires January 3, 2016 [Page 10] Internet-Draft SYNC July 2015 8. Security Considerations TBD Wang, et al. Expires January 3, 2016 [Page 11] Internet-Draft SYNC July 2015 9. IANA Considerations TBD Wang, et al. Expires January 3, 2016 [Page 12] Internet-Draft SYNC July 2015 10. Normative References [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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Wang, et al. Expires January 3, 2016 [Page 13] Internet-Draft SYNC July 2015 Authors' Addresses Cui Wang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: wang.cui1@zte.com.cn Wei Meng ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: meng.wei2@zte.com.cn,vally.meng@gmail.com Sunliang Huang ZTE Corporation No.50 Software Avenue, Yuhuatai District Nanjing China Email: huang.sunliang@zte.com.cn Wang, et al. Expires January 3, 2016 [Page 14]