Smarter DNS Policies: What You Should Be Blocking (But Probably Aren’t)

DNS filtering is a foundational layer of defense and helps to fortify the strongest security stacks. Most organizations use DNSFilter to block the obvious: malware, phishing, and adult content. That’s a great start, but many are missing out on the broader potential of DNS policies.

Let’s explore some of the underutilized content categories you should be blocking and how to customize policies for the most granular control.

DNS Policies: The Core of the Network Protection

DNSFilter policies are rule sets that determine which web content categories are allowed or blocked for users on your network. They're a critical tool for shaping Internet access in a way that supports security, productivity, and compliance.

While most admins configure the basics—blocking security threats and NSFW content—there are other categories that deserve your attention.

The Top 4 Underblocked Content Categories

The Parked Sites & Domains category is only blocked in 24% of policies. These domains may no longer be controlled by the original owner and are often taken over by malicious third parties to host threats.

The Contentious & Misinformation content category only appears in 21% of DNSFilter policies. This category is defined as sites that are contentious, often causing argument or controversy, characterized by strong opposing arguments, as well as sites that spread or aid in the spreading of misinformation. This category can have negative impact on productivity, as well as company culture.

Only 17% of policies include the Suspicious & Deceptive category. This category is for risky websites suspected of association with scams, risky software and/or unwanted activity. These include, but are not limited to, host abuse, URL shorteners, suspicious trackers, suspected typosquatting, potentially unwanted applications, disreputable businesses, and fast scam stores.

Only 12% of policies include Newly Observed Domains. These are characterized as domains observed in DNS traffic for the first time within the last 30 days, which have a higher likelihood of potentially malicious or unwanted activity. Blocking the Newly Observed Domains category provides an enhanced level of threat protection. Find more on new domains in our Q1 Security Report.

While there are plenty of content categories that don’t need to be blocked on most networks, the lesser-known categories above are likely to harbor threats.

When you go beyond blocking the basic threat categories, you set your organization up to improve productivity and stop some of the more novel, unique threats before they even get a chance. 

And when different levels of access are needed, you can lift the restrictions based on location, user, or device.

DNS Policy Hierarchy

Tailoring your DNS policies based on location, device, or user allows more granular control over Internet access and improves both security and user experience.

When building your DNS filtering policies, it’s important to consider: 

1. Who needs access to what?
2. Which devices are being used?
3. Where will the users be accessing the devices?

Breaking It Down: The Coffee Shop

Let’s pretend you are setting up new DNSFilter policies for your coffee shop. There will be different levels of access needed based on device, but also based on user. 

Safety Blanket: Your Network Policy

To ensure that your entire network is covered, it’s a good idea to start off with a blanket policy that protects all devices on your network. This would typically be where you would toggle on all of the threat categories and any other categories that are in line with the security guidelines for your organization.

Securing your network with a blanket policy via network forwarding is a great way to protect your network even when you don’t control the devices accessing it (like with your guest Wi-Fi).

We’ll talk about this in a bit, but keep in mind that you can override the categories blocked on your network later on with a more specific user-based policy.

Securing Individual Devices

Point-of-sale (POS) devices only need basic Internet access—your baristas don’t need to be scrolling their Instagram feed while taking orders, they just need to be able to send orders in and accept payments. These devices would require a Roaming Client with a very locked down Block list for the highest level of security.

However, your back office may have a PC that is used for placing inventory orders, managing payroll, and creating schedules. This device would need slightly looser restrictions in place to ensure that users can actually do their jobs.

Separate Policies for Users

As far as users, different access will be required for a barista than for the store manager. Additionally, the owner of the store may need a higher level of access than the marketing manager.

Users can have DNSFilter policies applied individually, or grouped within collections.This may look like the coffee shop’s social media marketer having access to social networking content while baristas are grouped into a collection with the highest restrictions. Read more on collections in our Help Center.

How Are Policies Enforced?

User-based policies are the highest priority and will override a device-based or network-based policy. Additionally, Allow lists will override Block lists. 

Utilizing Allow lists on user or collection policies will ensure that you can lock down a broader policy across your network without impeding access for those who need it.

This structure ensures that your most targeted policies always have the final say and gives you precise control.

The Balance of User Experience & Security Posture

DNS filtering policies are an intelligent, adaptable layer of your cybersecurity stack. By revisiting your policies, exploring lesser-known content categories, and using hierarchy strategically, you can dramatically improve your network’s security posture without frustrating end users.

The DNSFilter team recently presented a webinar on this topic and covered some of the most-blocked categories, additional content categories you should be blocking, and walked through creating new policies for scenarios similar to those above. 

Watch Building a DNSFilter Policy: What You Should Be Blocking on-demand now.