A Survey on DNS Security Issues and Mitigation Techniques

Current Content Delivery Networks (CDNs) primarily utilize the Domain Name System (DNS) to direct users towards optimal content replica servers. Typically, these CDNs will leverage specialized DNS servers to perform load balancing, by providing different users with different IP endpoints for a particular hostname. However, there typically exists some form of DNS cache between the user and the authoritative DNS for a particular web service (Examples include web browsers, operating systems, and home routers). While these DNS caches typically improve user experience and network performance by reducing the number of redundant DNS requests, there exist scenarios where the presence of a DNS cache can actually harm network performance and user experience. For example: if a server or datacentre were to suddenly become unavailable, end users may become `stuck' trying to access the old IP address contained in their DNS caches, even though the authoritative DNS server may have updated it's records accordingly. In order to address this issue, we propose a system that enables network operators to transparently redirect users towards optimal servers during times of network congestion or high server load. By leveraging SDN and NFV, we are able to implement this system over a variety of network infrastructures, and to various levels of scale. Our initial tests indicate that our methodology has the capability to vastly improve user experience by several orders of magnitude during times of high network load, over a variety of network conditions. Our system is application-layer agnostic, and is compatible with various networking protocols.

Visualizing and characterizing DNS lookup behaviors via log-mining

The Domain Name System (DNS) is an essential part of the Internet on whose function many other protocols rely. One key DNS function is Dynamic Update, which allows hosts on the network to make updates to DNS records dynamically, without the need for restarting the DNS service. Unfortunately, this dynamic process does expose DNS servers to security issues. To address these issues two protocols were introduced: Transaction Signature (TSIG) and Domain Name System Security Extensions (DNSSEC). In Internet Protocol version 4 (IPv4) networks using these protocols eliminated security issues. In Internet Protocol version 6 (IPv6) however, there is an issue with the DNS authentication process when using the Stateless Address Auto Configuration (SLAAC) mechanism (new to IPv6, nonexistent in IPv4). This authentication issue occurs when a node wants to update its resource records on a DNS server, during the DNS update process, or when a client wants to authenticate a DNS resolver to ensure that the DNS response does not contain a spoofed source address or message. In this paper we propose the use of a new mechanism which makes use of asymmetric cryptography to establish a trust relationship with the DNS server. We also consider the use of the current security parameters used to generate IPv6 addresses in a secure manner, i.e. Secure Neighbor Discovery (SeND), for assuring clients and DNS servers that the one they are communicating with is the real owner of this IP address. Since we are extending the RDATA field within the TSIG protocol to accommodate these new security parameters, we will call this new mechanism the CGA-TSIG algorithm.

The Domain Name System (DNS) is a necessary component of the Internet that allows hosts on the Internet to communicate with other hosts without needing to know their cryptic IP addresses. When this protocol was first introduced it did not contain robust security features because scalability was an issue. One of the useful features added to DNS was the DNS update mechanism that allowed other hosts to dynamically change DNS entries. This feature, though, exposed new vulnerabilities to DNS servers which necessitated the implementation of new security protocols. Some of the security protocols introduced to address these issues were Transaction SIGnature (TSIG) and DNS Security Extension (DNSSEC). Although, in IPv4, these mechanisms did resolve most of the security issues dealing with authentication between a node and a DNS server, they are not viable in IPv6 networks. This is because the Neighbor Discovery Protocol (NDP) introduced to organize the large IPv6 address space automatically does not support DNS authentication or have an option for secure DNS updating. In this chapter, the authors first explain the common approaches used in IPv4 to address these security issues. Then they explain the differences between the use of these approaches in IPv4 and IPv6, where the focus is on new research with regard to authentication mechanisms between hosts and DNS servers.

Cyberattacks significantly impact the services based on the internet that is used in our daily lives. Any disruption will make it extremely difficult for us to carry out our daily activities. Cyberattacks will disrupt online services, exploit vulnerabilities to breach databases and servers, and so on. Various systems and services contribute to the Internet’s seamless functionality. The Domain Name System (DNS) is one of the most important services. DNS is used to resolve domain names into machine-readable IP addresses. DNS, like many other Internet services, is vulnerable to cyber-attacks. While DNS faces a slew of threats, one in particular appears to stand out. DNS is vulnerable to a variety of distributed denial-of-service attacks. The distributed reflection denial of service (DRDoS) attack, a flooding attack against DNS servers that renders them unavailable, disrupting domain name resolution activities, is one of the most common variants. DRDoS attacks have been on the rise in recent years. DNS lookup outages would significantly impact our online activities in the world of ultra-connectivity because they are typically the first step in establishing a connection with a server. The purpose of this paper is to present a state-of-the-art review of DRDoS attack detection and mitigation algorithms as well as the datasets on which these algorithms operate. Finally, we discussed each of these algorithms' relative merits and demerits.

The existence of the Domain Name System (DNS) through the role of the DNS Record, functions to translate domain addresses into IP addresses. High availability is an absolute condition so that the service from the DNS Server is still available and running well. To make this happen, it is necessary to have an asynchronous API on the DNS server and data management on the DNS record. This research designs and implements RESTKnot as an asynchronous API on DNS Server for DNS record management, accompanied by high availability testing using Load Balancing techniques and the Round Robin (RR) algorithm. The test results show that RESTKnot can help the DNS record management process dynamically, where DNS records can be made through the RESTKnot API and RESTKnot CLI, to be sent to the RESTKnot agent and executed by Knot DNS. The test results also show that RESTKnot can realize high availability through a ten-time system access test scenario, where heavy traffic on the first web server can be immediately diverted to the second web server to achieve high availability.

A domain name system (DNS) is one of the most important infrastructures of the Internet communication. It is also a crucial point which is subjected to attacks. The largest distributed denial-of-service (DDoS) attack on October 21, 2016 has targeted a major DNS infrastructure named dynDNS. It was actually the Internet of Things (IoT) DNS flood attack that made more than half of websites in the United States unreachable for a significant amount of time. As we are using the Internet for everything in our life, especially health care and transportation, an attack of this type may cause a major disruption. Therefore, in this article, we are going to analyze the DNS flood attacks and propose two mitigation methods. We propose a load distributed mitigation process which will work as a quick escape route of the legitimate traffic from the attack field. Our solution mainly involves service level changes which can be implemented with collaboration among service providers. Also, our proposed solution is very cost effective as compared to the cost of downtime of the domain names caused by a DNS flood attack. Furthermore, we propose a benign-bot mitigation method and a business model for the method. In the benign-bot mitigation method, a bot program is installed in customers' DNS local servers to allow IP addresses of a list of paid businesses' websites to maintain in the caches so that the websites can be accessed even when the DNS servers are down.

Domain name system (DNS) is a foundational element of internet protocol (IP) communications. The global DNS is effectively a distributed hierarchical database. Each dot in a domain name indicates a boundary between tiers in the hierarchy, with each name in between dots denoted as a label. To illustrate how domain information is organized and how a DNS server leverages this hierarchical structure, this chapter gives an example name resolution. It includes a discussion regarding the distinction between zones and domains. DNS does require some basic client configuration prior to use. This initial configuration may be performed manually or by obtaining this information from a DHCP server. The chapter provides a brief overview of device resolver configuration. This background serves as a foundation for understanding the structure of data at rest on DNS servers and resolvers, as well as the process for locating DNS information within the global DNS tree.

Domain Name System (DNS) has become a target of the Distributed Denial of Service (DDoS) attacks. When a DNS is under a DDoS flood attack, all the domain information under that DNS becomes unreachable, eventually causing unavailability of those particular domain names. In this paper, we propose a method which includes periodic stale content update and maintains a list of most frequently queried domain names of different DNS servers. Our simulation results show that the our method can serve more than \(70\%\) of the total cache responses during a massive DNS Flood attack.

DNS amplification attack revisited

When a DNS (domain name system) client needs to look up a name, it queries DNS servers to resolve the name on the Internet. The query information from the client was passed through one or more DNS servers. While useful, in the whole query transmission, we say it can leak potentially sensitive information: what a client wants to connect to, or what the client is always paying attention to. From the definition, the privacy problem is to prove that none of the private data can be inferred from the information which is made public. We first analyzed the complete DNS query process now in use; then, from each step of the DNS query process, we discussed the privacy disclosure problem in each step of the query: client side, query transmission process and DNS server side. Finally, we proposed a simple and flexible privacy-preserving query scheme "range query", which could maximally decrease privacy disclosure in the whole DNS query process. And we also discuss efficiency and implementation on the range query.

DNS(Domain Name System)는 인터넷상의 호스트의 도메인주소를 IP주소로 변환하거나 IP주소를 도메인주소로 변환하는 이름해결 메카니즘을 총칭한다. 본 논문에서는 1차 DNS 서버가 오류로 인해 정지하더라도 2차 DNS 서버가 대신하여 서비스를 지속할 수 있도록 하는 결함내성을 갖는 DNS 시스템 구축에 관해 연구하였다. DNS(Domain Name System) is the Name Resolution Mechanism that makes conversion from a Domain Name of a computer on the Internet to an IP Address or the reverse conversion. In this paper we researched on the Foundation techniques of Fault-tolerant DNS Servers that the secondary DNS can take over and provide continuous services even though primary DNS stops due to some critical errors.

In the context of work on internationalizing the Domain Name System (DNS), there have been extensive discussions about multilingual or internationalized top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific multilingual TLDs in the language(s) and script(s) of that country. This memo provides information for the Internet community.

Domain Name Systems (DNS) play a vital role in the proper functioning of the internet Almost all internet applications rely on DNS for the name resolutions. The existing DNS infrastructure has a number of security vulnerabilities and it is prone to attacks such as DNS Cache Poisoning attack, DNS Rebinding attack. Flooding attack, etc. If a DNS server is compromised, it affects all the users of the internet, resulting in adverse effect In this paper the focus has been on the prevention of DNS Rebinding attack. The solution for detecting and preventing DNS rebinding attack has been incorporated into DEEP A1. The extended DEEPA, viz., DEEPAV2 tool, containing the enhanced packet analyzer, the traffic differentiator, and enhanced packet filter modules, detects and differentiates the abnormal group of activities in the DNS traffic caused by the public IP DNS rebinding attack which is the combination of classical DNS rebinding attack and Anti-DNS pinning attack. The DEEPAV2 effectively filters the DNS rebinding attack packets by deeply analyzing the DNS packets. As the DNS rebinding attack is prevented, the subsequent attacks such as pharming, phishing, click frauds, email spamming, etc., could be prevented.

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.