Securing The Root: A Proposal For Distributing Signing Authority

Management of the Domain Name System (DNS) root zone file is a uniquely global policy problem. For the Internet to connect everyone, the root must be coordinated and compatible. While authority over the legacy root zone file has been contentious and divisive at times, everyone agrees that the Internet should be made more secure. A newly standardized protocol, DNS Security Extensions (DNSSEC), would make the Internet's infrastructure more secure. In order to fully implement DNSSEC, the procedures for managing the DNS root must be revised. Therein lies an opportunity. In revising the root zone management procedures, we can develop a new solution that diminishes the impact of the legacy monopoly held by the U.S. government and avoids another contentious debate over unilateral U.S. control. In this paper we describe the outlines of a new system for the management of a DNSSEC-enabled root. Our proposal distributes authority over securing the root, unlike another recently suggested method, while avoiding the risks and pitfalls of an intergovernmental power sharing scheme

Roll, Roll, Roll your Root:A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover

The DNS Security Extensions (DNSSEC) add authenticity and integrity to the naming system of the Internet. Resolvers that validate information in the DNS need to know the cryptographic public key used to sign the root zone of the DNS. Eight years after its introduction and one year after the originally scheduled date, this key was replaced by ICANN for the first time in October 2018. ICANN considered this event, called a rollover, "an overwhelming success" and during the rollover they detected "no significant outages". In this paper, we independently follow the process of the rollover starting from the events that led to its postponement in 2017 until the removal of the old key in 2019. We collected data from multiple vantage points in the DNS ecosystem for the entire duration of the rollover process. Using this data, we study key events of the rollover. These events include telemetry signals that led to the rollover being postponed, a near real-time view of the actual rollover in resolvers and a significant increase in queries to the root of the DNS once the old key was revoked. Our analysis contributes significantly to identifying the causes of challenges observed during the rollover. We show that while from an end-user perspective, the roll indeed passed without major problems, there are many opportunities for improvement and important lessons to be learned from events that occurred over the entire duration of the rollover. Based on these lessons, we propose improvements to the process for future rollovers

Evaluation of Dnssec in Microsoft Windows and Microsoft Windows Server 2008 R2

The Domain Name System (DNS) provides important name resolution services on the Internet. The DNS has been found to have security flaws which have the potential to undermine the reliability of many Internet-based systems. DNS Security Extensions (DNSSEC) offers a long-term solution these DNS security flaws. However, DNSSEC adoption has been slow because it is challenging to deploy and administer. DNSSEC has also been criticized for not being an end-toend solution. Microsoft included support for DNSSEC in its latest operating systems, Windows Server 2008 R2 and Windows 7. This thesis concluded that DNSSEC features in Windows Server 2008 R2 and Windows 7 are not fully developed and are unlikely to impact DNSSEC adoption rates

Library and Tools for Server-Side DNSSEC Implementation

Tato práce se zabývá analýzou současných open source řešení pro zabezpečení DNS zón pomocí technologie DNSSEC. Na základě provedené rešerše je navržena a implementována nová knihovna pro použití na autoritativních DNS serverech. Cílem knihovny je zachovat výhody stávajících řešení a vyřešit jejich nedostatky. Součástí návrhu je i sada nástrojů pro správu politiky a klíčů. Funkčnost vytvořené knihovny je ukázána na jejím použití v serveru Knot DNS.This thesis deals with currently available open-source solutions for securing DNS zones using the DNSSEC mechanism. Based on the findings, a new DNSSEC library for an authoritative name server is designed and implemented. The aim of the library is to keep the benefits of existing solutions and to eliminate their drawbacks. Also a set of utilities to manage keys and signing policy is proposed. The functionality of the library is demonstrated by it's use in the Knot DNS server.

Is DNS Ready for Ubiquitous Internet of Things?

The vision of the Internet of Things (IoT) covers not only the well-regulated processes of specific applications in different areas but also includes ubiquitous connectivity of more generic objects (or things and devices) in the physical world and the related information in the virtual world. For example, a typical IoT application, such as a smart city, includes smarter urban transport networks, upgraded water supply, and waste-disposal facilities, along with more efficient ways to light and heat buildings. For smart city applications and others, we require unique naming of every object and a secure, scalable, and efficient name resolution which can provide access to any object\u27s inherent attributes with its name. Based on different motivations, many naming principles and name resolution schemes have been proposed. Some of them are based on the well-known domain name system (DNS), which is the most important infrastructure in the current Internet, while others are based on novel designing principles to evolve the Internet. Although the DNS is evolving in its functionality and performance, it was not originally designed for the IoT applications. Then, a fundamental question that arises is: can current DNS adequately provide the name service support for IoT in the future? To address this question, we analyze the strengths and challenges of DNS when it is used to support ubiquitous IoT. First, we analyze the requirements of the IoT name service by using five characteristics, namely security, mobility, infrastructure independence, localization, and efficiency, which we collectively refer to as SMILE. Then, we discuss the pros and cons of the DNS in satisfying SMILE in the context of the future evolution of the IoT environment

Towards Adoption of DNSSEC: Availability and Security Challenges

DNSSEC deployment is long overdue; however, it seems to be finally taking off. Recent cache poisoning attacks motivate protecting DNS, with strong cryptography, rather than with challenge-response ‘defenses’. Our goal is to motivate and help correct DNSSEC deployment. We discuss the state of DNSSEC deployment, obstacles to adoption and potential ways to increase adoption. We then present a comprehensive overview of challenges and potential pitfalls of DNSSEC, well known and less known, including:DNSSEC deployment is long overdue; however, it seems to be finally taking off. Recent cache poisoning attacks motivate protecting DNS, with strong cryptography, rather than with challenge-response ‘defenses’. Our goal is to motivate and help correct DNSSEC deployment. We discuss the state of DNSSEC deployment, obstacles to adoption and potential ways to increase adoption. We then present a comprehensive overview of challenges and potential pitfalls of DNSSEC, well known and less known, including: - Vulnerable configurations: we present several DNSSEC configurations, which are natural and, based on the limited deployment so far, expected to be popular, yet are vulnerable to attack. This includes NSEC3 opt-out records and interdomain referrals (in NS, MX and CNAME records). - Incremental Deployment: we discuss potential for increased vulnerability due to popular practices of incremental deployment, and recommend secure practice. - Super-sized Response Challenges: DNSSEC responses include cryptographic keys and hence are relatively long; we explain how this extra-long responses cause interoperability challenges, and can be abused for DoS and even DNS poisoning. We discuss potential solutions. - Vulnerable configurations: we present several DNSSEC configurations, which are natural and, based on the limited deployment so far, expected to be popular, yet are vulnerable to attack. This includes NSEC3 opt-out records and interdomain referrals (in NS, MX and CNAME records). - Incremental Deployment: we discuss potential for increased vulnerability due to popular practices of incremental deployment, and recommend secure practice. - Super-sized Response Challenges: DNSSEC responses include cryptographic keys and hence are relatively long; we explain how this extra-long responses cause interoperability challenges, and can be abused for DoS and even DNS poisoning. We discuss potential solutions

A Formal Specification of the DNSSEC Model

The Domain Name System Security Extensions (DNSSEC) is a suite of specifications that provide origin authentication and integrity assurance services for DNS data. In particular, DNSSEC was designed to protect resolvers from forged DNS data, such as the one generated by DNS cache poisoning. This article presents a minimalistic specification of a DNSSEC model which provides the grounds needed to formally state and verify security properties concerning the chain of trust of the DNSSEC tree. The model, which has been formalized and verified using the Coq proof assistant, specifies an abstract formulation of the behavior of the protocol and the corresponding security-related events, where security goals, such as the prevention of cache poisoning attacks, can be given a formal treatment

Deploying DNSSEC in islands of security

The Domain Name System (DNS), a name resolution protocol is one of the vulnerable network protocols that has been subjected to many security attacks such as cache poisoning, denial of service and the 'Kaminsky' spoofing attack. When DNS was designed, security was not incorporated into its design. The DNS Security Extensions (DNSSEC) provides security to the name resolution process by using public key cryptosystems. Although DNSSEC has backward compatibility with unsecured zones, it only offers security to clients when communicating with security aware zones. Widespread deployment of DNSSEC is therefore necessary to secure the name resolution process and provide security to the Internet. Only a few Top Level Domains (TLD's) have deployed DNSSEC, this inherently makes it difficult for their sub-domains to implement the security extensions to the DNS. This study analyses mechanisms that can be used by domains in islands of security to deploy DNSSEC so that the name resolution process can be secured in two specific cases where either the TLD is not signed or the domain registrar is not able to support signed domains. The DNS client side mechanisms evaluated in this study include web browser plug-ins, local validating resolvers and domain look-aside validation. The results of the study show that web browser plug-ins cannot work on their own without local validating resolvers. The web browser validators, however, proved to be useful in indicating to the user whether a domain has been validated or not. Local resolvers present a more secure option for Internet users who cannot trust the communication channel between their stub resolvers and remote name servers. However, they do not provide a way of showing the user whether a domain name has been correctly validated or not. Based on the results of the tests conducted, it is recommended that local validators be used with browser validators for visibility and improved security. On the DNS server side, Domain Look-aside Validation (DLV) presents a viable alternative for organizations in islands of security like most countries in Africa where only two country code Top Level Domains (ccTLD) have deployed DNSSEC. This research recommends use of DLV by corporates to provide DNS security to both internal and external users accessing their web based services.LaTeX with hyperref packagepdfTeX-1.40.1