Dynamic DNS filtering applications use the DNS system to filter out DNS answers to clients, that query for malicious hosts or content. This traffic between the client and local resolver as well as to upstream nameservers is commonly not protected against attackers. This paper provides an approach to securing two commonly used filtering DNS resolvers between the client and itself and on the upstream side and compares them to Unbound, a validating, recursive, caching DNS resolver and its features
The Domain Name System, described in RFC 1034 and specified in RFC 1035 provides the Internet standard mechanism for name to IP address resolution, which was revised and added upon multiple times. Relevant RFCs in the context of this paper are [1], [2], [3] regarding DNS, [4], [5], [6] and [7] regarding DNSSEC and [8], [9] regarding encryption for DNS. DNS is an integral part of digital communication, but the standard protocol provides no security: It either uses unencrypted UDP over port 53 or unencrypted TCP over port 53 to resolve names. Also, the requested names in a query to a DNS server, could itself be part of a malicious intent: As the user has no control over the target domain name and what domains the hosts queries for (at least in a common setup), there is also no control for the user, to decide what content to get – it is entirely dependent on the remote nameserver. This, in combination with a global rise in internet advertisements [10] has led to the development of DNS blocking solutions, that effectively stop the local host from resolving the domain names of advertisement services or malicious content by using curated lists of blocked domains. These services, when deployed, mostly use the standard DNS over Port 53, either by recursively resolving domains by themselves [11], or by using one or more upstream (recursive) resolver servers (i.e. Google and Cloudflare provide such servers [12] [13]), that will then directly answer the query to the local resolver/DNS software. All this communication is not secure by default. This paper presents different approaches to securing two commonly used DNS filtering applications and compares their filtering capabilities to the Unbound [14] DNS resolver software. Local resolver in the context of this paper is always the network-local server that receives and answers queries from the network clients (i.e. The Pi-hole server, AdGuard server or Unbound server).
Philipp Kalytta studiert Technische Informatik an der TH Köln und beschäftigt sich auch als Hobby mit IT-Themen
Philipp Kalytta studiert Technische Informatik an der TH Köln und beschäftigt sich auch als Hobby mit IT-Themen