Internet DRAFT - draft-huang-dnsop-synchronization-resolver-server
draft-huang-dnsop-synchronization-resolver-server
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]
