Security system for DNS using cryptography

1. Introduction

Scope Of The Project

The domain name system has become a serious equipped part of the

Internet communications, though it doesn’t contain secured mechanism to guarantee data integration or verification. Extensions to DNS provides services to security awares resolves are applications through the Cryptographic digital signatures which are included as resource records and also provides storage of valid public keys in the DNS which support general public key distribution services and also DNS security. The stored keys make security aware resolvers to know authenticating key of zone and these keys can be used to maintain other protocols and extensions gives for the authenticating DNS protocol transactions also.

DNS provides security using the concepts of Digital signature and Asymmetric key cryptography. In this asymmetric key is send as a substitute of private key. DNS security uses message digest algorithm to compact message and PRNG (pseudo random number generator) algorithm in order to generate this public and private key. Signature which is formed by combining message with the private key using DSA Algorithm is send along with public key

To form a signature receiver makes use of the public key and DSA Algorithm. If the received message signature is matched then that message is decrypted and will be read or else it will be discarded.

Problem Statement

Authenticity is based on entity identification where the entity is genuine. In many network applications entity can be identified by name or addresses. In high level applications names are used for authentication as the address lists are difficult to create, to understand and also for maintaining

Assume if an entity wants to take off other entity identification, then it is enough to change mapping between low level address and its high level name which means that attacker can forge someone’s name by changing the address associated from his name to those name he wants to takeoff. If this happens an authenticator cannot differentiate between the correct and false entity.

2. Overview Of The DNS

In order to connect a system which supports IP then the initiating host should know the IP address before only which is a 32-bit number and it represents the system location in a network and this address is divided into four octets which are separated by a dot character(“.”) and each octet is represented by a decimal number. Though it is easier to remember this four decimal numbers than thirty two 1’s and 0’s,a limit as to how many IP addresses can be remembered by a person without any directory support. Directory basically assigns hosts names to IP addresses .

The Stanford Research Institute’s Network Information Center (SRI-NIC) became the responsible authority for maintaining unique host names for the Internet. The SRI-NIC maintained a single file, called hosts.txt, and sites would continuously update SRI-NIC with their host name to IP address mappings to add to, delete from, or change in the file. As the Internet grew rapidly, managing the files become difficult and also the hostnames required to be unique allover the worldwide internet. As the internet size increases the guarantee the uniqueness of host name became impossible. The need for hierarchical naming structure and distributed management of host names lead for the creation of a new networking protocol that was flexible enough for use on a global scale [ALIU].

Internet distributed database is created and this maps the computer system’s names with their respective numerical IP network address. This Internet lookup facility is the DNS. Delegation of authority is important to the distributed database. No single organization is responsible for host name to IP address mappings for longer, but somewhat those sites that are responsible for maintaining host names for their organization(s) can gain that control again.

Fundamentals Of DNS

The DNS not only supports host name to network address resolution, known as forward resolution, but also network address to host name resolution, known as inverse resolution. This ability of mapping human memorable system names into computer network numerical addresses, its dispersed nature, and its strength, the DNS has become a vital component of the Internet. Without DNS, the only way to reach other computers on the Internet is to use the numerical network address. Connecting a distant computer system using IP addresses is not much user-friendly illustration of a system’s location on the Internet and thus the DNS is heavily relied upon to get back an IP address by referencing just a computer system’s Fully Qualified Domain Name (FQDN). A FQDN is mainly a DNS host name which represents where to decide this host name within the DNS hierarchy.

Related Works

The Domain Name Space

The DNS is a hierarchical tree structure. Its root node is known as the root domain. A label in a DNS name directly corresponds with a node in the DNS tree structure. A label is an alphanumeric string that exclusively identifies that node from its brothers. Dot notation (“.”) is used to connect labels together and labels are written from left to right. A DNS name that contains several labels represents its path along the tree to the root. Only one zero length labels are accepted and reserved for the root of the tree. This is referred to as the root zone. As the length of the root label is zero, all FQDNs end in a dot [RFC 1034].

As a tree is traversed in an rising manner (i.e., from the leaf nodes to the root), the nodes become increasingly less specific (i.e., the leftmost label is most specific and the right most label is least specific). Typically in an FQDN, the host name is the left most label , while the next label to the right is the local domain to which the host belongs. The local domain can be a sub domain of another domain. The name of the parent domain is then the next label to the right of the sub domain (i.e., local domain) name label, and so on, till the root of the tree is reached

 When the DNS is used to record an IP address back into a host name (i.e., inverse resolution), makes use of the same scheme of labels from left to right (i.e., most specific to least specific) when writing the IP address. This is in contrast to the typical demonstration of an IP address whose dotted decimal notation from left to right is least specific to most specific. For this, IP addresses in the DNS are usually represented in reverse order. IP addresses comes under a special DNS top level domain (TLD), known as the in-addr.arpa domain. By doing this, using IP addresses to find DNS host names are handled just like DNS host name lookups to find IP addresses.

DNS Components

The DNS has three major components, the database, the server, and the client [RFC 1034]. The database is a distributed database and comprises of the Domain Name Space, which is basically the DNS tree, and the Resource Records (RRs) that define the domain names within the Domain Name Space. The server is generally referred to as a name server that is usually responsible for organizing some portion of the Domain Name Space and also for supporting clients in finding information within the DNS tree. Name servers are authoritative for the domains in which they are responsible. They serve as a delegation point to identify other name servers that have authority over sub domains within a given domain.

The zone information is the RR data found on the name server that makes up a domain Thus, name servers have zones of authority. A single zone can either be a forward zone (i.e., zone information that pertains to a given domain) or an inverse zone (i.e., zone information that maps IP addresses into DNS host names). DNS allows more than one name server per zone, but only one name server can be the primary server for the zone. Changes to the data for a zone takes place in Primary servers. Copies of the primary server’s database are maintained in all other name servers for a zone. These servers are called as secondary servers. .

A DNS RR has 6 fields: NAME, TYPE, CLASS, TTL, RD Length, and RDATA. The NAME field holds the DNS name, to which the RR belongs. The TYPE field is the TYPE of RR. This field is necessary as it is common for a DNS name to have more than one type of RR. The more common types of RR are found in

The CLASS in this case is “IN” and it stands for Internet. Other classes also exist but are omitted for brevity. The TTL is the time, in seconds, that a name server can cache a RR. A zero time to live means that a server is not to cache the RR. RD Length is the length of the RDATA field in octets. The RDATA field is the resource data field which is defined for each TYPE of RR uniquely, but in common it can be considered as the value into which the entity specified in the NAME field maps. The NAME field can be thought of as the subject of a query, although this is not always the case, in RDATA field the answer is the contained data (even though the entire RR is returned in a DNS response) [RFC 1035].

RRs are grouped into resources records sets (RRSets). RRSets contain 0 or more RRs [RFC 2136] that have the same DNS name, class, and type, but (i.e., RDATA) different data. If the name, type, class and data are the same, for two or more records then there exists a duplicate record for the same DNS name. Name servers should suppress duplicate records [RFC 2181]. The Figure 3 shows an example of an RRSet.

The client component of the DNS typically contains software routines, known as functions that are responsible for requesting information from the Domain Name Space on behalf of an application. These functions are bundled collectively into a software library, commonly referred as the resolver library. For this reason, clients are often called resolvers and resolver documentation functions are dependable for sending a query to a name server requesting information concerning a DNS name and returning the answer to the query back to the requestor.

DNS Transactions

DNS transactions occur continuously across the Internet. DNS zone transfers and DNS queries/responses are the two most common transactions. A DNS zone transfer occurs when the secondary server updates its copy of a zone for which it is authoritative. The secondary server makes use of information it has on the zone, namely the serial number, and checks to see if the primary server has a more recent version. If it does, the secondary server retrieves a new copy of the zone.

A DNS query is answered by a DNS response. Resolvers use a finite list of name servers, usually not more than three, to find out where to send queries. If the first name server in the list is available to answer the query, than the others in the list are never consulted. If it is unavailable, each name server in the list is consulted until a name server that can return an answer to the query found. The name server that receives a query from a client can act on behalf of the client to resolve the query. Then the name server can inquiry other name servers one at a time, with each server consulted being most likely closer to the answer. The name server that has the answer sends a response back to the original name server, which then can store the response and send the answer back to the client. Once an answer is cached, a DNS server can use the cached information when responding to consequent queries for the same DNS information. Caching makes the DNS more capable, especially when under heavy load. This efficiency gain has its tradeoffs; the most important is in security.

Proposed System

Taking the above existing system into concern the best solution is using Pseudo Random Number Generator for generating Key Pair in a quick and more secured manner. We use MD5 (or) SHA-1 for producing Message Digest and Compressing the message. Signature is created using Private Key and Message Digest that is transmitted along with the Public Key. The transfer of the packets from each System to System is shown using Graphical User Interface (GUI). Each time the System get the message, it verifies the IPAddress of the sender and if match is not found then discards it. For verification, the Destination System generates Signature using Public Key and DSA Algorithm and verifies it with received one. If it matches it Decrypts else it discards.

The Following functions avoid the pitfalls of the existing system.

• Fast and efficient work
• Ease of access to system
• Manual effort is reduced

3. DNSSEC

In 1994, the IETF formed a working group to provide the security issues in the DNS protocol are surrounding the DNS. And these extensions are referred commonly to as DNSSEC extensions. These security enhancements to the protocol are designed to be interoperable with non-security aware implementations of DNS. The IETF achieved this by using the RR construct in the DNS that was knowingly designed to be extensible. The WG defined a new set of RRs to hold the security information that provides strong security to DNS zones wishing to implement DNSSEC. These new RR types are used in combination with existing types of Resource Records. This allows answers to queries for DNS security information belonging to a zone that is protected by DNSSEC to be supported through non-security aware DNS servers.

In order to gain widespread approval, the IETF DNSSEC WG acknowledged that DNSSEC must provide backwards compatibly and must have the capability to co-exist with non-secure DNS implementations. This allows for sites to move around to DNSSEC when ready and allows less difficulty when upgrading. This also means that client side software that are not DNSSEC aware can still correctly process RRSets received from a DNSSEC server [CHAR].

In March of 1997, the Internet Architecture Board (IAB) met in order to discuss the development of Internet security architecture. Existing security mechanisms and those that are under development, but have not yet become values, that can play a part in the security architecture were identified in this meeting.. They even found the areas where adequate security cannot be achieved using existing security tools. Core security necessities for the Internet security structural design was recognized in this meeting. DNSSEC is one of the security protocols recognized as core and the protection that it provides false cache information against injection information is important to the core security requirements of the Internet [RFC 2316].

DNSSEC Objectives:

A basic principle of the DNS is that it is a public service. It requires accurate and steady responses to queries, but the data considered as public data. As such, it is existed in integrity and for validation, but not for access control and privacy. Thus, the objectives of DNSSEC are to provide authentication and integrity to the DNS. Authentication and integrity of information held within DNS zones is generated through the use of public key technology and provided through the use of cryptographic signatures. Security aware servers, resolvers, and applications can then take advantage of this technology to guarantee that the information obtained from a security aware DNS server is true and has not been changed.

Although the DNSSEC WG chose not to provide confidentiality to DNS connections, they did not remove the ability to provide support for confidentiality. Other applications outside of the DNS may choose to use the public keys contained within the DNS to provide confidentiality. Thus the DNS, in real meaning, can become a worldwide public key distribution mechanism. Issues such as cryptographic export are not, and may never be, solved worldwide; however, the DNS provides mechanisms to have multiple keys, each from a different cryptographic algorithm for a given DNS name, as a means to help improve this problem.

Performance Considerations:

Performance issues are a concern for the security extensions to the DNS protocol and several aspects in the design of DNSSEC are besieged to avoid the overhead linked with processing the extensions. For example, formulating another query that asks for the signature belonging to the RRSet just retrieved is not necessarily the most efficient way to regain a signature for the RRSet. This additional query is avoided whenever possible by allowing information retrieved from secured zones to be accompanied by the signature(s) and key(s) that authenticate the information.

DNSSEC Scope:

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.

Key Distribution:

The key distribution service allows for the recovery of the public key of a DNS name to confirm the authenticity of the DNS zone data, and it also provides a means through which any key linked with a DNS name can be used for purposes other than DNS. The public key distribution service supports several different types of keys and key algorithms.

Data Origin Authentication:

Data origin authentication is the heart of the design of DNSSEC. It mitigates such threats as cache poisoning and zone data compromise on a Domain Name System server. The Resource Record Sets within a zone are cryptographically signed and thereby giving a high level of assurance to resolvers and servers that the data just received can be trusted.

Digital signature technology which contains the encrypted hash of the RRSet that is a data in the RRSet, it is the cryptographic checksum is used by DNSSEC to sign DNS RRSet. The hash is signed (i.e., digitally encrypted) using a private key belonging to the designer of the information, known as the signer or the signing authority. The digital signature is checked by the receiver of the RRSet against the data received in the RRSet. This is done by first decrypting the digital signature using the public key of the signer to get the original hash of the data. Then using the same cryptographic checksum algorithm, the recipient computes its own hash on the RRset data and the results of the hash found in the digital signature are compared with the hash just computed. If the values of the two hash matches, then the data has consistency and the origin of the data is true [CHAR].

DNS Transaction And Request Authentication:

DNS requests and DNS message headers can be verified using DNS transaction and request confirmation. 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. Thus the assurance for both can be done in one step. Part of the information, signature produced from the concatenation of the query and response is returned in a response to a query from a security aware server. This allows a security aware resolver to perform any necessary verification concerning the transaction can be performed by the security aware resolver

Another use of transaction and request verification is for DNS Dynamic Updates. Without DNSSEC, DNS Dynamic Update does not provide a mechanism that prohibits any system with access to a DNS reliable server from updating zone information. In order to provide security for such modifications, Secure DNS Dynamic Update incorporates DNSSEC to give strong verification for systems allowed to dynamically manipulate DNS zone information on the primary server [RFC 2137].

DNSSEC Resource Records:

The IETF created several new DNS RRs to maintain the security capabilities provided by DNSSEC extensions. The RRs related to the DNS are the KEY RR, SIG RR, and the NXT RR. DNSSEC utilizes the KEY RR for storing cryptographic public keys, one public key per KEY RR. It is the KEY RR that is used for proof of a DNS RRSet’s signature. SIG RR contains the signature for a RRSet that is used to prove the authenticity and integrity of the information in the RRSet. The NXT RR is the nonexistent RR and is used to cryptographically assert the nonexistence of a RRSet. CERT RR is another RR that does not bring any additional security functions to the DNS, but is provided so that public key certificates can be kept within the DNS for use in applications outside of the DNS [RFC 2538]. In much the same way an application wishing to communicate with a distant IP host generates a query to resolve the host name, a security application wishing to make encryption with another entity, generates a CERT query to getback the entity’s public key certificate. For further explanation on KEY, SIG, and NXT RRs and their RDATA fields and flags not contained herein, please reference RFC 2535 and related documents.

KEY RR

KEYRR contains the key for a DNS name. Any type of query for a DNS name, found in a secured zone, results in a response that contains the answer to the query. The KEY RR linked with the DNS name can accompany this response. The KEYRR is used to validate the data by the resolver that generated the query without sending another query for the Key RR and there by reducing the queries required for a DNS name in a secured zone.

KEY RR is used by DNSSEC for storing cryptographic public keys; though, it is not a public key certificate. Instead, the CERT RR stores public key certificates. The key found in the RDATA section of the KEY RR belongs to the DNS name that is listed first in the KEY RR .The owner name can represent a zone, a host, a user, et al.

The Key RR contains information regarding the security characteristics of the key and it’s allowed usage for the given owner name. security information such as the public key, algorithm type, protocol type, and flags that specify such things whether the DNS name has a public key or not are provided by Key RR. The actual format of the public key found in the RDATA section of the KEY RR is determined by the public key algorithm. Many key algorithms are supported and are defined in RFC 2535 as RSA/MD5, Diffie-Hellman, and Digital Signature Algorithm (DSA), and the elliptic curve algorithm. Only DSA support is compulsory. The protocol octet is another field that indicates for which protocol the public key is valid. TLS, email, DNSSEC, and IPsec are some of the previously assigned protocols. As both the public key algorithm field and the protocol octet is an 8-bit field, theoretically up to 255 different algorithms and 255 different protocols can be used in combination with the public key.

Out of the sixteen bits used for setting various flags two bits are known as the type bits. All four combinations of the type bits show the usage of KEY RR. They are confidentiality, authentication, confidentiality and authentication, or none. The last one indicates a key does not exist for the DNS name. In this way, one can cryptographically states that the given owner name does not have a key though it is in a secure zone. Other two bits are used to identify three kinds of entities for which this key belongs, such as user, zone, or something that is not a zone. Indicating a host with these flags is actually done by using the flags to indicate that the Information of the DNS zone which is on the primary server. Thus a host is implied rather than specified by the flags.

SIG RR:

SIG RR is another resource record type. It contains a signature and also provides verification for an RRSet and the signature’s validity time. In a secure zone, an RRSet has one or more SIG RR associated with it and this scenario of having more than one SIG RR for a given RRSet arises if more than one cryptographic algorithm is used for signing the RRSet. Some sites may choose to do this for issues such as cryptographic export restrictions.

RDATA section of a SIG RR has a number of fields. In the signature field the signature is belonged to a specific RR. A “type covered” field is used to indicate the RRtype of the RRSet (NS, MX, PTR, etc.). The signer’s field contains the signer’s name which a resolver or server should know for verifying the signature. The SIG RR has an algorithm field and it is identical to that KEY RR. Since signatures have termination times, as do individual RRs, the SIG RR has numerous time fields.

The SIG RRs used for request authentication and transactions and for these are specially the target of a query, security attentive servers try to include in the response the SIG RRs needed to authenticate the Resource Record Set. Hence, a server will receive an answer to an RRSet and it is belonging to a secure zone that does not have the SIG RR. This situation can normally happen when a size limitation is exceeded due to the SIG RR or when a response comes from a non-security aware server. Under these circumstances, the security aware server is essential for another query especially requesting any missing SIG RRs required concluding the confirmation process.

NXT RR:

DNS provide the ability to cache negative responses. In the RRSet negative response does not exist for a query. DNSSEC provides signatures for these nonexistent RRSets, so these nonexistence RRSets in a zone can be authenticated. By using the NXT RR that is used to identify a variety of DNS names that are not available or for an existing DNS name a wide range of RR types that are unavailable.

For nonexistent DNS names two possibilities are exist. First one is that the DNS names don’t contain any RRs; it simply may not exist. The other one is that the RR type in the query does not exist, but the DNS name will be exists. And in this all the records are arranged in alphabetical order to handles the proof of non existence of a DNS name. This method is used for canonical order and is defined in RFC 2535. Then when a query is received for a nonexistent name, after the name in the query is sent back a NXT RR containing the DNS name of the next DNS RRSet occurring canonically or “alphabetically”. With the DNS name a NXT record is sent back and the RR types that the name does in fact has to handle a proof of nonexistence of a RR type for an accessible DNS name . When SIGRRs are generated for a zone the entire NXTRRs for a zone should be generated.

Within the DNS Security conscious DNS servers are the source of all security-related information. Three main functions of any primary DNS server are managing the caching of DNS information and managing authoritative zone information and respond to client queries. A primary DNS server has more responsibilities to each of these functions because of security conscious. In a zone’s master database file security aware server includes the addition of SIG, KEY, and NXT RRs for an Authoritative zone information management system. The RRSets is generated for the SIG RRs and these are belonging to a zone. For generating the SIG belongs to the zone we are using a private key and itself as these private keys of servers are mostly found in on-line, it is feasible that these keys could be compromised. In contrast, the zone’s private key is reserved off-line for the majority purposes, so its compromise is less likely and the power of the data is further certain and is retrieved occasionally to re-sign all the records found within the zone. Once the new SIG RRs are generated they are included with the rest of the information in the zone’s master file and whenever SIGRRs are generated these NXT RRs should also be generated on the server and is located into a zone’s master file.

At the server side on-line signing also occurred. For DNS queries the transactions and request authentication, the server preparing the reply and that reply must use its private key and that private key is for signing. Moderately the zone key since it is reserved off-line. In the other case in which a zone key is not used for signing is for transaction. For dynamic updates the request authentication is used. The private key of the host creating the request and that request must be used. In very rare cases as DNS queries and active update requests can occur, the signer’s private keys must be maintained on-line. The protection of these on-line private keys is of extreme significance; though these are protected ahead of the scope of the paper. RFC 2541 discusses the operational considerations of SIG RR and KEY.

A security aware server must properly control the caching of all security related RRs for doing a caching. The maintaining of a four cache states starts with the extra duty in caching of a security aware server starts. One state, which has a succeeding state in a non-security aware server, is “Bad”. When a bad reply is received the information contained in that is some way corrupt, and a non-security aware server throws away the reply message without caching it (and typically logs the event) in a non-security aware server. In much the same way, a security aware server can throw away a bad response, but in this case, a bad response means that the SIG RR verifications are failed on the data. Even still the RRSet in the response may look valid, and with the related signature fault of the data checks is a severe condition.

In the RRSet Authenticated, Pending and Insecure are the other three states. There is no available data to use to ensure the accurateness of the RRSet in Insecure state. It does not mean the data is bad, just that it cannot be authenticated. This usually occurs from non-secured zones for RRSets. The RRSet cached has been fully definite through the use of the SIG RRs and KEY RRs is called Authentication. The cached data is still in the course of being checked is called pending.

When to expire a cached RRSet another server task is caching. Once an RRSet is cached, a count down to zero from the original TTL is started and it is maintained for the cached record. The RRSet is separated from the cache once zero is reached. The cache has changed a slight for security aware servers. When a cached RRSet is expired the TTL could not be the only time to find out the cache. Two new times are now used in addition to the TTL and these finally decide when to expire the RRSet from the cache. The new times are used to find when the signature’s validity time period for the authenticated RRSet expires, rather than just when the RRSet should be expired. These original times are kept in the SIG RR and are known as the signature begins time and the signature end time. For security aware clients and server this information is distant more essential on which to base expiration since it is cryptographically declared. Since the signature end time seems have a link to the TTL, the TTL field cannot be removed due to the backward compatibility issues.

For expiring valid RRSets TTL aging is still integrated. If the TTL expires earlier to the signature end time, and the RRSet is decomposed when the TTL strikes zero, the TTL is decremented as normal. If the signature expiration time occurs previous to when the TTL expire, the TTL is familiar to the signature end time and then the normal countdown of the TTL is continued.

Both security aware and security unaware resolvers involve answering queries, when a client is responses to a query. In a secured zone the non security aware resolver produces a query and sends it to a security aware server for gaining the information. With either valid or timid data the security aware servers can respond. The checking disabled (CD) flag is set when a security aware server sends the pending data. The security aware server knows not to send Pending data since a resolver not participating in DNSSEC in no way sets the CD flag in a DNS query. The security unaware resolver processes the reply message as common, since sending insecure data is same as DNS without DNSSEC. The security unaware resolver ignores the additional security information till it receives the valid data and it gives the response as normal.