Domain Name Security Extension

Published Date: 02 Nov 2017

Abstract—This paper is about vulnerabilities in DNS that is problem of Cache poisoning( DNS spoofing) and DNSSEC as a solution to handle these vulnerabilities. DNSSEC provides origin authenticity, data integrity, and secure denial of existence by using public-key cryptography .It also includes the latest implementation of DNSSEC in the real world. A major obstacle to the widespread adoption of DNSSEC is the complexity of implementing it. There is no package that one can install on a system, click the "start" button, and have DNSSEC running. Instead, there are a variety of tools, none of which on their own is a complete solution. To actually run a DNSSEC-enabled authoritative server requires writing custom scripts to link them together. Even then, aspects of DNSSEC management such as key management and use of hardware assistance (such as HSM:s) have not been adequately addressed.

Keywords—DNS, Information Security, Cryptography, Cache poisoning

Introduction

DNS stand for domain name system work of domain name system is to resolve the domain name into IP addresses DNS is the most critical component of the internet infrastructure. DNS contains zone files which contains the information about host name and IP addresses. Whenever the IP address of the domain changes the zone file has to be updated. The root zone of DNS contains information about all the TLD’s(Top level domain).generally in fully qualified domain name the root DNS zone is name less for example www.google.com. , when we write this address to the address bar then browser itself add the‘.’ After .com which is for root zone DNS & as mentioned above it is nameless.

A .Security issues in existing DNS

In general, security concerns hadn’t ever been major factors contributing to design for DNS software or any software for deployment on the early Internet since the network was not open for the general public. Nevertheless, the outgrowth of the Internet in the commercial domain in the 1990s changed the demands for security standards to protect data integrity and user authenticity.

Many vulnerability issues were detected and exploited by malicious users. One of many such issues is ‘DNS cache poisoning’.

B. DNS Terminology

1 . Zone- A domain is basically collection of hostnames/IP pairs all managed together. Ex- www.betterwebads.com, and all the records under it like- www.article.betterwebads.com, www.addirectory.betterwebads.com, are all part of the betterwebads.com zone.

2. Resolver- It is the client part of the DNS client/server system, it asks the questions about hostnames. The resolver is usually a small library compiled into each program that requires DNS services, and it knows just enough to send questions to a nearby name-server.

3. Recursive Name-server- This is a name-server that's willing to go out on the internet and find the results for zones.

4. Delegation-When a name-server doesn't have the contents of a zone, but if it knows how to find the owner, it's said to delegate service of that zone to another name-server.

5. Cache poisoning- is where the hacker manages to insert forge data into a name-server's cache, causing it to give out that wrong information to local clients. [1]

C. DNSSEC

Generally, DNS responses aren’t crypto logically signed, resulting in increased hazard of various attack; The DNSSEC (Domain Name System Security Extensions) alter DNS to add sustenance for cryptographically-signed receptions. Many extensions have been developed to ensure safe zone transfers as well.

Also, many domain names can be used to cause spoofing effects. Eg.-paypal.com and paypa1.com are two different names, but still users may be sometimes unable to distinguish them in a graphical user interface depending upon the typeface chosen by the user. In many of the font styles, the letter ‘l’ and the numeral ‘1’ look pretty much similar or at times even identical. This form of deception is often acute in systems that endorse internationalized domain names, since many of the character codes in ISO 10646, may appear indistinguishable on typical computer screens. This vulnerability is often exploited by various forms of phishing.

Fig. 1: Data flow through the DNS & the vulnerable points

D.DNSSEC a solution to these vulnerability

DNSSEC provides origin authenticity, data integrity, and secure denial of existence by using public-key cryptography.

1. Origin authenticity:- Resolvers can verify that data has originated from authoritative sources.

2. Data integrity: - Can also verify that responses are not modified in-flight

3. Secure denial of existence:- When there is no data for a query, authoritative servers can provide a response that proves no data exists.

METHODS IN DNSSEC

PUBLIC KEY CRYPTOGRAPHY

The problems of authentication and large network privacy protection were addressed theoretically in 1976 by Whitfield Diffie and Martin Hellman when they published their concepts for a method of exchanging secret messages without exchanging secret keys. The idea came to fruition in 1977 with the invention of the RSA Public Key Cryptosystem by Ronald Rivest, Adi Shamir and Len Adleman, then professors at the Massachusetts Institute of Technology.

Rather than using the same key to both encrypt and decrypt the data, the RSA system uses a matched pair of encryption and decryption keys. Each key performs a one-way transformation upon the data. Each key is the inverse function of the other; what one does, only the other can undo.

The RSA public key is made publicly available by its

owner, while the RSA private key is kept secret. To send a private message, an author scrambles the message with the intended recipient's public key. Once so encrypted, the message can only be decoded with the recipient's private key.

Inversely, the user can also scramble data using their

private key; in other words - RSA keys work in either direction. This provides the basis for the "digital signature", for if the user can unscramble a message with someone's public key, the other user must have used their private key to scramble it in the first place. Since only the owner can utilize their own private key, the scrambled message becomes a kind of electronic signature - a document that nobody else can produce.[2]

Fig. 2: Solutions to DNS problem (DNSSEC)

In DNSSEC, what are the KSK and ZSK?

KSK stands for Key Signing key (a long term key) and ZSK stands for Zone Signing Key (a short term key). Given sufficient time and data, cryptographic keys can eventually be compromised. In the case of the asymmetric or public key cryptography used in DNSSEC this means an attacker determines, through brute force or other methods, the private half of the public-private key pair used to create the signatures attesting to the validity of DNS records. This allows him to defeat the protections afforded by DNSSEC. DNSSEC thwarts these compromise attempts by using a short term key – the zone signing key (ZSK) – to routinely compute signatures for The DNS records and a long term key – the key signing key (KSK) – to compute a signature on the ZSK to allow it to be validated. The ZSK is changed or rolled over frequently to make it difficult for the attacker to "guess" while the longer KSK is changed over a much longer time period (current best practices place this on the order of a year). Since the KSK signs the ZSK and the ZSK signs the DNS records, only the KSK is required to validate a DNS record in the zone. It is a sample of the KSK, in the form of a Delegation Signer (DS) record that is passed up to the "parent" zone. The parent zone (e.g. the root) signs the DS record of the child (e.g., .org) with their own ZSK that is signed by their own KSK.

This means that if DNSSEC is fully adopted the KSK for the root zone would be part of the validation chain for every DNSSEC validated domain name (or yet to be developed application).[3]

Chaining Through The DNS

Starting with one or more trusted keys for any zone, it should be possible to retrieve signed keys for that zone's subzones which have a key. A secure sub-zone is indicated by a KEY RR with non-null key information appearing with the NS RRs in the sub-zone and which may also be present in the parent. These make it possible to descend within the tree of zones.

Chaining Through KEYs

In general, some RRset that you wish to validate in the

secure DNS will be signed by one or more SIG RRs. Each

of these SIG RRs has a signer under whose name is stored

the public KEY to use in authenticating the SIG. Each of

those KEYs will, generally, also be signed with a SIG. And

those SIGs will have signer names also referring to KEYs.

And so on. As a result, authentication leads to chains of

alternating SIG and KEY RRs with the first SIG signing the

original data whose authenticity is to be shown and the final

KEY being some trusted key statically configured at the

resolver performing the authentication. In testing such a

chain, the validity periods of the SIGs encountered must be

intersected to determine the validity period of the

authentication of the data, a purely algorithmic process. In

addition, the validation of each SIG over the data with

reference to a KEY must meet the objective cryptographic

test implied by the cryptographic algorithm used (although

even here the resolver may have policies as to trusted

algorithms and key lengths). Finally, the judgment that a

SIG with a particular signer name can authenticate data

(possibly a KEY RRset) with a particular owner name, is

primarily a policy question. Ultimately, this is a policy

local to the resolver and any clients that depend on that

resolver's decisions. It is, however, recommended, that the

policy below be adopted:

Let A < B mean that A is a shorter domain name than B

formed by dropping one or more whole labels from the left

end of B, i.e., A is a direct or indirect super domain of B.

Let A = B mean that A and B are the same domain name

(i.e., are identical after letter case canonicalization). Let A

> B mean that A is a longer domain name than B formed by

adding one or more whole labels on the left end of B, i.e., A

is a direct or indirect sub domain of B

Let Static be the owner names of the set of staticly

configured trusted keys at a resolver.

Then Signer is a valid signer name for a SIG authenticating

an RRset (possibly a KEY RRset) with owner name Owner

at the resolver if any of the following three rules apply:

Owner > or = Signer (except that if Signer is root,

Owner must be root or a top level domain name). That is, Owner is the same as or a subdomain of Signer.

( Owner < Signer ) and ( Signer > or = some Static ).

That is, Owner is a super domain of Signer and Signer is statically configured or a subdomain of a statically configured key.

(3) Signer = some Static. That is, the signer is exactly some

statically configured key.

Rule 1 is the rule for descending the DNS tree and includes a special prohibition on the root zone key due to the restriction that the root zone be only one label deep. This is the most fundamental rule.

Rule 2 is the rule for ascending the DNS tree from one or more statically configured keys. Rule 2 has no effect if only root zone keys are statically configured.

Rule 3 is a rule permitting direct cross certification. Rule 3 has no effect if only root zone keys are statically configured[4].

Chain of Trust Verification

1. Summary:-

Data in zone can be trusted if signed by a Zone-Signing-Key

• Zone-Signing-Keys can be trusted if signed by a Key-Signing-Key

• Key-Signing-Key can be trusted if pointed to by trusted DS record

• DS record can be trusted – if signed by the parents Zone-Signing-Key or – DS or DNSKEY records can be trusted if exchanged out of-band and locally stored (Secure entry point).

A LATEST EXAMPLE of DNSSEC implementation

Google public DNS now supports DNSSEC validation

Launched Google Public DNS three years ago to help make the Internet faster and more secure. Now, they have taken a major step towards this security goal: they now fully support DNSSEC (Domain Name System Security Extensions) validation on the Google Public DNS resolvers. Previously, they accepted and forwarded DNSSEC-formatted messages but did not perform validation. With this new security feature, Google can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.

Despite its Google’s critical role in Internet applications, the lack of security protection for DNS up to this point meant that a significantly large portion of today’s Internet attacks target the name resolution process, attempting to return the IP addresses of malicious websites to DNS queries. Probably the most common DNS attack is DNS cache poisoning, which tries to "pollute" the cache of DNS resolvers (such as Google Public DNS or those provided by most ISPs) by injecting spoofed responses to upstream DNS queries.

Currently Google Public DNS is serving more than 130 billion DNS queries on average (peaking at 150 billion) from more than 70 million unique IP addresses each day. However, only 7% of queries from the client side are DNSSEC-enabled (about 3% requesting validation and 4% requesting DNSSEC data but no validation) and about 1% of DNS responses from the name server side are signed. Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment.

Today, about 1/3 of top-level domains have been signed, but most second-level domains remain unsigned. We encourage all involved parties to push DNSSEC deployment and further protect Internet users from DNS-based network intrusions [5]

Conclusion

There has been a lots of information shared regarding the DNSSEC and how it will be effective in preventing certain types of DNS-related attacks, for ex-, DNS cache poisoning, that are prevalent on the Internet. This paper may assist networking staff in deploying DNSSEC more seamlessly in their network. We hope that the info contained in this document will leads to better management of resource and helps to develop new mechanisms to avoid information leakage and efficient use of network resources..

Acknowledgment

We would like to thanks Mr.Arpit sir for their valuable suggestions and support. Our very special thanks are to KIIT management Dr. Harsh Vardhan Kamrah and Ms. Neelima Kamrah for providing their constant encouragement, support and environment that was conducive for this work.