DNSSEC (A Protocol towards securing the Internet Infrastructure) - Printable Version +- Free Academic Seminars And Projects Reports (https://easyreport.in) +-- Forum: Seminars Topics And Discussions (https://easyreport.in/forumdisplay.php?fid=30) +--- Forum: Engineering Seminars Topics (https://easyreport.in/forumdisplay.php?fid=7) +---- Forum: Computer Science Seminar Topics (https://easyreport.in/forumdisplay.php?fid=12) +---- Thread: DNSSEC (A Protocol towards securing the Internet Infrastructure) (/showthread.php?tid=58542) |
DNSSEC (A Protocol towards securing the Internet Infrastructure) - Janaka - 10-04-2017 Seminar Report On DNSSEC (A Protocol towards securing the Internet Infrastructure) Submitted by SAHEER H In partial fulfillment of requirements of the award of Master of Technology (M-Tech) In Software engineering DEPARTMENT OF COMPUTER SCIENCE COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY COCHIN-682022Page 2 COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE COCHIN-682022 Certificate This is to certify that the seminar report entitled DNSSEC A Protocol towards securing the Internet Infrastructure submitted by Saheer H, in partial fulfillment of the requirements of the award of M-Tech Degree in Software Engineering, Cochin University of Science and Technology, is a bonafide record of the seminar presented by him during the academic year 2008-2009. Dr. Sumam Mary Idicula Dr. Paulose Jacob Course Coordinator Head of the Department Place: Cochin Date: 10-11-08 2Page 3 ACKNOWLEDGEMENT I express my deep sense of gratitude to D.r. K.Poulose Jacob, HOD, Department of Computer Science, CUSAT, for providing an opportunity to present this seminars. My profound gratitude to Dr. Sumam Mary Idicula for her valuable guidance and timely support she offered. I also express my sincere thanks to all other teaching staff especially, Mr.Santhosh Kumar and all non-teaching staff, for their generous help and guidance. I also express my friendly gratitude to my batch mates for their kind co-operation and good wishes. Finally, I thank the Almighty, without whose blessings nothing starts good or ends well. 3Page 4 ABSTRACT Unlike spam, worms, viruses, and phishing all of which confront end users directly infrastructure attacks occur outside their normal frame of reference and control. But attacks on the Domain Name System (DNS), an engine of the Internet infrastructure, appear to be increasing in length and severity, affecting DNS information associated with financial services institutions, Internet service providers, and major corporations in the travel, health, technology, and media/ entertainment sectors. Such attacks can result in, say, dropped or intercepted email messages or users unknowingly redirected to fraudulent sites where they inadvertently hand over personal information. The ultimate casualty in a serious infrastructure attack is public trust. The Internet technical community has responded to threats to the DNS infrastructure by developing the DNS Security Extensions (DNSSEC) protocol standard. DNSSEC-enabled systems run primarily in only a few early- adoption and experimental zones. DNSSEC introduces security at the infrastructure level through a hierarchy of cryptographic signatures attached to DNS records. In the context of DNSSEC, users are assured that the source of the data is verifiable as the stated source, and the mapping of a name to an IP address is accurate. DNSSEC - capable name servers also provide denial of- existence; that is, they tell a user that a name does not exist. 4Page 5 TABLE OF CONTENTS 1. INTRODUCTION -6- 2. DOMAIN NAME SYSTEM -7- 2.1. DNS HISTORY -7- 2.2. WHAT IS DNS? -9- 2.3. HOW DNS WORKS? -9- 3. DNSSEC -17- 3.1. WHAT IS DNSSEC? -17- 3.2. DNSSEC ADDITIONALS -18- 3.3. DNSSEC DEPLOYMENT STRATEGIES -22- 3.4. DNSSEC ISSUES -25- 4. CONCLUSION -26- REFERENCE -27- 5Page 6 1. INTRODUCTION Attacks on the Domain Name System, an engine of the internet infrastructure affect DNS information associated with ISPs, financial services institutions and other primary services. Such attacks can result in dropped or intercepted email messages or users unknowingly redirected to fraudulent sites. Ultimate causality in a serious infrastructure attack is public trust. The Internet technical community has responded to threats to the DNS infrastructure by developing the DNS Security Extensions (DNSSEC) protocol standard. DNSSEC introduces security at the infrastructure level through a hierarchy of cryptographic signatures attached to DNS records. In the context of DNSSEC, users are assured that the source of the data is verifiable as the stated source, and the mapping of a name to an IP address is accurate. 6Page 7 2. DOMAIN NAME SYSTEM (DNS) Domain Name System can be described as an Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they're easier to remember. The Internet however, is really based on IP addresses. Every time we use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. 2.1 DNS HISTORY The DNS was invented in 1983, shortly after TCP/IP was deployed. With the older system, each computer on the network retrieved a file called HOSTS from a computer at SRI (now SRI International). The HOSTS file mapped numerical addresses to names. A hosts file still exists on most modern operating systems, either by default or through configuration, and allows users to specify an IP address (eg. 208.77.188.166) to use for a hostname (eg. example.net) without checking DNS. Eg: in Windows XP/2000 the hosts file resides in /windows/system32/drivers/etc/ in Windows 9X/Me - the hosts file resides in /windows/ in linux - the hosts file resides in /etc Many of the so-called Web accelerators that are available as freeware or as part of commercial packages make use of the hosts file. The idea is that if you can resolve IP addresses on your own computer instead of waiting for a DNS server to do it, you can cut the time required to find a Web site. If you have a slow connection or if the servers are very busy, you might save a second or two off the connection time of your most used sites. Or on the rare occasion when 7Page 8 DNS servers are down, you might even be able to continue to use the Web. Perhaps the biggest use of the hosts file is to block sites that are regarded as undesirable or to block ads. This done by assigning the loopback IP 127.0.0.1 to an URL that you wish blocked. Thus an entry might be: 127.0.0.1 unwanted.com (without quotes). Any request for such an IP address just gets sent right back to your own computer. However, there are several drawbacks to using a hosts file. The most obvious is its size limitation. Only a small subset of all the registered Web addresses will be in a hosts file. This can be useful in speeding up your homepage and other pages that you visit regularly but many sites will still need the DNS server. Of course, many people visit only a relatively small number of sites on any regular basis and the fractional seconds saved each time may be attractive to them. Note that a hosts file that is much over 100 KB can actually slow up browsing in Windows XP unless the service "DNS Client" is set to manual start. (Managing services is discussed on another page.) In fact Windows XP SP2 is said to ignore the hosts file entirely if the DNS Client service is running. Another problem is that the numerical IP corresponding to a particular URL can change. This can cause unexpected "The page cannot be displayed" error messages and inability to connect to sites. Thus, it is necessary to make sure that the hosts file is kept up-to-date. The growth of networking required a more scalable system that recorded a change in a host's address in one place only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP Addresses. At the request of Jon Postel, Dr.Paul V. Mockapetris invented the Domain Name system in 1983 and wrote the first implementation. The original specifications appear in RFC 882 and RFC 883. In November 1987, the publication of RFC 1034 and RFC 1035 updated the DNS specification and made RFC 882 and RFC 883 obsolete. Several more-recent RFCs have proposed various extensions to the core DNS protocols. 8Page 9 2.2 WHAT IS DNS? The Domain Name System (abbreviated DNS) (Also referred as Domain Name Service or Domain Name Server) is an Internet directory service. DNS is how domain names are translated into IP addresses, and DNS also controls email delivery. If your computer cannot access DNS, your web browser will not be able to find web sites, and you will not be able to receive or send email. An often-used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, example.com translates to 208.77.188.166. ; howstuffworks.com translates to 70.42.251.42 ; cusat.ac.in translates to 210.212.233.40 Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite meaningful URLs and e-mail addresses without having to know how the machine will actually locate them. Domain Name System can be described as an Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they're easier to remember. The Internet however, is really based on IP addresses. Every time we use a domain name, therefore, a DNS service must translate the name into the corresponding IP address. 2.3 HOW DNS WORKS? The DNS system consists of three components: Domain Name Space and Resource Records (RRs) Name Servers Resolvers 9Page 10 Domain Name Space and Resource Records (RRs) The naming system on which DNS is based is a hierarchical and logical tree structure called the domain name space .i.e. The domain name space consists of a tree of domain names. Only one node or leaf in the tree has zero or more resource records, which hold information associated with the domain name. The tree sub-divides into zones beginning at the root zone. A DNS zone consists of a collection of connected nodes authoritatively served by an authoritative nameserver. (Note that a single nameserver can host several zones.) Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone. Figure 1 : Domain Name Space and Resource Records 10Page 11 Name Servers Name Servers contain information about the domain s tree structure. The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD). Resolvers Resolvers obtain information from name servers in response to queries from a client. The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address.A DNS query may be either a recursive query or a non-recursive query: A non-recursive query is one in which the DNS server may provide a partial answer to the query (or give an error). A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries. The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use of recursive service using bits in the query headers.Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can communicate only with a single name server. These simple resolvers rely on a recursive query to a recursive name server to perform the work of finding information for them. 11Page 12 Figure 2: Example DNS Tree At the top of the inverted tree structure is the root (see Figure 1). Below the root are the top- level domains (TLDs), which are divided into two primary categories: country code TLDs, the familiar .uk, .se, .jp, and so on; and generic TLDs (gTLDs), the familiar .com, .org, .net, and so on. A special TLD, .arpa, is reserved for infrastructure purposes. TLDs are further subdivided into subdomains: example.org, example.com, and so on.Further subdivision of domains occurs frequently, particularly in complex organizations, like corporations and universities. Indeed, many of us have email addresses that include the three-level name cs.nameofinstitution.edu or library.nameofinstitution.edu. Eg : cs.cusat.ac.in ; which is a 4 level domain In theory, this subdivision can go down 127 levels.But domain with more than 4 levels are rare. The process by which these subdivisions take place is called delegation. The DNS structure of domains and sub domains is typically expressed in one of two metaphors: leaf-and-node and parent-child. Here, we use the parent-child metaphor to focus on the hierarchical relationships and flow of information. In a Logical view DNS can be considered as series of records of various types that are stored in a hierarchical, distributed database for example, the A record type provides the IP address In an Administrative view DNS can be considered as a set of organizational relationships, 12Page 13 responsibilities, and authorities.These two views logical and administrative converge in the key concept of the zone, which is managed as an independent administrative entity. This entity is responsible for a zone file containing the subset of DNS data about that zone and the mapping of names to IP addresses and/or delegations (such as from parent to child or parent to children), along with other information. Operational Perspective From an operational perspective, DNS transactions consist of a series of queries and responses between two programs: resolvers and name servers. The resolver poses queries on behalf of a client and returns the desired information. The name server contains information about the names and IP addresses in its zone and responds to queries from resolvers. In practice, what appears to be a single transaction (such as tell me the IP address for this name) is more complicated (see Figure 3). The user s program, perhaps a Web browser or an email client, contacts a stub resolver containing a list of recursive or resolving name server addresses. The stub resolver contacts a local recursive or resolving name server that either knows which name server has the information or redirects the query up to a zone at the next level. If the parent zone does not have the information, or the IP address, the recursive name server begins a search at the top of the hierarchy, or the root, querying it and then querying down the tree through the successive zones and associated name servers until it obtains either the information or an error. Figure 3 : DNS Query and Response 13Page 14 This description of how the DNS operates is necessarily a highly abstracted view. In practice, there are multiple configurations to replicate and cache the information throughout the system. For example, a successful query rarely reaches the root. The answer is typically obtained from a caching name server lower down in the tree, perhaps at a user s Internet service provider. In practice The process of DNS Query involves, 1. An application that calls for a name resolution like Internet Explorer. 2. The DNS Client installed on the computer. 3. The local DNS server. 4. The various DNS servers on the Internet. A simple example of accessing a website on the Internet will explain the process the process of DNS query. 1. When a user types in a website address in Internet Explorer say wikepedia.org and clicks GO, Internet Explorer does not directly understand the domain name and wouldn t know where to go. Hence, picks up the website name wikepedia.org and pass it onto the DNS client [resolver] to resolve the IP Address of the website. 2. The DNS Client also known as the DNS Resolver will try to resolve the IP address from its local resources which includes the Name to Address mappings in the HOSTS file and its local DNS cache. Normally, most of the DNS clients are capable of caching the previous DNS query results. The DNS resolver will use these available local resources and if it can t find the IP Address will then query a DNS server that it knows to for the IP Address. 3. The DNS server will directly answer the query if it is the authoritative server for the particular domain (here wikepedia.org) else check its local cache of the previous queries. If it cannot find the IP Address, then it will query the DNS servers on the Internet. 14Page 15 The process it follows in contacting various DNS servers on the internet requires a bit of understanding of how it looks at the Domain name. For instance the website address wikepedia.org will be looked at by the DNS server as .org.wikepedia.ww NOTE: Make a note of the "." before org. The above indicates that . is the ROOT DOMAIN. org is Sub-domain for the ROOT Domain. wikepedia is a sub-domain for .org ww is either a node (no further sub-domains) or further a sub-domain for "wikepedia". 4. Now, the DNS Server will query one of the root servers requesting for a list of Authoritative servers for the .org domain. The Root server will respond with the list of servers addresses hosting the org domain. 5. The DNS server will pick one from the list and contact that server for a list of Authoritative servers for the wikepedia domain. The server will respond with the details of the Authoritative server for the wikepedia domain. 6. Now, that the DNS server knows the Authoritative server address for the wikepedia.org domain and hence will directly contact the server for the IP Address of the host ww which belongs to wikepedia.org (called as A Record). The Authoritative DNS server will then respond with the IP Address or a list of IP Address (if more than one server hosts the website wikepedia.org) for wikepedia.org. 7. This the DNS server then returns back to the DNS client which again passes it onto the DNS application which initially requested the IP Address information, Internet Explorer in this case. 15Page 16 8. The Application then knows where to go to fetch the website. How it fetches the correct page etc is being taken care by the HTTP protocol using host headers etc., That is how a DNS Query works in its simplest terms. In any of the above when we query for a non-existent domain or a domain or the server that hosts the domain is not available will return an error.The process of quering the Internet DNS servers is depicted in the Figure 4. Figure 4 : Query for wikepedia.org So in practice, as said earlier, a successful query rarely reaches the root. The answer is typically obtained from a caching name server lower down in the tree, perhaps at a user s Internet service provider. These caches can pose a potential vulnerability, since an attacker may be able to tamper with them by inserting false information in the DNS records, a strategy known as cache poisoning. DNSSEC is intended to detect such attacks, enabling users and applications to defend against their consequences. Cache poisoning is but one kind of threat to the DNS; others are explained in RFC 3833. Although threats vary, they share the characteristic that they exploit vulnerabilities in the DNS and result in responses that cannot or should not be trusted. 16Page 17 3. DNSSEC DNSSEC is not a security panacea. It is not a robust defense against all forms of attack against DNS servers and clients. DNSSEC is not an exercise in encryption of DNS data. 3.1. WHAT IS DNSSEC? DNSSEC introduces security at the infrastructure level through the definition of additional DNS Resource Records that can be used by DNS clients to validate the authenticity of a DNS response, the data integrity of the DNS response, and where the response indicates no such domain or resource type exists, this negative information can also be authenticated. In other words, if an attacker attempts to create a DNS response that has been altered from the original authentic response in some fashion, and the attacker then attempts to pass the response off as an authentic response, then a DNSSEC-aware DNS client should be able to detect the fact that the response has been altered and that the response does not correspond to the authoritative DNS information for that zone. In other words, DNSSEC is intended to protect DNS clients from forged DNS data. This protection does not eliminate the potential to inject false data into a DNS resolution transaction, but it adds additional information to DNS responses to allow a client to check that the response is authentic and complete. DNSSEC achieves this with a hierarchy of cryptographic signatures attached to DNS records. With DNSSEC, users are assured that the source of the data is verifiable as the stated source, and the mapping of a name to an IP address is accurate. With DNSSEC a zone administrator "digitally signs" a Resource Record Set (RRSet), and publishes this digital signature, along with the zone administrator's public key, in the DNS. In checking a DNS response, a DNSSEC client can retrieve the related RRset digital signature and then check this signature using the public key against the locally calculated hash value of the RRset, and then validate the zone administrator's public key against a hierarchical signature path that leads to a point of trust. If all these checks succeed than the client has some confidence that the DNS response was complete and authentic. 17Page 18 DNSSEC implies different actions for different roles. For a DNS zone administrator: DNSSEC is essentially the process of signing RRSets with a private key, publishing these signatures for each RRset in the zone file, and publishing the zone public key in the zone file. In addition the zone administrator has to get the zone's public key signed by the parent zone administrator. For a DNS client: DNSSEC is the ability to perform a number of additional checks on a DNS response that can result in greater trust in the authenticity and accuracy of the DNS response. For the DNS: DNSSEC essentially represents a number of additional Resource Records that hold digital signatures of DNS information, as well as key information. The specification for DNSSEC is available in RFC 1033, RFC 1034, RFC 1035. 3.2. DNSSEC Additionals DNSSEC defines four new DNS resource records (RRs), namely the 1. DNSKEY 2. RRSIG 3. NSEC 4. DS DNSSEC also calls for new information in the packet header. The information in the header used by DNSSEC indicates that the response to a query passed checks on the server side. 18Page 19 DNSKEY Every DNSSEC secured DNS zone has an associated private and public key pair, as generated by the zone's administrator. The private key remains the (closely guarded) secret of the zone administrator. The associated public key for the zone is published in the zone file in the form of a DNSKEY resource record. An example DNSKEY record for the zone example.com is as follows [from RFC4034]: example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3 Cbl+BBZH4b/0PY1kxkmvHjcZc8no kfzj31GajIQKY+5CptLr3buXA10h WqTkF7H6RfoRqXQeogmMHfpftf6z Mv1LyBUgia7za6ZEzOJBOztyvhjL 742iU/TpPSEDhm2SNKLijfUppn1U aNvv4w== ) The Time to Live (TTL) value is 1 day (86400 seconds). The Flags value is 256, indicating that this is a Zone Key. The protocol value is the constant value 3. The next field is the public key algorithm, and the value 5 indicates RSA/SHA1. The RR value is the Base64 encoding of the public key value. RRSIG A "Resource Record set" (RRset) is a collection of RRs in a DNS ZONE that share a common name, class and type. In DNSSEC RRsets are digitally signed by the zone administrator. This signature is generated by generating a hash of the RRset, then encrypting the hash using the zone administrator's private key. For a zone that contains SOA, NS, A, MX, DNSKEY resource records there are, minimally 5 distinct RRsets, and each RRSET would have its own RRSIG Resource Record. This implies that the granularity of DNSSEC signing is not that of an entire zone, but is aligned to a unit of a DNS query response. An example RRSIG record for the zone example.com is as follows [from RFC4034]: host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 ( 20030220173103 2642 example.com. 19Page 20 oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG J5D6fwFm8nN+6pBzeDQfsS3Ap3o= ) The first four fields specify the owner name, TTL, Class, and RR type (RRSIG). The next field is the Type Covered field, and the value of "A" indicates that this is a signing of the A RRs for "host.example.com". next field is the signing algorithm, and the value of 5 indicates that this is signed using RSA/SHA1. The value 3 is the number of Labels in the original owner name. The value 86400 in the RRSIG RDATA is the original TTL value for the covered A RRset. 20030322173103 and 20030220173103 are the expiration and inception dates, indicating that the RRset signature was created on 17:31:03 20/02/2003, and the signature expires at 17:31:03 22/03/2003. The key tag is 2642 and the signer's name is "example.com." The remainder of the RR value is the encrypted hash of the RRset. NSEC The DNSKEY and RRSIG records can be used to check the authenticity of a DNS response, where there is a DNS response, but where there is no authoritative data to return then authentication requires additional information. The NSEC RR can be considered as a "gap spanning record" for authentication purposes. The entire zone file is ordered in a canonical form, and then NSEC RRs are added to cover the "gap". If the zone contained the names "alpha" and "beta", then there would be a NSEC RR for alpha, and the RR value would be beta, indicating that there are no defined named that lie between "alpha" and "beta". In addition, the NSEC record defines the set of RR types for this domain name. Continuing the example, the NSEC record for "alpha", would have as a value field the enumeration of the RR types that are defined for "alpha". In response to a query, if the name does not exist in the zone file, or the RR type does not exist for the name in question, then the NSEC record is returned as authenticatable evidence that the name, or the RR type does not exist. 20Page 21 The reason for this form of spanning data, as distinct from a more generic response of "no such name", is that the latter form of response can be used in a replay attack, falsely claming that a does not exist, whereas the NSEC record explicitly informs the client of the "gap". An example NSEC record for the zone example.com is as follows [from RFC4034]: alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 ) The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry host.example.com. is the next authoritative name after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com. DS The perennial issue in public key cryptography is that of the means of validation of the public key. If an attacker manages to intercept all your traffic, signs responses using their own private key and represents their public key as that of the party you thought you were communicating with, then how are you to tell that the communication has been corrupted? In public key cryptography the conventional answer is to find other parties who are willing to attest as to the validity of a public key, and find yet more parties who are willing to attest as to the validity of the first group of attesters, and so on until you find a page link with a party that you trust. Assuming that trust is a transitive quantity (always a risky assumption of course), then you can construct a chain of trust from your trust point to the party whose public key you are attempting to validate. The issue of validation of the zone public key remains unaddressed with the first three Resource Record types. An attacker would simply need to supply the DNSKEY and RRSIG data to match the bogus RRset data in order to make the response look 'authentic'. So we are back to the same public key validation question - how can a client validate the DNSKEY record? The approach adopted by DNSSEC is to use a chain of trust within the hierarchical delegation structure of the DNS itself. Apart from the root zone, every DNS zone has a parent zone. The 21Page 22 Delegation Signer (DS) RR contains the hash of the public key of the child zone. This record is signed by the parent zone's private key with a matching RRSIG RR. To validate a zone's DNSKEY, the associated DS, RRSIG(DS) and DNSKEY of the parent zone is retrieved. The DS record is validated by using the DNSKEY to encrypt the RRSIG(DS) record, and then checking that the result matches the DS record. This is the zone public key, according to the zone's parent. This can be compared to the DNSKEY record of the zone in question. This relies on the parent zone key, and the question is how can this key be validated? The same process can be applied here. The process stops when the DNSSEC client encounters a "trusted" key. The ideal "trust key" would be the DNSKEY of the root zone, but in the absence of such a trust anchor each DNSSEC client has to configure their trust validation system with known trust points where there is no parent validation. An example DS record for the zone example.com is as follows [from RFC4034]: dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A 98631FAD1A292118 ) The first four text fields specify the name, TTL, Class, and RR type (DS). Value 60485 is the key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used to construct the digest, and the rest of the RDATA text is the digest in hexadecimal. 3.3. DNSEC DEPLOYMENT STRATEGIES Two dominant Deployment Strategies 1. a process that zone operators initiate for digitally signing their own zones by employing public-private key pairs 2. a chain of trust between parent and child that enables the system to eventually become trustworthy. A zone administrator who wishes to deploy DNSSEC first generates a key pair consisting of a public key and a private key. The public key is stored in a DNSKEY record, and the private key is stored safely. The private key is used to digitally sign the records, and the resulting digital signature is stored in an RRSIG record. Next, a zone operator must generate NSEC 22Page 23 records and, depending on the content of the zone, one or more DS records. This makes possible the response that no record exists. If the zone includes delegations, then a DS record must also be added in the parent zone for a given child. A zone that contains children must include DS records for the children. A zone that has signed its records and added the NSEC (and, if necessary, the DS) records may go into business as a self-signed DNSSEC-capable zone, also known as an island of security. This island contains signed records or is considered a signed zone but is also the child of a parent that cannot vouch for the authenticity of the child s key. The combination of RRSIG and the child s public key in a DNSKEY record allows validation of the source of the data (see Figure 5). But only the associated private key can be used to sign it in the first place. Figure 5 : Secure DNS Query and Response (simple case) Thus, the simplest DNSSEC sequence is to obtain the DNS information queried for, together with the signature associated with that information (in the RRSIG), and use the public key in the DNSKEY to perform the validation, proving the signature was made by the holder of the private key. However, the power of DNSSEC lies in a second step that allows the signed zone to be 23Page 24 vouched for, preferably by its parent; if not, it is vouched for by another authenticating entity. Assume for purposes of simplicity that both parent and child are DNSSEC-capable. In this more powerful DNSSEC sequence, the child has signed a DNSKEY record with the private part of a second key pair and stored the public key part of that second key pair in a record (the DS record).The child conveys the DS record to the parent. The parent signs the child s DS record with the private part of the parent s key pair, placing the resulting signature in an RRSIG record associated with the DS record. Any parent may itself be a child (except the root), and the process is replicated between each child/parent pair. This sequence creates the chain of trust up to the trust anchor, the starting point in the chain. A DNSSEC-aware resolver validates the information it receives in response to a query by using the public keys to check the signed records. How does DNSSEC work? When requested by the client, DNSSEC adds additional data to the DNS protocol responses that provide additional information to allow the DNS client to authenticate the RRset data response. From the perspective of the protocol transaction between a query agent and an authoritative name server, the change is the addition of a RRSIG part to the data response where there is a response that can be generated, and the use of an NSEC RR response, plus its accompanying RRSIG record if there is no authoritative data to respond to the query. In addition to an RRSIG response covering the RRset records in the answer section of the DNS response there is also an RRSIG response covering the records in the authority section and one or more RRSIG responses relating to records in the additional response section. The client can take the RRset response and use the algorithm referenced in the RRSIG record to generate the hash of the data. The RRSIG value can be encrypted using the DNSKEY public key which will, in effect, decrypt the hash in the RRSIG record. To do this the client must also have at hand the DNSKEY record for the zone. This operation allows the client to check that the hash of the RRset data matches the decrypted RRSIG hash. The DNSKEY would normally be provided as part of the additional section of a DNSSEC response. If the client has not validated the DNSKEY within some locally defined period, then the client should also validate the DNSKEY value. This entails verifying the RRSIG record on 24Page 25 the DNSKEY value, using the same procedure as for the RRset validation. However domain zone key validation also entails the construction of a trust chain back to a trust anchor point. If this domain key is not already a trust anchor then the client needs to query the parent zone for the DS record of the child zone, which returns both a public key value and an RRSIG value, and a DNSKEY RR. This public key needs to be validated using the DNSKEY of the parent zone. This parent zone public key, in turn, must be validated. This iterative process constructs a trust chain that, hopefully, leads back to a trust anchor. At that point the DNS response can be considered to be validated. 3.4. DNSSEC ISSUES Some issues associated with DNSSEC is as follows. The average size of a DNS response message increases, due to the additional signature records that are attached to the response. Where the message size exceeds the UDP message size it will need to set the truncated response flag, causing the query to fall back to the use of TCP, with its attendant higher overheads in terms of client and server state, and the number of network messages to manage the TCP connection. The number of DNS transactions increases due to the requirement to perform additional queries for zone public key records when constructing trust chains. Even though caching has some potential to reduce much of this traffic, there is still an additional query load that must be considered with DNSSEC. The zone file increases in size due to the addition of the additional DNSEC records. The major contributors here are the NSEC and RRSIG records, and the zone size will increase. By what factor depends on what is in the zone file of course, but increases by a factor of up to seven in sizes have been noted in DNSSEC literature. The client has to spend additional time validating the signed data and validating the public key, potentially slowing the resolution process. The server has to generate new signatures over all RRset changes, which places an incremental load on the server function. 25Page 26 As noted in RFC3383 DNSSEC is complex to implement, and test bed experience to date suggests that trivial zone configuration errors or expired keys can cause serious problems for a DNSSEC-aware resolver. 4. CONCLUSION Other protocols (such as Secure Sockets Layer) do protect both personal privacy and the integrity of the transmission but are not applicable to store-and forward protocols (such as DNS, with its caches). DNSSEC fills an important gap, since perfect privacy would be meaningless if the user s transaction is hijacked or diverted during transmission through, say, cache poisoning. Thus, DNSSEC is part of a suite of security protocols and measures ranging from those appropriate for individual users on small home office systems up through zone operators of infrastructure systems. As DNSSEC capable Zones are added, the system incrementally becomes more secure.Full Deployment of the Protocol requires global cooperation across myriad entities in both the public and private sectors, including those known as registries and registrars that provide DNS services, as well as Internet service providers. Deploying DNSSEC is a necessary step toward hardening the Internet infrastructure, the base on which many applications and services depend. The Internet is as widely distributed as it is precisely because the complexities of its inner workings are largely hidden from end users who have come to trust it. The challenge is to preserve that trust. 26Page 27 REFERENCE [1] Amy Friedlander, Allison Mankin,W. Douglas Maughan, and Stephen D. Crocker, DNSSEC : A protocol toward securing the internet infrastructure, Communications of the ACM, Vol. 50, No.6,pp.44-50,June 2007 [2] http://dnsdnsrd/docs/whatis.html [3] http://dnssec [4] http://ietfrfc/rfc1034.txt [5] http://ietfrfc/rfc1035.txt [6] http://en.wikipediawiki/Domain_Name_System |