A DNS sinkhole is used to block malicious DNS requests. Implementation can be done via DNS servers, a firewall or other on-prem application, or a hosted service.
The process works by intercepting DNS queries and comparing them to a dynamic list of known malicious domains. If a query attempts to resolve a known bad domain, the response is configured to contain a non-routable IP address to block (sinkhole) the traffic from reaching the domain.
What is DNS? And how does it work?
To understand the benefit a DNS sinkhole can provide, it’s important to first understand the basics of how DNS works.
DNS is the speed dial app of the Internet. All websites are hosted on servers that use IP addresses in decimal or hexadecimal format (i.e., 220.127.116.11 or FE80:CD00:0000:0CDE:1257:0000:211E:729C).
IP addresses are what the routers that interconnect all the networks that make up the Internet understand. The problem is that people can’t remember these long numeric values.
Internet routers need IP addresses to send traffic to their correct destination on the Internet, but people can’t possibly remember these. That’s where the magic of DNS comes in. DNS allows names to be mapped to IP addresses. Therefore, IP addresses don’t have to be remembered by people.
Here’s how it works. DNS servers store databases that contain mappings for domain names to their respective IP addresses. Your computer or phone is configured to point to a DNS server so when you type in a domain name in the web browser, it can find the IP address from the DNS server and route the traffic to that IP address.
Usually, the DNS server you point to is on your local network, but it doesn’t have to be. If the DNS server you are pointing to doesn’t know the IP address of a particular domain, it is usually configured to forward to another DNS server upstream from it to complete the name resolution.
The result is just like looking up someone by name on the speed dial app on your phone before placing a call. It’s much easier to remember their name than their phone number.
To learn more about DNS itself, independent of sinkhole specific functionality, consider reading CloudFlare’s excellent guide, What is DNS?
DNS is efficient, it’s elegant, and it gets the job done. Yet, some problems arise when relying exclusively on DNS.
Problems with DNS
DNS makes navigating the Internet possible. At the same time, it has some flaws. First, DNS has no native ability to distinguish between legitimate and malicious network traffic. Thus, when you type in a domain name DNS will get you to that website regardless of if the server is compromised or the site contains malware.
Also, there is nothing to stop a computer that has been infected with malware from changing the DNS servers it uses to point to malicious ones. That would allow tit to be directed to harmful domains used by hackers.
DNS sinkholes offer a means to mitigate these situations where DNS traffic to malicious or unwanted domains represents a threat.
How a DNS sinkhole works
Computers and devices generally trust their DNS servers without question. Using a DNS sinkhole, this lack of skepticism can be improved to add some protection that prevents computers from browsing to unsafe locations.
A DNS sinkhole is a dead-end or black hole akin to routing to the null route. For example, let’s say some known bad website called malwarexyzabc.com points to 18.104.22.168. We want to stop traffic from being able to get there. We can tell our DNS server that if it receives a query for malwarexyzabc.com to point to 127.0.0.1 (the loopback), which would prevent the traffic from being routed to the site. Better yet, we could point it to the IP address of a logging server that would allow us to track systems that were attempting to access this malware domain for further investigation.
To recap, a DNS sinkhole prevents a device from reaching a domain by directing it to another IP address instead. The key is having a dynamically updated list of known bad sites to send to the sinkhole. We will cover a couple of options to accomplish this shortly.
A DNS sinkhole by itself helps prevent users from unknowingly navigating to harmful sites. However, on its own, a DNS sinkhole has some limitations.
First, with self made solutions and some services, there is no native alerting. In this case, when a computer attempts to browse a bad site, you won’t get any indication of it to prompt further investigation. This limitation can be mitigated by using a logging server as the sinkhole or using a service or application that includes alerting capability.
Second, no database of malicious sites is perfect. There will always be false positives. That’s why it’s important to have an easy-to-use process in place to override false positives if they can be validated as such.
Finally, if you are using a hosted service-based DNS sinkhole that also functions as your DNS resolver, it is possible that you could experience an outage. It’s important to know your provider’s SLA and always have a backup plan you can quickly implement in a pinch.
DNS sinkhole options
The optimal setup for a DNS sinkhole depends on the network design and objectives. There are three main ways to implement a DNS sinkhole:
- An administrator can roll their own by setting up a DNS server to have sinkholing capability.
- An on-prem application can be used to intercept DNS traffic and sinkhole.
- A cloud-hosted service can be used as a DNS forwarder that includes sinkhole functionality.
An administrator must decide which option is the best fit for their network and goals. Each option has benefits and downsides.
Setting up your sinkhole server has the benefit of giving you complete control and customization. The downsides are that there is no support, and the database you rely on to catalog bad domains may not be properly maintained. It’s easier to trust a specialized third party than to manually update your list of dangerous domains.
It’s worth checking to see if you already have an application that includes DNS sinkhole functionality. Many Layer 7 Next-Gen Firewalls support this capability. The benefits of this are that it is leveraging technology you may already own, will be more dependable than a self-made sinkhole, and has enterprise support.
The downsides are that you may need to configure your firewall to act as your DNS resolver, you might have to redesign your network to proxy DNS traffic through your firewall, and it may create a single point of failure for DNS (whereas with DNS servers there is normally redundancy).
Many cloud-hosted DNS services include DNS sinkhole capability as part of their feature sets. The benefit of these is that they don’t require redesigning your network to get up and running. It also doesn’t result in a single point of failure as services are load-balanced.
A hosted DNS sinkhole’s downside is that it will have less customization However, because of the ease of implementation, security benefits, and support available, this will be the easiest to get up and running. This option will usually provide the most bang for the buck, assuming you don’t have an app that can do it.
If you aren’t sure of any specific services that offer this functionality and want to know what providers are on the market, the following are the most popular DNS sinkhole providers:
- AWS Route 53
Below are instructions required to get the DNS sinkhole set up with a hosted service that supports it.
Instructions for setting up a DNS sinkhole
- Select a hosted DNS provider that supports DNS sinkhole capability.
- Note the IP addresses of the hosted DNS providers DNS resolvers.
- Configure your on-prem internal DNS servers to use the hosted providers resolvers as DNS forwarders.
- Make sure all your internal systems point to your DNS servers that are configured to forward to the hosted provider that is configured as a DNS sinkhole.
- Confirm it works by browsing to a test site.
- Configure alerts, if supported, to monitor systems that attempt to browse to malicious sites.
- Devise a plan of action when alerts are generated, for investigating the source and neutralizing any potential malware.
The following are a few best practices you should follow:
- Avoid setting up your DNS sinkhole from scratch if you have the option to use an app or hosted service, as it will not be as reliable.
- Set up monitoring and logging of systems that trip the DNS sinkhole so that they can be investigated and remediated if they are infected with malware.
- Restrict outbound DNS traffic leaving your network, so only the DNS resolvers of your DNS hosted service are allowed to be accessed. This will prevent someone from circumventing your DNS sinkhole by changing the locally configured DNS servers.
- Add conditional forwarders, if necessary, for any sites that require custom DNS resolution that your DNS service can’t provide.
A DNS sinkhole is a clever way to leverage the existing DNS protocol to extend protective capabilities. Even if malware does become active on systems in your network, this strategy often prevents the malware from performing its malicious goal by preventing it from beaconing out to a command and control server.
DNS sinkholes empower administrators to pre-emptively block traffic to malicious domains by forwarding the traffic to a sinkhole instead of the harmful destination. This offers a leg up on malicious software and acts as an additional layer of defense for the network.
See how Network Administrators are using Active Monitoring - Synthetic Monitoring - as the basis for building a strong digital observability strategy.
In our overview article, you’ll learn about tiers of Internet Service Providers (ISP), Autonomous Systems (AS), and the Internet Exchange Points (IXP) ISPs use to exchange traffic via the BGP routing protocol. You’ll also be given some context for related technologies (such as SD-WAN and IPv6) and troubleshooting tools (such as ping and traceroute).
This chapter tackles the ISP arrangement known as “IP transit,” which is used to transport traffic to its destination, and understand how it differs from IP peering. You’ll also learn about supporting concepts like AS path, dual-homing, BGP communities, and Resource Public Key Infrastructure (RPKI), which helps protect against threats such as BGP leaks and hijacking
Software-defined wide area networks (SD-WAN) are the most popular way to connect remote corporate networks. In this article, we present the benefits and challenges of SD-WANs, and compare SD-WANs to dedicated connections based on the Multiprotocol Label Switching (MPLS) protocol.
Put your newfound knowledge to use by accessing 16 free online tools. Each tool has a specific and useful functionality, such as testing website speeds from global locations, checking MX records, performing Organizationally Unique Identifier (OUI) lookups, browsing the most updated BGP route servers list on the internet, and more.
Learn the differences between Software-defined wide area networks (SD-WAN) and Multiprotocol Label Switching (MPLS) protocol in supporting your multi-site connectivity. In this article, we provide tabular side-by-side comparison, and explain the pros, cons and benefits of each solution.
Introduction page blurb: MQTT is a lightweight protocol that supports the Internet of Things (IoT). This article explains the functionality of its central hub known as the MQTT broker, compares its various implementations, and reviews its use cases, features, and best practices.
Learn why inter-VLAN routing is required, understand the different models used for implementing it, and follow examples to configure it.
A DNS sinkhole is used to block malicious DNS requests. In this article, learn how the DNS sinkhole works, understand its limitations and best practices, and follow step by step instructions for setting it up.
Learn how to run a traceroute command, interpret the results, and understand the common problems that it reveals.
Understand how switching loops are created and learn the best practices for preventing them using the spanning tree protocol and portfast mode.
Learn the best practices for designing and implementing SD WAN security including Internet Key Exchange (IKE), Authentication Headers (AH), and Encapsulating Security Payload (ESP).
Learn multicast concepts and the different types of multicast forwarding path trees and multicast routing protocols by following examples.