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.

When queries are initiated from security aware resolvers, it is strongly encouraged that the resolver set the CD flag. With the CD flag set in the query, security aware servers can send the Pending data. Sending the Pending data can be carrying two things. It release up server resources and minimizes the response time for handling queries and it allows a resolver to apply its rules on Pending data, and it’s independent of servers. If the answer to the query is previously Authenticated data on the server, the server sets the authentic data flag (AD) to specify to the resolver and that the essential checks have already been done. At this time the resolver may not need to do any security verification checks.

Public Key Retrieval:

In one of two ways the resolvers can get public key of zones. Resolvers may utilize the DNS to process the query for the public key or resolvers can be statically configured with the key. Regardless of the method used, problems are present with both public key and key. In this case the keys are obtained through the DNS, the key arises a trusting issue. In organizing the trusted retrieved key it must be signed and the signature is consistent. The public key of the signing authority must also be obtained, be signed, and be found reliable and so on by provided that the assurance that the signature on the key is consistent. The key to ending this recursive chain of events is to organize the resolver with the public key. And that public key is confirms the signed keys. In other words, a trusted zone key can be used as a primary point for verifying all keys initiate. A possible set of trusted public keys with which a secure zone can be statically arranged and these are called as the root zones.

The static design of a resolver with the public keys from several dissimilar zones has one benefit. In this the compromise of one of the zone’s private key does not result in the compromise of the keys for all the further zones. For many different zones is that it does not balance well is the main disadvantage of statically configuring each resolver with keys. If we are using one key for one zone it must be altered, then all the resolvers must be configured to replicate this alteration.

Literature review

DNS Definition:

DNS is said to be protocols that include TCP/IP. It is standard for industries using Microsoft Windows Server2003. DNS consists of two software aspects such as DNS client and DNS server, it works as service applications. Numeric IP addresses are recognized by resources of network, Network users find very tough to memorize IP addresses. DNS data base include records where alphanumeric names are enhanced for network resources by a user and get IP address for communication purpose. For that reason DNS is a device which operates as a mnemonic, creating network resources to the network users in simple way to remember.

DNS protocol is used by Windows Server 2003 DNS Server as well as Client services which includes in TCP/IP protocol. In TCP/IP reference model application layer acquire a portion of DNS.

DNS is a database providing information to the internet operations among human readable (host names) and Internet Protocol (IP) address. The system plays a significant role in DNS conserving information and securing communication within DNS. Upcoming DNS could not avoid attackers from DNS messages. Basing on the host names the internet depends on right translation by which user’s access to IP addresses through DNS system. Refer to DNS, spoofing permits the attacker to manipulate the answers. If any changes manipulate by the attackers are easily propagated by internet. By using spoofing DNS tables the RSA security web page was hijacked, even fraud web pages are also produced by attackers to forward all the valid data to the RSA security main page but the attacker could not crack the DNS server of the company whereas the network over line the DNS server.

DNS executes load distribution within duplicated servers, For example companies like Akamai using DNS as web content sharing, henceforth DNS provides all over database working as Public Key Infrastructure (PKI) which enables to access e-commerce applications.

Securing DNS:

The main source for securing DNS was authentication of data and protecting integrity. When communication needs for private channels, DNS interface IP security with chosen candidate where as the information present in the database is used apparently to public. Securing DNS depends on Public key cryptography; it is mostly oriented on symmetric cryptographic techniques. Now currently we have many secure services which have not been applied previously and kept impractical.

Enabling Secure On-Line DNS Dynamic Update:

DNS is the method for remembering host names and IP addresses. For extending security DNS has been placed in the Internet Engineering Task Force (IETF) running a set to maintain authentication. There are two conditions in the current DNSSEC standards in tackling DNS dynamic updates: The Zone security key provides online storage, developing a particular point for attackers both inside as well as outside. DNS server administrators and zone security managers are segregated by DNSSEC. Threshold cryptography is relying on the design for DNS security, the principle is used to remain for the role separation without placing a distinct of attack. Practically it reveals that ,the signature with total time, our design include tiny performance as penalty while using MD5/RSA signatures but it is important when applying DSA signatures. In critical zones we need high level security to design efficiently like .com zone.

We have to confirm whether we are talking to correct machine or not, then we must encrypt IP packets, Firstly secure the Internet by securing DNS. According to John Gilmores’ DNS security mailing list:

Paul Vixie has introduced and released the test of BIND [Berkeley Internet Name Domain service] which consists of DNS Security support. Protection is provided by the DNS security against the spoofing of DNS records through parties than to who was entrusted. It affords a handy infrastructure for the publication of certificates or keys by any individual who desires to utilize other protocols.

DNS Security Extension (DNSSEC):

DNSSEC is anticipated in [RFC2535]. With the help of digital signatures DNSSEC presents Resource Record authentication. Here every region is ready by means of a private/public key pair. In the zone RRs was digitally signed by a private key. A SIG RR (signature RR) and Requested RRs are indulged in DNS query with response whereby it contains the requested RRs of the Digital signature. The public key zone is used to distribute KEY RRS and to check the signatures. The main security principle of DNSSEC is the role separation- it vary the roles from DNS zone manager through DNS server administrator. Role separation has one advantage, it facilitates to avoid power abuses [SBM99].In DNSSEC DNS zone manager is responsible for the security of a zone but not DNS server administrator. A DNS server is used to mix the digitally signed DNS information of the zone, it co-operates the secondary server. When you kept the private key in offline it does not affect the degree of declaration where the client receives DNS [RFC2535]. The update zone data is signed by zone manager when the zone data is simplified.

Securing The Domain Name System

Basically each application of internet depends on the Domain Name system but a critical role is placed for the DNS security. DNSSEC is the criteria to face security challenges where it underwent deployment. There is a key principle to deploy servers, public key learning and resolvers in DNSSEC level. DNS is a vital infrastructure module of the internet as it interprets simply to memorize internet such as web pages, mail servers and addresses like URLs into original network address named as IP addresses. Basing on the Global economy the DNS needs secure holding some practical steps by using technology. A group of security requirements mentioned as DNS Security Extensions (DNSSEC) which was planned by IETF and enhanced required protection by verification. DNSSEC organize DNS infrastructure handle throughout critical security operations. There are some impossible issues which are undertaken to generate in aspects of Consensus security and specification gaps and operational challenges. This editorial discuses the subject and provide some dimensions to resolve.

Cryptography

Cryptography is a portion of functional mathematics which contrasts with transforming messages into apparently useless form and turn back to its initial state. Digital signatures use cryptography to create and verify the messages. It employs a public key cryptography which practices an algorithm by applying two mathematically related keys. One of the two keys is utilized for innovating digital signature or modifying the data into apparently inexplicable form. Another key is used for validating the digital signature and transfer it back to its normal (initial form). Asymmetrical cryptosystem is the expression used to correspond combined merging of computer equipment and software utilization.

The public key must be generously obtainable or shared among the public, as if it has possibility to verify signers digital signatures by a group of people at a time. Thus public key must be posted in any on-line warehouse or directory for easy access. It is infeasible to have a private key from the acquaintance of public key even though they are mathematically related. This is done if the asymmetric cryptosystem is planned and executed safely. Irreversibility can be termed as a situation in which, people may identify the public key of a signer and verify the signatures by that signer. But they can’t determine the signer’s private key to counterfeit digital signatures.

Cryptographic Technology

Cryptography influence is on Federal government both inside and outside. Powerful cryptography develops the security to the information which they work on the system. By using cryptography, Public key Infrastructure (PKI) and e-authentication IT users secure the applications in the market position. The work concern with addresses topics are secret, advanced authentication systems, public cryptographic techniques, cryptographic protocols and interfaces, smart tokens, biometrics, public key management, security architectures and cryptographic key escrowing. Presently Home land Security Presidential Directive 12 (HSPD-12) is running. For instance some influence fallen on the Federal employee identity by occurring certain changes, when government services are in online the users possess certain identity and privacy and some technical phases of passports are subjected to U.S citizens.

CSD works mutually with many international and national agencies and taken standard steps to maintain secure with interoperable security measures. Federal agency collaborators comprise of Department of state, Department of Energy, National Security Agency and Communications Security Establishment of Canada. Since some standards maintain for national and international standards which includes the International Organization for Standardization (ISO), the American Standards Committee(ASC) X9 (financial industry standards), the Internet Engineering Task Force (IETF) and the Institute of Electrical and Electronic Engineers (IEEE). Few industrial collaborators incorporate Certicom, Hewlett Packard, NTRU, RSA Security, Spyrus, nBC5 Technologies, Entrust Technologies, Pitney Bowers and Wells Fargo.

Cryptographic Applications & Infrastructures

Creating security services application developers rely on security protocols utilizing cryptography. In turn these protocols depend on cryptographic infrastructures like Kerberos or PKI to access and share cryptographic keys. The Group of Security Technology promotes and maintains standards, trail modes and giving guidelines for these blocks in association with organizations in international standards, Federal agencies and product developers. The Security Technology Group is a key role in the U.S. Federal Government’s PKI organizes activities.

High Level API For Crypto-Functions

Public Key Infrastructure team has established a high level -Advanced Programming Interface (API). It is used for public key oriented cryptographic services in related with collaborators from GAO, DOE, FDIC and Treasury FMS. The main object was to ensure simple interface for PKI – cryptographic services that conceal the difficulty of public key cryptography which facilitates PKI applications. API denotes functions concern with digital signature and encryption and provides two processes of operations- one is for buffer and another include file operation. Additionally a parser function is précised as Cryptographic message syntax (CMS). The PKI team has oriented some implementations of API forming a thin glue layer which maps on high level to an essential product API. PKI allows financial management system by utilizing reference implementation as uttered by one agency.

Cryptographic Algorithm Object Registration

Cryptographic algorithm objects possess a branch named as CSOR

Nist Algorithms OBJECT IDENTIFIER ::={ csor nistAlgorithm (4)}

The NIST-accepted cryptographic algorithms are merely listed by the CSOR. The CSOR only registers only NIST-accepted cryptographic algorithms. Whereby the algorithm allotted object identifiers previously, latest OIDs are not allotted. Turn the page that is preferred OIDs for these algorithms.

ASN.1 Modules

The objects of Cryptographic algorithm are referred with other ASN.1 kinds frequently. In fact, OIDs proposed the Algorithm of ASN.1 kind may be linked by classifications of parameters. Data is enclosed in the module of ASN.1.To recognize the various editions of ASN.1 constructs, ASN.1 module may be allocated OIDs . FOR an ASN.1 element, a sub arc is provided by the CSOR algorithm arc. A particular module is listed for supporting AES project.

CsorModules OBJECT IDENTIFIER ::={ nistAlgorithm modules (0)}

AesModule1 OBJECT IDENTIFIER::= { csorModules aes (1) }

Secure Hash Algorithms Registered Objects

In order to sustain the operation of safe hash algorithms the subsequent objects are listed.

hashAlgs OBJECT IDENTIFIER ::= { nistAlgorithm 2 }

Secure Hash Algorithm object identifiers

id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 }

id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 }

id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 }

id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 }

DSA Registered Objects

The provided objects are recorded for maintaining the project of DSA signature. Note: As they are not mentioned in FIPS 186-3, DSA with SHA-384 and SHA-512 are detached.

sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }

DSA Algorithms

id-dsa-with-sha224 ::= { sigAlgs 1 }

id-dsa-with-sha256 ::= { sigAlgs 2 }

Cryptographic Project:

Hash function has a message which consists of binary data and generates condensed representation which is said to be message digest. Cryptographic functions are structured to impose security properties. Secure Hash Standard and Federal Information Processing Standard 180-2 is shown particular algorithms to work out on five cryptographic hash functions such as SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512. FIPS 180-2 was subjected in August, 2002, superseding FIPS 180-1.[12]

Secure DNS

DNS field focuses on current development in order to secure DNS they are updating by testing to install in various organizations. The following three different services are used to achieve the goal to secure.

 Data Origin Authentication

DNS is helpful to store the data signed by cryptographically which is afforded by Authentication.DNS contains both signatures and keys, comprise with the data it authenticates. Hence keys are applied for authenticating these signatures; like other DNS data they must be authenticated. Of course, this string consists of signatures and keys with locally trusted root, or else the statistics is entrusted at all. By using a number of trusted keys DNS aware clients will be secured.

In DNS information the keys are used to sign data as (“DNS zone”). To query the information keys are involved to assure individual servers. This architecture permits for “off line signing”, so that the servers involves in this does not influence on the data for security.

 Key Distribution

To maintain Data Origin Authentication, Secure DNS refers a mode of keys stored in DNS called as “KEY records”. Henceforth DNS is applicable as public key sharing mechanism (”Public Key Infrastructure”). PKI supports the public-key cryptographic operations need to Secure DNS itself, as well as for other protocols.

There are three chief drawbacks were there for implementation faces, Secure DNS has to prevail them in following aspects.

 It requires the signing key at server B to be “online”

When scheduling the queries signing operations are accessible. To secure DNS security, it compromise breaking into the servers.

 Cryptographic signing operations are slow

This output has two similar problems. Firstly, it is simple to overload a server by fervently questions, named as “Denial of Service” attack. Secondly, now days huge servers give response many thousand queries per second, this practice are not available in these days like cryptographic signing hardware.

 Vulnerability to Playback attacks

If a domain give negative answer it is recorded, as well as domain is added later. The existence of domain can be denied by using signed negative response. (Resolve by totaling challenge/response scheme for every DNS query, but DNS could not sustain today.)

Secure DNS faces resistance:

For DNS records DNSsec is architecture a layer of signed cryptographic, and IP address prompts a domain name, the user thinks in a wide way that he is correct in choosing an answer. The registrar market also pact among razor-thin margins mostly, so registrars are keen interested to figure out whether they were able to sense return-on-investment when they came out from DNSsec.

Cryptographic keys are added to DNS similarly the infrastructure also adds the costs– cryptographic functions possess additional storage, bandwidth, CPU-intensive and memory requirements to enhance the keys.

Few registrars converse of adding a “significant” add-on fee for DNSsec “expert services”, while others were building domain registration selecting from two services — a domain name and another one is “secure domain name”, the final costs more.

Internet Cryptography:

“The Internet does use cryptography? I just made an SSL connection to my bank” Many connections like Skype, SSL are used. “Because nobody cares, Cryptography is pointless, attackers are exploiting buffer overflows; they aren’t intercepting or forging packets.” “The Internet does use cryptography! I just made an SSL connection to my bank.”“It’s too easy to write Internet software that exchanges data without any cryptographic protection. Most Internet clients and servers don’t know how to make cryptographic connections.”

1. Cryptography can end sniffing attackers by scrambling valid packets.

2. It is often mentioned as defending from privacy because the attackers cannot analysis the twisted packets.

3. It can also secure reliability where attackers can not find out a twisted counterfeit.

4. To distribute secret keys cryptography requires genuine client and server pair.

5. Fewer requirements are there for Public key cryptography. Where as, every party has one public key and both parties can communicate securely if each party knows the public key of other party.

Symmetric cryptology: data authentication

 The problem

Hash functions lack a key

–MDC: Manipulation Detection Codes

hash functions by a secret key

–MAC: Message Authentication Codes

Advantages of public key cryptology

• decrease protection of information to secure the public key privacy
• Privacy without creating secret keys

–tremendously useful in an open environment

• Data authentication is devoid of shared secret keys: digital signature

–sender and receiver have individual capabilities

–Third party can determine dispute among sender and receiver

The First Cryptographic Hash Workshop is conducted in Gaithersburg; the workshop was planned in reaction of attack on NIST permitted Secure Hash Algorithm SHA-1. The main proposal to place workshop was converse about attack and analyzing the status comparing with other NIST approved hash algorithms. This conference is initiated about the issues related to SHA-256.

According to Dunkelman said, we can use current techniques to break 40 rounds of SHA-256, with some changes. Besides that we require new techniques and expecting high techniques on the horizon for coming years.

Rechberger proposed that wangs attack is not that much and able to apply SHA1 to SHA-256. It considers on the efficiency of SHA-256 attacks. Joux mentioned that recent attacks are not completely to SHA-256 but some analysts are pointing on SHA1 as a target. As for this attacks we need new, so he did not analyze that attack will be 40 rounds of SHA-256 as stated by Dunkelman. Kelsey acknowledged that there is no evidence if any complexities of SHA-2 s messages it may indulge either weaker or stronger to entail hash function than SHA-1.Jutla s technique for the SHA-1 message for expand SHA-256 can be utilized to give confidence.

Future Hash Functions

Basing on future hash functions the following are listed as below:

1. If we have to start AES competition, we must be attentive to have software encryption incorporating in our mind, but the algorithm needs actual assortment enough to go in hardware. Obviously hardware benefits when new hash algorithms are placed in a competition.

2. The problems come with SHA-1 or SHA-2; they are attached by raising the number of rounds. If performance is significant things go better.

3. We must cross beyond the confine area in the Merkle-Damgård production, as well as generic attacks are blocked.

4. Perhaps we need hash function with many states and the last state will differ from other states.

5. specialized functions are needed, since hash function is not the perfect function for digital signatures for HMAC, for instance, some people require everything through hash function while others analysis that a single hash function is not applicable for all applications. For instance, hash function is operated from signing message digest to create a digital signature.

6. Now the competition was started, designs were planned rather than current and for the coming year’s hash functions are enhanced and developed. So we have to wait for knowing better about the hash function in basic technology before starting the hash function process.

7. Cooperative competition was advised; therefore hash functions are selected and linked with best elements.

8. Probably security is must and verifiable, the security may not lean on more assumption rather rely on one. However, a provably secure hash function may be very inefficient in terms of performance.

9. Randomness could be initiated into protocols therefore we wont rely on the hash functions potency, but it is necessary for a hash function to run without randomness.

10. With regards to the output of hash function the legacy systems can be retrofitted with minimum output.

DNS Security Algorithm Numbers

For the purpose of the registration document alters from Standards Track RFC. Few algorithms are benefited but they are not useful for Standard Track RFC. For instance, an algorithm is supported by government and use cryptography which is not estimated to place on Standards track. Even though the registry was limited new algorithms are occasionally used. Few developers will impose on the standards of the RFCs that are present in the registry as to reflect the update standard level of every algorithm recorded.

Fortunately, the size of the registry is tiny than more of IETF registries, eventually some of the DNS members in the community is focused on registry completing. The IETF reconsider the entry basing on the requirements for the registry when it is half full. This evaluation has firm restrictions for expanding the registry size. Where there is no RFC the developers need to test the private-use values such as 253 and 254, the semantic of two values are not changed in the document.

DISA Certifies DNSsec IPv6:

DNS appliances are used to make simpler administration providing functional GUI interface. These appliances consist of Internet Protocol Address Management (IPAM) capabilities and functionally Dynamic Host Configuration Protocol (DHCP). These features are linked with DNS but not in organizations. DNSsec is added to the appliance is highly benefited.

According to Hughes “Deploying DNSsec on BIND directly without the aid of an appliance requires very rare and expensive expertise in cryptography, digital signatures and key management, in addition to use of Perl scripts and text editors,” and also he said “Even if you can find and afford an administrator that can manage this, they would be far more profitably used doing things other than managing DNS. No such expertise is required for a Solid DNS appliance administrator.”

Asymmetric Cryptographic Algorithms:

According to W.Diffe and M. Hellman the problems of large integers and discrete logarithms for components in groups with finite are projected. In modern information technology asymmetric cryptographic algorithms are used to pursue a discrete logarithm for an elliptic curve on a finite field. Mainly the concept is imposed on different keys applying for data encryption and decoding. The keys are related with mathematical portion. With the help of public encryption key owners personal encoding key is encoded the message easily by others but to decrypt the message only owner can apply the personal key. Hence the new concept is introduced to solve the problem to enhance private keys to get large information from the networks. In this article the author proposed one more algorithm deciding a common key for both participants for data exchange and not to open secret information among them.

A protocol was introduced by Diffe-Hellman with Two participants as A and B whereas the data exchange choose a common simple finite field GF(p), where P is said to be a large prime number and they take a frequent generating element G for a multiplicative group of this field, both will select their own private keys as xA and xB, it calculates with an open key yA=gxA and yB=gxB respectively, the calculations are maintained in the field GF(p) as prime number p modulo, now replace open keys. Henceforth common key as K is calculated by the formula as below shown.

To find out the key, potential interceptor will solve one of the equations yA=gxA and yB=gxB with respect to xA or xB respectively. The solution of the equation of the form is yA=gxA is known as problem of discrete holding the logarithm and is classified as most difficult calculating problems. Thus, Diffie-Hellman cryptographic stability of the protocol is relied on impossibility to solve in a sufficient time, taking a simple finite field the problem of discrete is drawn the logarithm for a large prime number.

T. Elgamal has issued an algorithm of evaluation, an algorithm of asymmetric encryption and check of a digital signature is based on the stability and also on complexity of discrete taking the logarithm in a simple finte field. Numbers of cryptographic logirthms are used to solve the problems for the safety by monitoring the documents (digital signature), encryption and identification many more. Such algorithm is so called cryptographic algorithms of exponential type.

Security Considerations

The Document mentions about DNS resource records providing a format which is Utilized by security extensions of DNS and projecting an algorithm to a public key with the help of calculating key tag. As said below, security considerations does not initiate on resource records. Additionally [RFC 4033] and [RFC 4035] are used for records by security considerations.

The DNS record uses the key algorithm key, key tag and cryptographic digest focusing into DNSkey RR. The purpose of DNS record is to detect an existing DNSKEY RR, it is possible in theory to operate DNSKEY that equals to the DS fields for an attacker. Possibility of structuring a matching key relies on the use of digest algorithm. Currently refer SHA-1 as digest algorithm where the working locality entrusts on the public key structurally matching the algorithm, SHA-1 digest and key tag in the DNS record that it makes serious threat for an attack in this time which would be complicated problem. The key tag has efficiency to record DNSKEY resource but it is not particular to identify a single DNSKEY resource record. It is feasible having two different DNSKEYS with the same owner name, algorithm type and same key tag. In some conditions the wrong public key can select by DNSKEY RR which uses as a key tag to implement.

A peculiar portion in the standards of DNS security has described a decade ago, it is decided when more people in IETF says “no standard that requires the use of Jim Bidzos’s

Monopoly crypto algorithm is ever going to be approved on my watch”. Jim as CEO of RSA Data Security, he pissed off so many people and utmost hated person in crypto. (NSA export manages not to place the crypto in your product; the way he licensed is second by Bidzo’s patent, The IESG prejudice has not focused whether he has free license from RSA to utilize DNS with algorithm because the patent expires in three years besides we got permission for export and it implements basing on the working code. Remade the servers and records with contrast algorithm by dealt the problems which may take another 5 -10 yrs. (“officially mandatory” algorithm) [18]

Cryptography In DNS Curve

The DNS Curve project secures DNS packets with link-level public-key. This article suggests about DNSCurve by applying the cryptographic tools. Currently elliptic curve cryptography is running rather than RSA which is an old concept. Basically RSA was bringing forth in 1977 whereas elliptic-curve cryptography was start up in 1985. More so over elliptic-curve cryptography was strong enough than RSA. In 1970’s RSA efficiency security level was reduced radically by the linear sieve, in 1980’s ECM as well as quadratic sieve and in 1990’s number –field sieve is present. Comparing with this, unusual elliptical curves include special algebraic structures were faced adjacent to some attacks and forecast is increased in attackers with the help of computer power, but distinct elliptical curves acquire more computer power has a break as they need twenty years ago.

In late 1990’s elliptic-curve cryptography have standardized IEEE P1363, it consists of security criteria with rigid list for elliptic curves. IEEE P1363 is used by NIST choose fifteen particular elliptic curves at five various security levels. In 2005 N