DOCSLIB.ORG

An Integrity Verification Scheme for DNS Zone File Based on Security Impact Analysis

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Integrity Verification Scheme for DNS Zone File Based on Security Impact Analysis An Integrity Verification Scheme for DNS Zone file based on Security Impact Analysis Ramaswamy Chandramouli Scott Rose NIST, Gaithersburg, MD 20899 NIST, Gaithersburg, MD 20899 ([email protected]) [email protected] Abstract a query every time it receives a request from an application that requires Internet service (e.g., a The Domain Name System (DNS) is the world’s browser). The other type is called a caching (also largest distributed computing system that performs the called recursive/resolving) name server that caches the key function of translating user-friendly domain names name resolution responses it has obtained from to IP addresses through a process called name authoritative name servers and thus able to serve resolution. After looking at the protection measures multiple stub resolvers. for securing the DNS transactions, we discover that The zone file hosted on an authoritative name the trust in the name resolution process ultimately server consists of various types of records called depends upon the integrity of the data repository that Resource Records (RRs). Associated with each DNS authoritative name servers of DNS use. This data resource record is a type (RRtype). The code for these repository is called a zone file. Hence we analyze in RRtypes is assigned by an international organization detail the data content relationships in a zone file that called Internet Assigned Names Authority (IANA). An have security impacts. We then develop a taxonomy RR of a given RRtype in a zone file provides a and associated population of constraints. We also specific type of information. Some of the common have developed a platform-independent framework RRtype codes are: NS, MX and A. An NS RR in a using XML, XML Schema and XSLT for encoding zone file gives the fully qualified domain name those constraints and verifying them against the XML (FQDN) of the host that is considered the name server encoded zone file data to detect integrity violations. for that zone. For example, an NS RR in the zone file of the zone example.com gives the information that the host ns1.projects.example.com is a name server for 1. Introduction the domain projects.example.com. Similarly an MX RR gives the host name for a mail server for the zone. The domain name system (DNS) is the world’s An A RR gives the IP address for a host in a domain largest distributed computing system that enables within the zone. A zone file generally consists of access to any resource in the Internet by translating multiple RRs of a given RRtype with some exceptions user-friendly domain names to IP Addresses. The (e.g., there can be only SOA RR in a zone file). It can process of translating domain names to IP Addresses also have multiple RRs for the same domain name and is called Name Resolution. A DNS name resolution is same (or different) RRtype (e.g., multiple name the first step in the majority of Internet transactions. servers or mail servers for a domain say The DNS is in fact a client server system that provides services.example.com). this name resolution service through a family of The DNS infrastructure consists of many different servers called Domain Name Servers. The hierarchical types of DNS servers, DNS clients and transactions domain space is divided into administrative units among/between these entities. The most important called zones. A zone usually consists of a domain (say transaction in DNS is the one that provides the core example.com) and possibly one or more sub domains service of DNS (i.e., name resolution service) and is (projects.example.com, services.example.com). The called the DNS Query/Response. A DNS authoritative data needed for performing the name Query/Response transaction is made up of a query resolution service is contained in a file called the zone originating from a DNS client (generically called a file and the DNS servers hosting this file are called the DNS resolver) and response from a DNS name server. authoritative name servers for that zone. The DNS The response consists of one or more RRs. These RRs clients that make use of the services provided by may be served from its own zone file (for an authoritative name servers could be of two types. One authoritative name server) or from a cache of RRs type is called a stub resolver that formulates and sends obtained from other name servers (for a caching/resolving/recursive name servers). In this order for DNSSEC to be effective and the data to be way, the DNS basically serves as a global, distributed usable by clients, the original DNS data must be database. Name servers (serving zone files) each correct. contain a small portion of the global domain space, This original data is the one found in zone files of and clients issue queries using a domain name and a authoritative name servers. The overall trust in DNS desired RRtype. depends upon the integrity of the zone file data. The The DNS Query/Response transaction, just like integrity of zone file data, in the context of this paper, any other Internet-based transaction, is subject to pertains to the content satisfying certain relationship several types of attacks such as spoofing and man-in- constraints. It has nothing to do with the traditional the-middle attacks. DNS is especially vulnerable to concept of file integrity which is verified by matching these types of attacks because the basic an archived hash with the hash of the file generated on Query/Response transaction uses UDP as the the fly. Therefore, to discover the exact consequences transport. This makes it easier for an attacker to of the zone file integrity on the trust of DNS name intercept DNS message packets and alter any of the resolution service, it is necessary to perform a detailed information contained therein. An attacker could analysis of the zone file content relationships. Hence redirect Internet traffic from a host (or collection of the first of two major contributions of this paper is to hosts) in this manner. To provide protection from perform this analysis and develop a taxonomy and these attacks, it is necessary to verify that a DNS associated population of zone file integrity constraints. response has originated from an authentic source (the The second major contribution of this paper is to responding name server is indeed the one that is develop a framework for verifying a zone file for supposed to respond), the response is complete and satisfaction of these constraints and has not been tampered with on transit (integrity of the detecting/identifying violations of these integrity response is maintained). The protection requirements constraints. Towards this objective, we developed a of origin authentication and integrity verification are schema of the zone file using XML Schema [12]. We needed not only for responses originating from call this schema – “Zone File Schema”. The associated authoritative name servers but also from the cache of XML encoded Zone file is called “XML encoded resolving/recursive name servers. Zone File Data”. The integrity checks (procedural To provide these security services of data origin statement of constraints) needed for any zone file are authentication and integrity verification to DNS encoded as XSLT [13] constraints. The XSLT responses, IETF has proposed a set of security constraints are based on the Zone File Schema and can extensions to DNS collectively called DNSSEC be applied to verify the integrity of any XML encoded through a series of RFCs [8,9,10]. These DNSSEC zone file whose structure is based on Zone File specifications call for generating a digital signature Schema. A useful by product of this framework is the (stored in a new RRtype called RRSIG) for every ability to programmatically generate zone files using RRset in a zone ( a set of RRs of a given RRtype is XSLT transforms on the integrity-checked XML called an RRset) using a private key associated with encoded zone file data. the zone and then publishing the corresponding public The overall organization of this paper is as key (stored in a DNSKEY RR). This will then enable a follows. A brief description of the common data recipient of the DNS response (i.e., the DNS resolver structure of any RR and information and functionality on the client side) to verify the integrity of the RRs in provided by the original DNS RRs and DNSSEC RRs a response using the public key and the signature of are given in section 2. Section 3 builds up the case for RRsets (contained in a RRSIG RR) sent along with it integrity verification of DNS based on analysis of data in the DNS response. For discussion purposes, we will content relationships that have security impacts. call the RRs of these additional types as DNSSEC RRs Section 4 presents the taxonomy and a set of and the original RRs as simply DNS RRs. associated integrity constraints. Sections 5 and 6 However, these new types only provide the ability describe the framework for automated integrity for clients to authenticate the origin of the DNS data verification of DNS zone file. Specifically, in section (i.e. the authoritative source for the zone data) and the 5, we deal with the development of an XML Schema integrity of the data in transit. This is to counter an for the zone file and an XML encoding of an example attacker redirecting Internet traffic by altering the data zone file that corresponds to this schema. Based on the in a DNS response in transit, or in the cache of a XML Schema, XSLT constraints that encode the caching, recursive name server.
Load more

Recommended publications
  • DNS Zones Overview
    DNS Zones Overview A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has authority. A zone is a portion of a namespace. It is not a domain. A domain is a branch of the DNS namespace. A DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple DNS zones. A non-contiguous namespace cannot be a DNS zone. A zone contains the resource records for all of the names within the particular zone. Zone files are used if DNS data is not integrated with Active Directory. The zone files contain the DNS database resource records that define the zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory. The different types of zones used in Windows Server 2003 DNS are listed below: Primary zone Secondary zone Active Directory-integrated zone Reverse lookup zone Stub zone A primary zone is the only zone type that can be edited or updated because the data in the zone is the original source of the data for all domains in the zone. Updates made to the primary zone are made by the DNS server that is authoritative for the specific primary zone. Users can also back up data from a primary zone to a secondary zone. A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. In fact, a secondary zone can only be updated through zone transfer. An Active Directory-integrated zone is a zone that stores its data in Active Directory.
    [Show full text]
  • Domain Name System 1 Domain Name System
    Domain Name System 1 Domain Name System The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. A Domain Name Service translates queries for domain names (which are easier to understand and utilize when accessing the internet) into IP addresses for the purpose of locating computer services and devices worldwide. 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, the domain name www.example.com translates to the addresses 192.0.43.10 (IPv4) and 2620:0:2d0:200::10 (IPv6). The Domain Name System makes it possible to assign domain names to groups of Internet resources and users in a meaningful way, independent of each entity's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. 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). Users take advantage of this when they recite meaningful Uniform Resource Locators (URLs) and e-mail addresses without having to know how the computer actually locates them. The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain.
    [Show full text]
  • DNS) Administration Guide
    Edgecast Route (DNS) Administration Guide Disclaimer Care was taken in the creation of this guide. However, Edgecast cannot accept any responsibility for errors or omissions. There are no warranties, expressed or implied, including the warranty of merchantability or fitness for a particular purpose, accompanying this product. Trademark Information EDGECAST is a registered trademark of Verizon Digital Media Services Inc. About This Guide Route (DNS) Administration Guide Version 2.40 8/28/2021 ©2021 Verizon Media. All rights reserved. Table of Contents Route ............................................................................................................................................................. 1 Introduction .............................................................................................................................................. 1 Scope ......................................................................................................................................................... 1 Module Comparison ................................................................................................................................. 2 Managed (Primary) or Secondary DNS Module .................................................................................... 2 DNS Health Checks Module .................................................................................................................. 3 Billing Activation ......................................................................................................................................
    [Show full text]
  • Rssac026v2: RSSAC Lexicon
    RSSAC026v2: RSSAC Lexicon An Advisory from the ICANN Root Server System Advisory Committee (RSSAC) 12 March 2020 RSSAC Lexicon Preface This is an Advisory to the Internet Corporation for Assigned Names and Numbers (ICANN) Board of Directors and the Internet community more broadly from the ICANN Root Server System Advisory Committee (RSSAC). In this Advisory, the RSSAC defines terms related to root server operations for the ICANN Community. The RSSAC seeks to advise the ICANN community and Board on matters relating to the operation, administration, security and integrity of the Internet’s Root Server System. This includes communicating on matters relating to the operation of the Root Servers and their multiple instances with the technical and ICANN community, gathering and articulating requirements to offer to those engaged in technical revisions of the protocols and best common practices related to the operational of DNS servers, engaging in ongoing threat assessment and risk analysis of the Root Server System and recommend any necessary audit activity to assess the current status of root servers and root zone. The RSSAC has no authority to regulate, enforce, or adjudicate. Those functions belong to others, and the advice offered here should be evaluated on its merits. The RSSAC has relied on the RSSAC Caucus, a group of DNS experts who have an interest in the Root Server System to perform research and produce this publication. A list of the contributors to this Advisory, references to RSSAC Caucus members’ statement of interest, and RSSAC members’ objections to the findings or recommendations in this Report are at the end of this document.
    [Show full text]
  • DNS) Deployment Guide
    Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-81 Revision 1 Title: Secure Domain Name System (DNS) Deployment Guide Publication Date(s): April 2010 Withdrawal Date: September 2013 Withdrawal Note: SP 800-81 Revision 1 is superseded in its entirety by the publication of SP 800-81-2 (September 2013). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-81-2 Title: Secure Domain Name System (DNS) Deployment Guide Author(s): Ramaswamy Chandramouli, Scott Rose Publication Date(s): September 2013 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-81-2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-81-2 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal N/A announcement (link): Date updated: ƵŐƵƐƚϳ, 2015 Special Publication 800-81r1 Sponsored by the Department of Homeland Security Secure Domain Name System (DNS) Deployment Guide Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose i NIST Special Publication 800-81r1 Secure Domain Name System (DNS) Deployment Guide Sponsored by the Department of Homeland Security Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose C O M P U T E R S E C U R I T Y Computer Security Division/Advanced Network Technologies Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 April 2010 U.S.
    [Show full text]
  • DNS Introduction
    DNS Introduction www.what-is-my-ip-address.com (C) Herbert Haas 2005/03/11 1 “Except for Great Britain. According to ISO 3166 and Internet tradition, Great Britain's top-level domain name should be gb. Instead, most organizations in Great Britain and Northern Ireland (i.e., the United Kingdom) use the top-level domain name uk. They drive on the wrong side of the road, too.” DNS and BIND book Footnote to the ISO 3166 two-letter country code TLDs 2 DNS Tree Growth 162,128,493 by 2002/7 (C) Herbert Haas 2005/03/11 3 The ISC about the new DNS survey method: The new survey works by querying the domain system for the name assigned to every possible IP address. However, this would take too long if we had to send a query for each of the potential 4.3 billion (2^32) IP addresses that can exist. Instead, we start with a list of all network numbers that have been delegated within the IN-ADDR.ARPA domain. The IN-ADDR.ARPA domain is a special part of the domain name space used to convert IP addresses into names. For each IN- ADDR.ARPA network number delegation, we query for further subdelegations at each network octet boundary below that point. This process takes about two days and when it ends we have a list of all 3-octet network number delegations that exist and the names of the authoritative domain servers that handle those queries. This process reduces the number of queries we need to do from 4.3 billion to the number of possible hosts per delegation (254) times the number of delegations found.
    [Show full text]
  • Measurements and Laboratory Simulations of the Upper DNS Hierarchy
    Measurements and Laboratory Simulations of the Upper DNS Hierarchy 1 2 2 2 Duane Wessels , Marina Fomenkov , Nevil Brownlee , and kc claffy 1 The Measurement Factory, Inc. [email protected] 2 CAIDA, San Diego Supercomputer Center, University of California, San Diego fmarina, nevil, [email protected] Abstract. Given that the global DNS system, especially at the higher root and top-levels, experiences significant query loads, we seek to answer the following questions: (1) How does the choice of DNS caching software for local resolvers affect query load at the higher levels? (2) How do DNS caching implementations spread the query load among a set of higher level DNS servers? To answer these questions we did case studies of workday DNS traffic at the University of California San Diego (USA), the University of Auckland (New Zealand), and the University of Colorado at Boulder (USA). We also tested var- ious DNS caching implementations in fully controlled laboratory experiments. This paper presents the results of our analysis of real and simulated DNS traffic. We make recommendations to network administrators and software developers aimed at improving the overall DNS system. 1 Background The Domain Name System (DNS) is a fundamental component of the modern Inter- net [1], providing a critical link between human users and Internet routing infrastructure by mapping host names to IP addresses. The DNS hierarchical name space is divided into zones and coded in the widespread “dots” structure. For example, com is the parent zone for microsoft.com, cnn.com, and approximately 20 million other zones. The DNS hierarchy’s root zone is served by 13 nameservers, known collectively as the DNS root servers.
    [Show full text]
  • DNS and the DNS Cache Poisoning Attack
    Lecture 17: DNS and the DNS Cache Poisoning Attack Lecture Notes on “Computer and Network Security” by Avi Kak ([email protected]) June 25, 2021 3:21pm ©2021 Avinash Kak, Purdue University Goals: The Domain Name System BIND Configuring BIND Running BIND on your Ubuntu laptop Light-Weight Nameservers (and how to install them) DNS Cache Poisoning Attack Writing Perl and Python code for cache poisoning attacks Dan Kaminsky’s More Virulent DNS Cache Poisoning Attack CONTENTS Section Title Page 17.1 Internet, Harry Potter, and the Magic of DNS 3 17.2 DNS 5 17.3 An Example That Illustrates Extensive DNS 13 Lookups in Even the Simplest Client-Server Interactions 17.4 The Domain Name System and The dig Utility 28 17.5 host, nslookup, and whois Utilities for Name 42 Lookup 17.6 Creating a New Zone and Zone Transfers 45 17.7 DNS Cache 48 17.7.1 The TTL Time Interval 51 17.8 BIND 56 17.8.1 Configuring BIND 58 17.8.2 An Example of the named.conf Configuration File 64 17.8.3 Running BIND on Your Ubuntu Laptop 68 17.9 What Does it Mean to Run a Process in a 70 chroot Jail? 17.10 Phishing versus Pharming 73 17.11 DNS Cache Poisoning 74 17.12 Writing Perl and Python Code for Mounting a 81 DNS Cache Poisoning Attack 17.13 Dan Kaminsky’s More Virulent Exploit for 92 DNS Cache Poisoning 17.14 Homework Problems 99 Computer and Network Security by Avi Kak Lecture 17 Back to TOC 17.1 INTERNET, HARRY POTTER, AND THE MAGIC OF DNS If you have read Harry Potter, you are certainly familiar with the use of owl mail by the wizards and the witches.
    [Show full text]
  • Understanding Implications of DNS Zone Provisioning
    Understanding Implications of DNS Zone Provisioning Andrew J. Kalafut Craig A. Shue Minaxi Gupta [email protected] [email protected] [email protected] Computer Science Department Indiana University Bloomington, IN ABSTRACT a domain need to synchronize with each other in their view DNS is a critical component of the Internet. This paper of the zone. The DNS provides a special query for that, takes a comprehensive look at the provisioning of Internet called the zone transfer query. In this work, we leverage the domains and its impact on the availability of various services. zone transfer query to capture detailed information about To gather data, we sweep 60% of the Internet’s domains DNS zones in the Internet. During a three month period, for zone transfers. 6.6% of them allow us to transfer their we swept 60% of the Internet for zone transfers. In order to complete information. We find that carelessness in handling increase our data beyond those zones allowing zone trans- DNS records can lead to reduced availability of name servers, fer, we walked the zones of the second-level domains known email, and Web servers. It also undermines anti-spam efforts to deploy DNSSEC [2] (DNS Security Extensions). This is and the efforts to shut down phishing sites or to contain a slow process since it involves making a large number of malware infections. queries, but its net effect is the same as a zone transfer. Us- ing the two data sets, we examined the DNS zones in our two data sets. The key findings of our study are the following: Categories and Subject Descriptors C.2.2 [Network protocols]: Applications—DNS 1.
    [Show full text]
  • When Parents and Children Disagree: Diving Into DNS Delegation Inconsistency
    When parents and children disagree: Diving into DNS delegation inconsistency Raffaele Sommese1, Giovane C.M. Moura2, Mattijs Jonker1, Roland van Rijswijk-Deij1;3, Alberto Dainotti4, K.C. Claffy4, and Anna Sperotto1 1 University of Twente 2 SIDN Labs 3 NLnet Labs 4 CAIDA Abstract. The Domain Name System (DNS) is a hierarchical, decen- tralized, and distributed database. A key mechanism that enables the DNS to be hierarchical and distributed is delegation [7] of responsibil- ity from parent to child zones—typically managed by different entities. RFC1034 [12] states that authoritative nameserver (NS) records at both parent and child should be “consistent and remain so”, but we find in- consistencies for over 13M second-level domains. We classify the type of inconsistencies we observe, and the behavior of resolvers in the face of such inconsistencies, using RIPE Atlas to probe our experimental do- main configured for different scenarios. Our results underline the risk such inconsistencies pose to the availability of misconfigured domains. 1 Introduction The Domain Name System (DNS) [12] is one of the most critical components of the Internet, used by virtually every user and application. DNS is a distributed, hierarchical database that maps hosts, services and applications to IP addresses and various other types of records. A key mechanism that enables the DNS to be hierarchical and distributed is delegation [7]. In order for delegation to work, the DNS hierarchy is organized in parent and child zones—typically managed by different entities—that need to share common information (NS records) about which are the authoritative name servers for a given domain.
    [Show full text]
  • DNS and BIND Other Resources from O’Reilly
    DNS and BIND Other resources from O’Reilly Related titles DNS and BIND Cookbook™ DNS on Windows Server 2003 oreilly.com oreilly.com is more than a complete catalog of O’Reilly books. You’ll also find links to news, events, articles, weblogs, sample chapters, and code examples. oreillynet.com is the essential portal for developers interested in open and emerging technologies, including new platforms, pro- gramming languages, and operating systems. Conferences O’Reilly brings diverse innovators together to nurture the ideas that spark revolutionary industries. We specialize in document- ing the latest tools and systems, translating the innovator’s knowledge into useful skills for those in the trenches. Visit con- ferences.oreilly.com for our upcoming events. Safari Bookshelf (safari.oreilly.com) is the premier online refer- ence library for programmers and IT professionals. Conduct searches across more than 1,000 books. Subscribers can zero in on answers to time-critical questions in a matter of seconds. Read the books on your Bookshelf from cover to cover or sim- ply flip to the page you need. Try it today for free. FIFTH EDITION DNS and BIND Cricket Liu and Paul Albitz Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo DNS and BIND, Fifth Edition by Cricket Liu and Paul Albitz Copyright © 2006, 2001, 1998, 1997, 1992 O’Reilly Media, Inc. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (safari.oreilly.com).
    [Show full text]
  • A Longitudinal, End-To-End View of the DNSSEC Ecosystem
    A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung Roland van Rijswijk-Deij Northeastern University University of Twente and SURFnet Balakrishnan Chandrasekaran David Choffnes Dave Levin TU Berlin Northeastern University University of Maryland Bruce M. Maggs Alan Mislove Duke University and Akamai Technologies Northeastern University Christo Wilson Northeastern University Abstract To address these problems, DNS Security Extensions (DNSSEC) [20] were introduced nearly two decades ago. The Domain Name System’s Security Extensions At its core, DNSSEC is a hierarchical public key infras- (DNSSEC) allow clients and resolvers to verify that tructure (PKI) that largely mirrors the DNS hierarchy and DNS responses have not been forged or modified in- is rooted at the root DNS zone. To enable DNSSEC, the flight. DNSSEC uses a public key infrastructure (PKI) owner of a domain signs its DNS records and publishes to achieve this integrity, without which users can be sub- the signatures along with its public key; this public key is ject to a wide range of attacks. However, DNSSEC can then signed by its parent domain, and so on up to the root operate only if each of the principals in its PKI prop- DNS zone. A resolver validates a signed DNS record erly performs its management tasks: authoritative name by recursively checking the associated signatures until it servers must generate and publish their keys and signa- reaches the well-known root zone trusted key. tures correctly, child zones that support DNSSEC must Largely in response to powerful attacks such as the be correctly signed with their parent’s keys, and resolvers Kaminsky Attack [28], DNSSEC adoption has increased must actually validate the chain of signatures.
    [Show full text]