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.
Cloud Webinar Series: Part 2
Regain control of DDI infrastructure and accelerate delivery of critical DNS services to cloud teams.
Yes, you can optimize DNS routing for global SaaS use
Routing DNS for SaaS can lead to latency, non-local results, and messy internet breakouts. With BlueCat, optimize SaaS delivery and gain full DNS control.
Yes, you can tame hybrid cloud DNS traffic jams
Admins often use messy conditional forwarding DNS rules to fill hybrid cloud gaps. With BlueCat, automate and gain control over your data pathways.
Yes, networking can extend DNS control into the cloud
When cloud and on-premises DNS are separate, enterprise-wide control is out of reach. Learn how BlueCat can provide a single source of truth for DNS.