Understanding the Role of Registrars in DNSSEC Deployment

The Domain Name System (DNS) provides a scalable, flexible name resolution service. Unfortunately, its unauthenticated architecture has become the basis for many security attacks. To address this, DNS Security Extensions (DNSSEC) were introduced in 1997. DNSSEC’s deployment requires support from the top-level domain (TLD) registries and registrars, as well as participation by the organization that serves as the DNS operator. Unfortunately, DNSSEC has seen poor deployment thus far: despite being proposed nearly two decades ago, only 1% of .com, .net, and .org domains are properly signed. In this paper, we investigate the underlying reasons why DNSSEC adoption has been remarkably slow. We focus on registrars, as most TLD registries already support DNSSEC and registrars often serve as DNS operators for their customers. Our study uses large-scale, longitudinal DNS measurements to study DNSSEC adoption, coupled with experiences collected by trying to deploy DNSSEC on domains we purchased from leading domain name registrars and resellers. Overall, we find that a select few registrars are responsible for the (small) DNSSEC deployment today, and that many leading registrars do not support DNSSEC at all, or require customers to take cumbersome steps to deploy DNSSEC. Further frustrating deployment, many of the mechanisms for conveying DNSSEC information to registrars are error-prone or present security vulnerabilities. Finally, we find that using DNSSEC with third-party DNS operators such as Cloudflare requires the domain owner to take a number of steps that 40% of domain owners do not complete. Having identified several operational challenges for full DNSSEC deployment, we make recommendations to improve adoption

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

Evaluation of Anonymized ONS Queries

Electronic Product Code (EPC) is the basis of a pervasive infrastructure for the automatic identification of objects on supply chain applications (e.g., pharmaceutical or military applications). This infrastructure relies on the use of the (1) Radio Frequency Identification (RFID) technology to tag objects in motion and (2) distributed services providing information about objects via the Internet. A lookup service, called the Object Name Service (ONS) and based on the use of the Domain Name System (DNS), can be publicly accessed by EPC applications looking for information associated with tagged objects. Privacy issues may affect corporate infrastructures based on EPC technologies if their lookup service is not properly protected. A possible solution to mitigate these issues is the use of online anonymity. We present an evaluation experiment that compares the of use of Tor (The second generation Onion Router) on a global ONS/DNS setup, with respect to benefits, limitations, and latency.Comment: 14 page

Infrastructure of DNS/DNSSEC

DNS Security Extension is introduced as a solution after the in-depth study of all expected issues regarding security of Domain Name System. Accordingly, DNS is domain name service provider via name server but it fails to facilitate the support for authenticity of data origin and integrity. In addition, DNS satirizing give stage to digital assaults, and can be used to watch client's exercises, for control, for conveyance of pernicious programming and to offend client's PC and even to subvert rightness and accessibility of internet systems and administrations. Therefore, it is fundamental to attract DNS framework to defeat security concerns, and to make cautious arrangement that should adapt to assaults through off way foes. So, we have broken down security of area enlistment centers and name server completely and we deal with vulnerabilities, which should open DNS foundation to store harming. In this paper, we gave the DNSSEC structure and showed how it is secure using DNSSEC

The Impact of IPv6 on Penetration Testing

In this paper we discuss the impact the use of IPv6 has on remote penetration testing of servers and web applications. Several modifications to the penetration testing process are proposed to accommodate IPv6. Among these modifications are ways of performing fragmentation attacks, host discovery and brute-force protection. We also propose new checks for IPv6-specific vulnerabilities, such as bypassing firewalls using extension headers and reaching internal hosts through available transition mechanisms. The changes to the penetration testing process proposed in this paper can be used by security companies to make their penetration testing process applicable to IPv6 targets

DSTC: DNS-based Strict TLS Configurations

Most TLS clients such as modern web browsers enforce coarse-grained TLS security configurations. They support legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward-Secrecy), mainly to provide backward compatibility. This opens doors to downgrade attacks, as is the case of the POODLE attack [18], which exploits the client's silent fallback to downgrade the protocol version to exploit the legacy version's flaws. To achieve a better balance between security and backward compatibility, we propose a DNS-based mechanism that enables TLS servers to advertise their support for the latest version of the protocol and strong ciphersuites (that provide Forward-Secrecy and Authenticated-Encryption simultaneously). This enables clients to consider prior knowledge about the servers' TLS configurations to enforce a fine-grained TLS configurations policy. That is, the client enforces strict TLS configurations for connections going to the advertising servers, while enforcing default configurations for the rest of the connections. We implement and evaluate the proposed mechanism and show that it is feasible, and incurs minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most visited websites globally, and show that most of the websites can benefit from our mechanism