DOCSLIB.ORG

The Forgotten Side of DNS: Orphan and Abandoned Records

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Forgotten Side of DNS: Orphan and Abandoned Records The Forgotten Side of DNS: Orphan and Abandoned Records Raffaele Sommese∗, Mattijs Jonker∗, Roland van Rijswijk-Deij∗, Alberto Dainottiy, K.C. Claffyy, Anna Sperotto∗ ∗Design and Analysis of Communication Systems (DACS) yCAIDA University of Twente UC San Diego Enschede, the Netherlands La Jolla, CA, USA fr.sommese, m.jonker, r.m.vanrijswijk, [email protected] falberto, [email protected] Abstract—DNS zone administration is a complex task in- Given the complexity of managing DNS information, volving manual work and several entities and can therefore misconfiguration and errors can occur, with an impact on result in misconfigurations. Orphan records are one of these the overal security and reachability of the DNS. misconfigurations, in which a glue record for a delegation The goal of this paper is to analyze a specific mis- that does not exist anymore is forgotten in the zone file. configuration, defined as the orphan record [2] in a TLD. Orphan records are a security hazard to third-party domains Such orphan records are a leftover of a domain that has that have these records in their delegation, as an attacker expired, and should have been removed, by the registry may easily hijack such domains by registering the domain or by the registrar, together with the expired domain they associated with the orphan. The goal of this paper is to belong to. Orphan records form a security risk as unwit- quantify this misconfiguration, extending previous work by ting third party domains may still point to these orphan Kalafut et al., by identifying a new type of glue record records in their delegation. An attacker can easily hijack misconfiguration – which we refer to as abandoned records – domains referring to orphan records by re-registering the and by performing a broader characterization. Our results domain they belong to. highlight how the situation has changed, not always for the This work reproduces and extends the analysis per- better, compared to a decade-old study. formed by Kalafut et al. [2] in 2010 and is motivated by the main question: A decade after the original analysis, Index Terms—DNS, orphan records, abandoned records, what does the orphan records phenomenon look like? misconfiguration Compared to [2], we characterize the orphan records phenomenon through a significantly larger dataset of ∼2K 1. Introduction TLDs and over a wider time window of 25 months. We also introduce a related type of misconfiguration, which The Domain Name System (DNS) [1] is part of the has not been considered before, that we refer to as aban- core Internet infrastructure and also one of the most doned records, which could be predecessors to new orphan complex parts. The DNS is organised as a hierarchical, records. distributed database with built-in redundancy. The respon- sibility for domains is arranged through a process of 2. Background delegation, in which an entity at a higher level in the hierarchy diverts responsibility for a subset of the name Zone files and glue records. A zone is a portion of space to another party. The hierarchy starts at the root the DNS managed by a single entity. A zone file de- of the DNS, which delegates top-level domains (TLDs) scribes all the Resource Records (RRs) related to a zone, such as .com, .net, .nl, etc. These TLDs in turn del- and its format is defined in two IETF standards [3], egate to second-level domains, which in turn may further [4]. Resource Records map a host name to a specific delegate parts of the name space. Administration of these type, e.g. an A record maps a host name to an IPv4 delegations, especially at the TLD level, can be a complex address. A top-level domain (TLD) is a special type task involving many entities. As a matter of fact, within of zone that typically only has one task: to delegate the context of the DNS, we typically identify three types second-level domains. This delegation uses NS records of stakeholders: registries, registrars and registrants. The that identify the name server for a domain. If the NS registry is the entity responsible for the administration record for a domain points to a record that is inside the of a TLD. The registrar provides an interface between domain (called in-bailiwick), that name is included in the registrant and registry. It manages the administrative parts zone as a glue record to enable the resolution process related to the selling of the domain (e.g. manage payment, to continue. Consider for example: example.com NS renewal, billing and collecting owner information) and ns1.example.com. To resolve example.com, we usually provides customers an interface to interact and need to resolve ns1.example.com, but this implies modify the records related to their domains. Finally, the resolving the example.com delegation. Defining the registrant is the customer that registers a domain. A/AAAA glue record for ns1.example.com in the example.com 86400 IN NS ns.external.org parent zone file breaks this circular dependency and allows ns1.example.com 3600 IN A 1.2.3.4 ns1.expired1.com 3600 IN A 3.2.5.4 the domain to be resolved. Glue records are usually the ns1.expired2.com 3600 IN A 8.4.5.6 active.com 86400 IN NS ns1.expired2.com only A/AAAA records admitted in TLD zone files.A good.com 86400 IN NS ns1.good.com notable exception to this condition represented by the .de ns1.good.com 3600 IN A 1.2.3.5 zone is explained in x 5.3. TABLE 1: Example .com Zone File Algorithm 1 (O) Algorithm 2 (A) EPP - the Extensible Provisioning Protocol. EPP is an XML text protocol defined in RFC5730 [5]. The primary goal of EPP is to permit multiple service providers to analysis on the same zones as in [2], but also extend the manipulate objects in a shared centralized object directory. analysis to other zones available to us. Liang et al. [6] EPP was introduced by Hollenbeck to provide a standard proposed a method for keeping DNS records locked in the Internet domain registration protocol between registrars cache of open DNS resolvers after the domain expires. and registries. The protocol defines and describes the The authors defined these records as ghosts and prove interaction between these two parties via a standard set that by performing queries against open resolvers and by of atomic and idempotent commands. EPP defines three crafting an ad-hoc response in the controlled authoritative main object types: domains, contacts and hosts. EPP also nameserver, it was possible to refresh the TTL value for the defines actions, such as: check, info, create, update, delete, record in the cache of the open resolver even if the domain transfer and renew. Domain objects represent the domain no longer exists in the parent zone. While their work does itself, contacts are the WHOIS contact information, and not specifically focus on junk records, it indirectly refers finally hosts represent the glue records. to generic expired domains in the parent zone. In EPP, creation of host and domain resources are two independent operations. A registrar typically creates 3. Methodology and Dataset glue records in case of the aforementioned in-bailiwick NS record case. The specification [5] does not define who is Methodology. We developed two algorithms to respec- responsibile to clean up glue records if they are no longer tively identify orphan and abandoned records inside zone required (e.g., in case of expired domains). A registrar files. These algorithms rely on the principle that in the could periodically check this. Alternatevely, a registry zone file the only A records available are glue records1. could check on if glue records in its database are actually Algorithm 1 identifies orphan records and it is similar required by an in-bailiwick domain before publishing a to the one described in [2]. The algorithm first collects zone on its name servers. When a domain expires, after all the domains in A records available inside the zone a grace period the registrar return the responsibility of file. Then it trims the domains to the second level domain managing the domain to the registry, which should ensure (SLD). Finally, it looks for SLDs that do not have any that all the related resource records are deleted by the associated NS record. registrar. Algorithm 2 identifies abandoned records. The algo- rithm collects the list of domains in the A records available Orphan and abandoned records. Glue records are sup- in the zone file. Alike Algorithm 1, it trims the domain to posed to be removed after a delegation is removed or the SLD and looks for the SLDs for which the NS records changed. Earlier work indicates, however, that this does do not point to the extracted A records. not always happen in practice [2]. In this paper, we define Table 1 provides an example of records retrieved an orphan record as a former glue record for which the by the two algorithms. Algorithm 1 identifies related domain no longer exists in the zone (the delegation ns1.expired1.com and ns1.expired2.com has been removed). We also define an abandoned record as orphans since no NS records exist for as a former glue record for which the related domain still expired1.com or expired2.com. Algorithm 2 exists in the zone but the delegation no longer requires that marks ns1.example.com as abandoned (a delegation glue record. Under normal operation, abandoned records for example.com exists, but points elsewhere). do not show up in the DNS resolution, as there is no longer a relation with the domain the record served.
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]