International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
Reliable Strong Cache and Security for the
Domain Name System
S. Pari Elavarasan#1 , K. Sampath Kumar*2
# Department of Computer Science and Engineering, PGP College of Engineering and Technology, Namakkal,
Tamil nadu, India.
* Professor and head of Computer Science and Engineering, PGP College of Engineering and Technology, Namakkal
Tamil nadu, India.
Abstract— Effective caching in the Domain Name System
(DNS) is critical to its performance and scalability to overcome
the sudden and dramatic Internet failures, natural and human
disasters, frequent changes of Internet Protocol (IP) addresses
and fine-grain controls for balance load distributions. The
strong DNS cache consistency improves the availability and
reliability of Internet services. We introduce a new strategy to
build chains of trust from root servers to authoritative servers.
The techniques we employ are based on symmetric-key
cryptography.
Then, In propose system a DNS Security Extensions
(DNSsec), running as middleware in DNS, to provide string
authentication and integrity to the DNS. It compare
cryptographic algorithm with other existing lease schemes.
Based on this process, build a DNSsec with minor
modifications to the current DNS implementation. The system
might be designed and keep track of the DNS name servers
such that it suppose to keep only the frequently used IP
addresses and may required regularly and at the same
instance it should involved in deletion of IP address which are
fake one. Our system prototype demonstrates the effectiveness
of DNSsec and its easy and incremental deployment on the
internet.
Keywords— Domain name system, cache consistency,
middleware, cryptograpy.
I.INTRODUCTION
The Domain Name System (DNS) is a
distributed database that provides a directory service
to translate domain names to Internet Protocol (IP)
addresses. DNS consists of a hierarchy of name
servers. For such a hierarchical system, caching is
critical to its performance and scalability. To
determine the IP address of a domain name, the DNS
resolver residing at a client sends a recursive query to
its local DNS name server. If no valid cached
ISSN: 2231-5381
mapping exists, then the local DNS name server will
resolve the query by iteratively communicating with
a root name server, a Top-Level Domain (TLD) name
server, and a series of authoritative DNS name
servers. All the replied DNS messages including
referrals and answers are cached at the local DNS
name server so that subsequent queries for the same
domain name will be answered directly from the
cache. Therefore, DNS caching significantly reduces
the workload of root and TLD name servers, lookup
latencies, and DNS traffic over the Internet [1].
A zone administrator deciding whether to deploy
DNSSEC must weigh the costs and benefits of:


The fraction of clients whose resolvers validate
DNSSEC records and therefore would be able to
detect tampering if it were occurring and
DNSSEC were deployed.
The fraction of clients which fail with valid
DNSSEC records and therefore will be unable to
reach the server whether or not tampering is
occurring.
The Domain Name System(DNS) has become a
critical operational part of the Internet Infrastructure,
yet it has no strong security mechanisms to assure
Data Integrity or Authentication. Extensions to the
DNS are described that provide these services to
security aware resolves are applications through the
use of Cryptographic Digital Signatures. These
Digital Signatures are included zones as resource
records [11].
http://www.ijettjournal.org
Page 182
International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
The extensions also provide for the storage of
Authenticated Public keys in the DNS. This storage
of keys can support general Public key distribution
services as well as DNS security. These stored keys
enables security aware resolvers to learn the
authenticating key of zones, in addition to those for
which they are initially configured. Keys associated
with DNS names can be retrieved to support other
protocols. In addition, the security extensions provide
for the Authentication of DNS protocol transactions.
The DNS Security is designed to provide security by
combining the concept of both the Digital Signature
and Asymmetric key (Public key) Cryptography.
Here the Public key is send instead of Private key.
The DNS security uses Message Digest Algorithm to
compress the Message(text file) and PRNG(Pseudo
Random Number Generator) Algorithm for
generating Public and Private key. The message
combines with the Private key to form a Signature
using DSA Algorithm, which is send along with the
Public key. The receiver uses the Public key and
DSA Algorithm to form a Signature. If this Signature
matches with the Signature of the message received,
the message is Decrypted and read else discarded.
Authenticity is based on the identity of some entity.
This entity has to prove that it is genuine. In many
Network applications the identity of participating
entities is simply determined by their names or
addresses. High level applications use mainly names
for authentication purposes, because address lists are
much harder to create, understand, and maintain than
name lists [11].
II.RELATED WORKS
DNS performance at either root name servers or
local DNS name servers and their caching
effectiveness have been studied in the past decade. In
first conduct extensive Internet measurements to
quantitatively characterize DNS dynamics; then
propose a proactive DNS cache update protocol,
called DNScup, running as middleware in DNS
nameservers, to provide strong cache consistency for
DNS. The core of DNScup is an optimal lease
scheme, called dynamic lease, to keep track of the
local DNS nameservers. We compare dynamic lease
ISSN: 2231-5381
with other existing lease schemes through theoretical
analysis and trace-driven simulations. Based on the
DNS Dynamic Update protocol, we build a DNScup
prototype with minor modifications to the current
DNS implementation. Our system prototype
demonstrates the effectiveness of DNScup and its
easy and incremental deployment on the Internet [1].
Motivated by our ongoing work exploring an
alternative Internet architecture, we wish to make use
of naming services in order to support functionality
such as: host and network mobility; application
and/or virtual machine migration; and various forms
of traffic control (e.g. multi-homing). Currently, the
Domain Name System (DNS) is used to resolve
names to DNS records, with relatively large time-tolive (TTL) values (several thousands of seconds) for
caching the results. To support new agile services and
systems, cached results may need to have much lower
TTL values, so that cached DNS values do not
become stale as system changes occur, e.g. changes
to end-system location information to support new
methods of mobility. However, current conventions
for DNS configuration normally use conservatively
high TTL values. We have conducted an empirical
study of a live DNS deployment where we have
reduced to zero the TTL values of records for the
entire School of Computer Science at the University
of St Andrews. Our results show that the increase in
DNS load is much lower than might be expected,
following a highly non-linear decrease with respect to
the TTL value of the DNS records [5].
The mapping service provided by the Domain
Name System (DNS) is fundamental not only to the
health of the Internet but also to the protection and
integrity of the data. Recently, the DNS infrastructure
has suffered several malicious attacks including DNS
cache poisoning, which causes the DNS to return
false name-to-IP mappings and can be used as a
foothold for more insidious attacks. I propose a peerto-peer based scheme to quickly detect and correct
inaccurate DNS records caused by cache poisoning
attacks. This scheme also helps DNS servers to
improve cache consistency by detecting and
removing stale cached records. This scheme does not
require modifications to the current infrastructure and
http://www.ijettjournal.org
Page 183
International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
can be deployed quickly. In addition, it does not use
cryptographic techniques and thus does not suffer
from the key management and processing overhead
issues of those techniques [4].
Recursive DNS (RDNS) resolvers on new attack
for poisoning the cache was discovered in DNS. DNS
software only partially protected the DNS poisoning
in servers. I discuss two type of DNS poisoning
prevention methods 1) wildcard secure DNS
(WSECDNS) and 2) Start of authority (SOA) in
without changing protocol. In wild-card given in the
RFC 1034, RFC 4592 and TXT resource records in
order to increase the flow of DNS queries to the point
that cache poisoning attack infeasible. The stubresolvers depend on the RDNS for the IP address. It
is responsible for the direct contraction authoritative
name servers on stub-resolvers and the cache
responses for a given TTL (Time to Live) and then
forwarded it back to stubresolvers. Now the
poisoning attack works by forcing an RDNS to look
up a domain name and then sending a forged before
RDNS gives back the domain to the server. As per in
this paper the RDNS sends authoritative name to the
server it provides and recommends a TLD(Top Level
Domain) server as we don’t give any knowledge of
the IP address to the RDNS. Now RDNS will ask for
the TLD servers for the IP of authoritative name
server. TLD will response with the recommend to
SOA (Start of Authority) for the domain and finally
gives record to stubresolvers through the path of
RDNS. So the attack over the cache is not possible as
the domain is sent from the SOA [2].
The mapping or binding of IP addresses to host
names became a major problem in the rapidly
growing Internet and the higher level binding effort
went through different stages of development up to
the currently used Domain Name System (DNS) [11].
The DNS Security is designed to provide security by
combining the concept of both the Digital Signature
and Asymmetric key (Public key) Cryptography.
Here the Public key is send instead of Private key.
The DNS security uses Message Digest Algorithm to
compress the Message (text file) and PRNG (Pseudo
Random Number Generator) Algorithm for
generating Public and Private key. The message
ISSN: 2231-5381
combines with the Private key to form a Signature
using DSA Algorithm, which is send along with the
Public key. The receiver uses the Public key and
DSA Algorithm to form a Signature If this Signature
matches with the Signature of the message received,
the message is Decrypted and read else discarded.
III.PROPOSED METHODOLOGY
The scope of the security extensions to the DNS
can be summarized into three services: key
distribution, data origin authentication, and
transaction and request authentication [6].
A. Key distribution
The key distribution service not only allows for the
retrieval of the public key of a DNS name to verify
the authenticity of the DNS zone data, but it also
provides a mechanism through which any key
associated with a DNS name can be used for
purposes other than DNS. The public key distribution
service supports several different types of keys and
several different types of key algorithms [8].
B. Data origin authentication
Data origin authentication is the crux of the design of
DNSSEC. It mitigates such threats as cache
poisoning and zone data compromise on a DNS
server. The RRSets within a zone are
cryptographically signed thereby giving a high level
of assuredness to resolvers and servers that the data
just received can be trusted [8].
DNSSEC makes use of digital signature technology
to sign DNS RRSet. The digital signature contains
the encrypted hash of the RRSet. The hash is a
cryptographic checksum of the data contained in the
RRSet. The hash is signed (i.e., digitally encrypted)
using a private key usually belonging to the
originator of the information, known as the signer or
the signing authority. The recipient of the RRSet can
then check the digital signature against the data in the
RRSet just received. The recipient does this by first
decrypting the digital signature using the public key
of the signer to obtain the original hash of the data.
http://www.ijettjournal.org
Page 184
International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
Then the recipient computes its own hash on the
RRSet data using the same cryptographic checksum
algorithm, and compares the results of the hash found
in the digital signature against the hash just
computed. If the two hash values match, the data has
integrity and the origin of the data is authentic.
C. DNS transaction and request authentication
DNS transaction and request authentication provides
the ability to authenticate DNS requests and DNS
message headers. This guarantees that the answer is
in response to the original query and that the response
came from the server for which the query was
intended. Providing the assurance for both is done in
one step. Part of the information, returned in a
response to a query from a security aware server, is a
signature. This signature is produced from the
concatenation of the query and the response. This
allows a security aware resolver to perform any
necessary verification concerning the transaction.
Another use of transaction and request authentication
is for DNS Dynamic Updates. Without DNSSEC,
DNS Dynamic Update does not provide a mechanism
that prohibits any system with access to a DNS
authoritative server from updating zone information.
In order to provide security for such modifications,
Secure DNS Dynamic Update incorporates DNSSEC
to provide strong authentication for systems allowed
to dynamically manipulate DNS zone information on
the primary server [7].
DNSSEC works by signing domains (including root
and top level) and zones using public/private key
cryptography, thereby creating a chain of trust. Note
that to be backwards compatible with non-DNSSEC
enabled servers and clients, queries are completed
using standard DNS when DNSSEC is not available.
In other words, when DNSSEC is not available
throughout the entire chain - from requestor client to
resolver/caching nameserver
to authoritative
nameservers - the system reverts to regular DNS [6].
However, if DNSSEC is available throughout the
chain, the client has a level of assurance that the DNS
query response is signed and trustworthy starting
ISSN: 2231-5381
from the root and chaining all the way down to the
domain and subdomains. The following illustration
provides a high-level overview of DNSSEC in action.
D. Caveats
DNSSEC is one way to improve the overall security
of DNS. But before you going running off and
planning for full implementation of DNSSEC at your
organization, note that there are some criticisms and
caveats. Because DNSSEC was designed to respond
with complete, signed, authoritative information
about a domain or sub-domain, it does not work well
with traditional split (or split-horizon) DNS
architectures. In split DNS architecture, some
machine information is available to all requestors
while other information, such as servers with highly
sensitive data that should be accessible only from the
trusted internal network and not from the Internet, is
kept private. Since DNSSEC makes previously
private information public, it opens zones up to
enumeration/walking exposures which allows
attackers to use DNSSEC information to determine a
definitive list and map of hosts in a zone. To mitigate
this issue, the extension DNSSEC Hashed
Authenticated Denial of Existence (a.k.a. NSEC3)
was introduced in 2008, but is not yet in wide use [6].
IV.IMPLEMENTATION MECHANISM
DNSSEC purely to address the risk. One of the
most common ways of “defacing” a web server is to
redirect its domain name to the address of a host
controlled by the attacker through manipulation of
the DNS. DNSSEC eliminates some of these
problems by providing end-to-end authenticity and
data integrity through transaction signatures and zone
signing.
Transaction signatures are computed by clients and
servers over requests and responses. DNSSEC allows
the two parties either to use a message authentication
code (MAC) with a shared secret key or public-key
signatures for authenticating and authorizing DNS
messages between them. The usefulness of
transaction signatures is limited since they guarantee
integrity only if a client engages in a transaction with
http://www.ijettjournal.org
Page 185
International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
the server who is authoritative for the returned data,
but do not protect against a corrupted server acting as
a resolver. For zone signing, a public-key for a digital
signature scheme, called a zone key, is associated
with every zone. Every resource record (it is the basic
data unit in the DNS database) is complemented with
an additional SIG resource record containing a digital
signature, computed over the resource record and can
implement DNSSEC on an end-to-end basis, signing
and validating internal zone data. Finally, conclude
Encryption and Decryption, Signature Creation, and
Signature Verification [11].
A. The chain of trust
In order for DNSSEC to be fully deployed, an
unbroken chain of trust needs to be established, down
from the root at the top, through the TLD, down to
individual registrants. All zones need to be
authenticated by “signing”, i.e. the publisher of a
zone signs that zone prior to publication and the
parent of that zone publishes the keys of that zone.
To achieve this we need the root signed and
procedures in place at each step to enable the secure
transmission of keys between parties.
B. Secure key management
Currently registries only make minimal use of keys
within DNS transactions as part of the ordinary
operations of the registry. Managing DNSSEC keys
requires a registry to implement a new infrastructure
for the secure storage and transmission of keys,
including both suitable equipment and procedures.
C. Signing changes
In common with a few of the larger TLD registries,
Nominet currently provides near synchronous zone
file publication. This means that new domain name
registrations are entered into the DNS within minutes
and can work almost immediately. Signing a large
zone, like co.uk which has over 6 million
registrations, would be a highly involved and
maintenance intensive task. Given the frequency of
updates to the records within co.uk, which can peak
at 300,000 per day, signing a large, fast-changing
ISSN: 2231-5381
zone in real time will require significant
cryptographic processing power and reliability.
D. Automated re-signing
With any zone it is likely that the signatures will
expire before the DNS records are updated. Zone
operators therefore require a means to automatically
re-sign DNS records before these signatures expire.
This functionality is dubbed ‘continuous signing’ and
is not yet a feature of common nameserver
implementations. Nominet is therefore providing
financial assistance to the Internet Standards
Consortium (ISC) to fund the development of
continuous signing within BIND, one of the most
popular nameserver implementations in deployment.
E. Managing resource usage
Signed DNS records are considerably larger than
unsigned records, with a fully signed zone being an
order of magnitude greater in size than an unsigned
zone. Some registries have expressed concern at the
impact this will have on their infrastructure and
possibly limit their involvement with DNSSEC as a
consequence. However a solution for this exists with
NSEC3, the enhancements to DNSSEC that are close
to becoming an RFC. This solution is called ‘opt-out’
and enables a zone operator to only sign those
delegations that need DNSSEC. A registry that uses
this can manage the increase in resources in line with
the gradual uptake of DNSSEC, rather than being
forced into an all-or-nothing upgrade. Traditional
capacity management for registries has been based
around the number of domains within the zone.
However, future capacity planning will need to
incorporate the additional factor of the number of
signed zones to ensure that a true picture of resource
requirements is developed.
V.CONCLUSION
Our replicated name service provides fault
tolerance and security guarantees to secure DNS
against an attacker that compromises a fraction of
name servers in a zone, while supporting dynamic
updates. The results show that such a system can be
used in practice. DNSsec provide string
http://www.ijettjournal.org
Page 186
International Journal of Engineering Trends and Technology (IJETT) – Volume 9 Number 4 - Mar 2014
authentication and integrity to the DNS and compare
cryptographic algorithm with other existing lease
schemes. Based on this process, build a DNSsec with
minor modifications to the current DNS
implementation. The DNS as an Internet standard to
solve the issues of scalability surrounding the
hosts.txt file. Since then, the widespread use of the
DNS and its ability to resolve host names into IP
addresses for both users and applications alike in a
timely and fairly reliable manner, makes it a critical
component of the Internet. The distributed
management of the DNS and support for redundancy
of DNS zones across multiple servers promotes its
robust characteristics. The system might be designed
and keep track of the DNS name servers such that it
suppose to keep only the frequently used IP addresses
and may required regularly and at the same instance
it should involved in deletion of IP address which are
fake one. Our system achieves the reliable strong
cache in DNS and significantly improves its
availability, performance and scalability.
[3] Vinton Cerf, Paul Twomey, “https://www.icann.
org/en/about/staff/.../ssr/dnssec-paper-15jul08-en.pdf,” ICANN, 12
June 2007.
[4] Lihua Yuan, Krishna Kant, Prasant Mohapatra, Chen-Nee
Chuah, “DoX: A Peer-to-Peer Antidote for DNS Cache Poisoning
Attacks” Communications, June 2006. ICC '06. IEEE International
Conference on (Vol:5).
[5] Saleem N. Bhatti, Randall Atkinson, “Reducing DNS Caching”
Computer Communications Workshops (INFOCOM WKSHPS),
2011 IEEE Conference on, 10-15 April 2011.
[6] Diana Kelley, “http://www.esecurityplanet.com/vi
ews/article.php/3923021/What-the-Heck-is-DNSSEC
.htm” February 01, 2011.
[7] IETF DNSSEC
WG,
"DNS
Security
(dnssec)
Charter",IETF,1994.”http://www.ietf.cnri.reston.va.us/proceedings
/94dec/charters/dnssec-charter.html”.
[8] Diane Davidowicz, “http://compsec101.antibozo.
net/papers/dnssec/dnssec.html” 1999.
[9] D. Eastlake, C. Kaufman Iris,“http://www.freesoft
.org/CIE/RFC/2065/index.htm, Jan 1997.
[10]
R
Chandramouli,
“http://static-71-166-250129.washdc.east.verizon.net/eLibrary/TECH/US_DOC/N100400C.
pdf” Oct 2009.
[11] Sachin Kumar Sinha, Avinash Kant Singh, Amaresh Sharma,
“Security System for DNS using Cryptography” (IJERT)ISSN:
2278-0181) Vol. 2 Issue 2, February- 2013.
REFERENCES
AUTHORS PROFILE
[1] Xin Chen, Haining Wang, Shansi Ren, Xiaodong Zhang,
“Maintaining Strong Cache Consistency for the Domain Name
System” IEEE August 2007 (vol. 19 no. 8).
[2] K. Sampath Kumar, Dr.G.K.D.Prasanna Venkatesa, “Effective
Method of Prevention of Cache Poisoning for Wild Card Secure
DNS – A Novel Approach” IRACST – Engineering Science and
Technology: An International Journal (ESTIJ), ISSN: 2250-3498,
Vol.3, No.2, April 2013.
ISSN: 2231-5381
1) S.Pari Elavarasan, Department of Computer Science and
Engineering at PGP College of Engineering and Technology,
Namakkal, Tamilnadu, India..
2) K.Sampath Kumar, Professor and head / Computer Science and
Engineering Department at PGP College of Engineering and
Technology, Namakkal, Tamilnadu, India. Presently Research
Scholar at Anna University, Chennai, India.
http://www.ijettjournal.org
Page 187