66 (IJCNS) International Journal of Computer and Network Security,

Vol. 2, No. 1, January 2010

DNS cache-record coordination

Using Adaptive Cache TTL Adjustment
Isihara Tomohiro1, Yuji Sekiya2
1
Keio University
sho@sfc.wide.ad.jp
2
University of Tokyo
sekiya@wide.ad.jp

Abstract: Domain Name System (DNS) cache mechanism 2. Background

improves performance and scalability to DNS. The current DNS
In current architecture of the Internet, each node has an IP
implementation only support fixed cache Time-to-Live(TTL),
address for its identifier. For user’s convenience, hostname
therefore when data update occurs, there is a coherence problem
between cached data and updated data.In this paper, we propose could be used instead of IP address. DNS provides mapping
an adaptive cache TTL adjustment mechanism to provide of these hostnames and IP addresses. Namespace is
consistency between cached record and original record in hierarchically distributed by zone, and each zone can be
authoritative server. we have implemented this mechanism administrated separately. Data which used in DNS is called
prototype with minor modifications to one of DNS resource record. Whenever clients receive an answer to
implementation, BIND [1]. This prototype demonstrates the query, the resource record is cached by client.
effectiveness of the mechanism which proposed in this paper.
Keywords: Domain Name System, DNS, Internet 2.1 Inconsistency Problem
In current DNS cache mechanism, authoritative server
1. Introduction answer a record in same TTL. Therefore, cached record will
Domain Name System(DNS) is a Name and Address be different from original record if original data is updated
translation system that widely used in the Internet. DNS has after the record was cached [Fig. 1]
high scalability because of its hierarchical distributed design
and caching. DNS cache reduces transaction between DNS
server and client, therefore query performance increases too.
DNS cache sets Time-to-Live (TTL) parameter. When the
TTL time runs out, clients drop the cache. These caches
could not by dropped before TTL expired even if the
original record is changed in Authoritative server. Hence,
when record is changed, possibly there is a difference
between cached record and original record. Therefore, it is
difficult to estimate appropriate cache TTL.
Several studies have been made on DNS cache and TTL. Figure 1. Inconsistency scenario
Danzig [2] analyzed traffic to one of root nameserver to
2.2 Zero TTL (no cache)
investigate how DNS cache saves traffic to upper node in
DNS tree. Jung [3] shows the most of DNS traffic is consist Zero TTL is a one of solution to solve this inconsistency. In
of wrong DNS packets, but DNS cache is still effective to DNS protocol, Zero TTL means ”no cache”. Clients doesn’t
cache a resource record if its TTL is 0. Although it is easy
reduce DNS traffic. Both researches focus on cache
and simple solution, Zero TTL causes serious performance
effectiveness on upper nodes in DNS tree, and there is few
and scalability problem. Moreover, US-CERT advised
studies which focuses on lower nodes.
extremely short TTL causes security threat such as DNS
Nowadays, dynamic DNS services that users can register spoofing [4].
their own IP address to DNS dynamically is increasing.
Thus record updating occurs frequently in such zones, and 2.3 Extension of current DNS Protocol
it is difficult to guarantee coherence between cached record Several DNS Protocol Extension which aims to solve this
and updated record. inconsistency problem was developed. DNScup [5] propose
This paper describes design and implementation of a new cache update message to expire obsolete caches. And
adaptive cache TTL adjustment mechanism which provides in Cohen [6] developed proactive caching mechanism for
consistency between cached record and original record in same purpose.
authoritative server. Each solutions need to upgrade current name server
 (IJCNS) International Journal of Computer and Network Security, 67
Vol. 2, No. 1, January 2010

implementations to support proposed protocols. In a long later from update. We used port mirror technique on switch
period, there solution will achieve a good consistency with which connects these servers. The Switch make mirror port
cache, however, deployment is very hard on the grounds that for each web server and nameserver port. Then trace PC was
replacing current running server software is not easy. connected to mirror port.[Fig. 4]

3. Adaptive Cache TTL Adjustment

Mechanism
We propose Adaptive Cache TTL Adjustment Mechanism to
solve inconsistency problem of DNS cache. This mechanism
uses count down method. When update is scheduled,
authoritative server keeps its expiration date locally, and its
TTL parameter decrease to expire just at update time.[Fig.
2]

Figure 4. Packet Trace Point

4.1 Packet Trace on Web Server

Figure 2. Adaptive cache TTL Adjustment
Hence cached TTL is reducing every second, and server
which have cache sends cached record with reduced TTL
when asked by another clients. Therefore, the cache TTL is
shared by clients, and these cached record in each servers
disappear in same time. [Fig 3]
Fig. 5 and 6 shows a number of TCP SYN packet to web
server. One of this used current fixed cache mechanisms,
and another one used adaptive cache TTL mechanism that
proposed in this paper. Black field is HTTP access to old IP
address, and white is access to new IP address. The updated
time is assumed to be 0 on X-AXIS.
In both result, there was a few access to new IP address
before change record. Result of examining these accesses,
these were web bot from some search engine and port-
scanner. And there was a bursty http traffic in normal
scenario. It was made by only one host in University in
United Kingdom. It threw over 100 TCP SYN packet per
second while five or six seconds. According to our survey of
this host, it is some kind of web crawler. However, it has no
connection with this experiment.
Comparing each results, It was linearly reducing access to
old address in case of fixed TTL. On the other hands, In
case of adaptive TTL, access to old address is reduced
rapidly than fixed TTL. Hence it is clear that cache
inconsistency is reduced too.

Figure 3. Cached record’s TTL is shared by each nodes.

4. Evaluation
We implemented prototype that equipped with proposed
function so that evaluate effectiveness of this mechanism.
This prototype only has simple interface which could specify
record to change and time for modification. This method
aims to achieves cache consistency, but in the other hands, it
increases the number of queries because of less cache TTL.
In order to evaluate this trade-off, we focused on DNS
query packets which ask our web server’s address, and
correspondent HTTP access likewise. Then, we updated a
record which is the most asked record in the zone,
www.sfc.wide.ad.jp. Since its default cache TTL is 1
hour(3600sec), we tapped from one hours ago to two hours
Figure 5. Number of TCP SYN to web server, in fixed
68
cache TTL
Figure 6. Number of TCP SYN to web server, in adaptive
cache TTL
4.2 Packet Trace on Name Server
Fig. 7 presents a number of DNS query packet to name
server. Black bar shows number of query in case that used
fixed cache TTL, and white is adaptive cache TTL.
An increase in query can be observed at 2000 – 3000 second
after from update. It is roughly two times from fixed cache,
and increasing was disappeared after elapsed time of TTL.
According to this result, it is entirely fair to say that there is
no critical traffic burst to DNS server.
5. Conclusion
We proposed an adaptive cache TTL adjustment mechanism
to provide consistency between cached record and original
record in authoritative server. To investigate effectiveness of
this propose, we have demonstrated prototype and gathered
related traffic:(1) queries to DNS server (2)HTTP traffic led
by changed record. And we explained observed effect for
this mechanism, and proved effectiveness of this propose.
Adaptive cache TTL Adjustment achieves the superior DNS
cache consistency without critical scalability crisis.
Actually, clients don’t always obey TTL. Sometimes
operating system (and resolver library) keeps DNS records
even if their TTL expired. For example, old windows
clients(windows98 and earlier) keep name cache for almost
30 minute regardless their TTL. Linux clients which uses
Name Server Cache Daemon(nscd) keep it for 15 minute. In
addition to this, several applications also hold records. Old
Internet explorer carries them for 30 minute.
Since there are several name server implementations,
behavior of each cache servers is different. Nevertheless, we
don’t have anymethods to estimate implementation for each
queries.
There is room for further investigation to get detailed
behavior.
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 1, January 2010
Figure 7. Number of DNS query to name server
6. Acknowledgement
We appreciate Jun Murai, Osamu Nakamura, Hiroyuki
Kusumoto for great advises and suggestions. This work is
supported by grants from WIDE project and Keio University
Murai Lab.
References
[1] Berkeley Internet Name Domain(BIND), Internet
Systems Consortium, http://www.isc.org
[2] P. B. Danzig and K. Obraczka and A. Kumar, An
analysis of wide-area name server traffic, ACM Comp.
Commun. Review (SIGCOMM’92), Conference Proc.
[3] Jaeyeon Jung, Emil Sit, Hari Balakrishnan and Robert
Morris, DNS Performance and the Effectiveness of
Caching, Proceedings of the ACM SIGCOMM Internet
MeasurementWorkshop 2001
[4] Various DNS service implementations generate
multiple simultaneous queries for the same resource
record, US-CERT Vulnerability Note VU#457875,
http://www.kb.cert.org/vuls/id/457875
[5] Xin Chen, Haining Wang, Shansi Ren, DNScup:
Strong Cache Consistency Protocol for DNS,
Distributed Computing Systems, 2006. ICDCS 2006.
26th IEEE International Conference
[6] Edith Cohen and Haim Kaplan, Proactive Caching of
DNS Records: Addressing a Performance Bottleneck,
SAINT2001.
 (IJCNS) International Journal of Computer and Network Security, 69
Vol. 2, No. 1, January 2010

Authors Profile

Tomohiro Isihara received the B.E.

degrees in Physics from Nihon University
in 2001. received M.E. degrees in Media
and Governance from Keio University in
2003. Currently, he has been in Doctor
course of Keio University.

Yuji Sekiya was received B.E. from Kyoto

University in 1997 and received M.E. from
Keio University in 1999. He worked at
USC/ISI (University of Southern California /
Information Sciences Institute) from Oct.
1999 for 6 months as a visiting researcher.
Currently He belongs to Information
Technology Centre in the University of
Tokyo since Oct. 2002. His major research
topics are IPv6 and DNS. He works for
USAGI Project as core member since its establishment. University.