Which top-level domains to block and how to do it right
Identifying malicious top-level domains to block is easy enough. But you can take it further with BlueCat to spot devices querying bad TLDs to begin with.
Key takeawaysThis key takeaway was generated through LLMs crawling the page and coming up with an overview of the content.The article explains why organizations should block malicious top-level domains (TLDs) and how assessing and enforcing those blocks is most effective at the first-hop DNS layer. It outlines the growth of many new TLDs since 2012, notes that some TLDs are overwhelmingly abused for spam and malicious activity, and describes the operational challenge of tracing queries when blocking only at network boundaries. The article argues BlueCat’s first-hop recursive DNS approach lets admins enforce policies per device, identify offending hosts, and prevent lateral movement and DNS-based data exfiltration.
What is a top-level domain (TLD) and why are some TLDs considered more risky?
A top-level domain (TLD) is the portion of a web address after the final dot (for example, .com or .edu). Since restrictions on TLDs were removed in 2012, many new TLDs have proliferated and some registries are heavily abused. Certain newer TLDs are used predominantly for malicious purposes—spam, phishing, or hosting malware—and in extreme cases over 90% of domains in a TLD can be malicious, making those TLDs high-risk and candidates for blocking.
Why are boundary-level filters and firewalls insufficient for blocking malicious TLD activity?
Boundary-level filters and firewalls can block external connections and leverage threat feeds to block known bad domains, but they lack visibility into which internal device originated the DNS query. They typically only see the recursive server that forwarded the request, so locating the source device requires correlating data across recursive layers—a complex task. As a result, boundary defenses often treat symptoms without enabling administrators to trace or remediate the infected internal host triggering the malicious queries.
How does a first-hop DNS solution help prevent and investigate TLD-related threats?
A first-hop DNS solution sits at the device-facing recursive server and enforces security policies on every DNS query before it progresses up the network. By applying user-defined rules to monitor, block, redirect, or allow queries, admins can see which specific device generated queries to malicious TLDs and take remediation steps. Additionally, first-hop enforcement can block lateral movement and DNS-based exfiltration inside the network, addressing internal threats that boundary-only controls cannot detect or stop.
When they range from .guru to .xyz, how do you know which top-level domains to block?
And what is a top-level domain (TLD), anyway? Basically, it’s everything after the dot in a website address.
There used to be just six generic TLDs that we all knew and loved. These generic top-level domains were .com, .edu, .org, .net, .gov, and .mil.
In 2012, restrictions on TLDs ended, essentially allowing anyone to register a domain. Today, TLD registries show that just half of web addresses end in .com.
But even if you determine which TLDs to block, how do you best go about blocking them?
This post will explore the extent of top-level domains to block and the basics of blocking them. It will also discuss the limitations of network boundaries for blocking TLDs. Finally, it will explore the benefits of a first-hop solution to rid queries for TLDs from your network altogether.
How many top-level domains to block are there?
The worst of these newer TLDs are used almost exclusively for malicious purposes. They’re significant sources of spam and other malicious activity. Owners of abused top-level domains are either turning a blind eye or actively complicit in it.
The amount of abuse is remarkable. Spamhaus has a top ten index of the world’s most abused TLDs. In February 2021, the champion was .fail, but the rankings change all the time.
Sometimes, malicious activity is behind over 90% of the domain listings in a TLD. In other instances, the total number of domains with bad intent may be lower. But the overall volume is still high enough to merit caution with that TLD.
Just block top-level domains and you’re done, right?
When thinking about how to block top-level domains, is it enough to just block it and be done?
No Domain Name System (DNS) query from a corporate network should resolve top-level domains with a record of malicious activity. The best option in these cases is usually to block the TLD entirely.
But beyond simple blocking, security personnel should investigate where that query is coming from. It’s tempting to declare victory when the query itself doesn’t resolve. But wouldn’t you want to know if malware on the source device is generating these queries?
That’s where the specific IP addresses and associated devices that attempt to connect with those blocked internet domains become important.
To block top-level domains, boundaries only go so far
Just about every corporate network uses filters and firewalls on the network boundary. Some of these have the capability to block DNS queries and specifically those associated with malicious TLDs. There are plenty of threat feeds out there that can block bad domains en masse.
However, there is a hitch. Boundary-level filters and firewalls can block external connections to bad TLDs. But they usually have no visibility into which device on the network generated that DNS query to begin with.
They basically treat the symptoms without offering a cure for the root cause.
Why they fall short has to do with how most networks are architected. Filters or firewalls only see the recursive server that last forwarded the DNS request.
Tracking the DNS query back to the source device requires correlating the data between these recursive layers. That’s a huge task.
Block TLD suspects with a first-hop solution
Instead of assessing TLDs at the network boundary, BlueCat does it at the device level.
BlueCat takes the place of the “first hop” recursive server. It applies security policies to every DNS query that comes from a device before it moves up the network hierarchy. Based on user-defined parameters, policies can monitor, block, redirect, or allow a query to resolve.
Unlike boundary-level filters and firewalls, with BlueCat, you can actually see which device is producing queries to a malicious TLD. Admins can both deal with the suspect request and trace it back to a specific device.
Another advantage of being at the first hop is the ability to block lateral movement within a network. Queries of known bad TLDs may be part of an advanced persistent threat to attempt to exfiltrate sensitive information through a DNS tunnel or a domain generation algorithm.
These threats rely on the inability of most admins to monitor and block internal traffic. With BlueCat, you can block both suspect activity inside the network and queries of an external malicious TLD.
Learn more about BlueCat’s network security features.
Published in:
BlueCat provides core services and solutions that help our customers and their teams deliver change-ready networks. With BlueCat, organizations can build reliable, secure, and agile mission-critical networks that can support transformation initiatives such as cloud adoption and automation. BlueCat’s growing portfolio includes services and solutions for automated and unified DDI management, network security, multicloud management, and network observability and health.
Related content
How to map your network with user-defined links in Integrity X
Map your network with user-defined links in Integrity X to define and manage custom relationships, such as dual-stack and NAT environments.
Automate your DDI modernization path by migrating with Micetro
Automate cross-platform DNS and DHCP migration with Micetro to reduce risk, eliminate manual effort, and modernize infrastructure faster.
Your journey to intelligent NetOps begins at Cisco Live
Visit BlueCat’s booth or book a meeting now to learn more about how our solutions can help you build a network that supports constant change.
Replace BIND and ISC with Micetro DNS/DHCP Server (MDDS)
Tired of patching and manually configuring BIND DNS and ISC DHCP? Discover how Micetro MDDS appliances can replace them for modern DDI.