Introduction
Virtually every page (or page element) that’s accessed via the Internet is first looked up in the Domain Name System (DNS). This means that those DNS lookups represent a unique opportunity whereby companies can keep users from inadvertently “hurting” themselves. Summarizing this in bullet point format:
- Sites may be known to be dangerous (for example, sites that are known to be malware-infected, phishing sites, etc.)
- Users may be routinely lured (or tricked) into visiting those dangerous sites
- You could potentially warn or block access to those sites by making local modifications to the DNS
This is the fundamental concept behind protective DNS services: Use DNS services to shield users from many known dangerous sites. Some people refer to this as “protective DNS” or using a “DNS firewall.”
At its most basic, protective DNS services may refuse to resolve a known-dangerous domain name, reporting that the bad domain doesn’t exist (returning “NXDOMAIN” to user queries). Other times, sites may attempt to take advantage of a potential “teachable moment,” redirecting the user from a dangerous site to a safe alternative web site that explains that they’ve just been protected from accidentally getting infected with malware (or from visiting a phishing site). Either way, the outcome is the same, and good – a user HASN’T had their system infected (or their information stolen by a cyber attacker)!
So How Do I Do This? Build or Buy?
Those who may be open to “rolling their own” protective DNS cybersecurity solution can use DNS RPZ as a critical “building block” for a protective DNS project. See https://dnsrpz.info/ or check out https://datatracker.ietf.org/doc/html/draft-vixie-dnsop-dns-rpz-00 (an expired draft by Paul Vixie and Vernon Schryver).
Some might consider combining the DNS RPZ protocol with DomainTools Hotlist). Another potential source of protection is NOD/NAD/NOH. Both might serve as a pretty good data foundation for a basic protective DNS system.
Commercial cybersecurity companies also produce a variety of ready-to-use protective DNS services, either “on-premises” or “in-the-cloud.” A representative assortment of these companies includes:
- Akamai Secure Internet Access
- BlueCat Networks DNS Edge
- CIRA DNS Firewall
- Cisco Umbrella DNS SE
- Cloudflare Gateway
- Comodo Secure Internet Gateway
- DNSFilter
- FlashStart DNS Filtering
- EfficientIP DNS Guardian
- HYAS Protect
- Infoblox BloxOne Threat Defense Cloud
- Mimecast DNS Security
- Neustar UltraDNS
- NexusGuard DNS Protection
- Nominet Protective DNS
- OpenDNS
- PaloAlto Networks DNS Security
- Quad9
- SafeDNS
- ScoutDNS
- ThreatSTOP DNS Defense
- TitanHQ ArcTitan
- Verizon DNS Safeguard
- Webroot DNS Protection
- WebTitan DNS Filter
Other protective DNS services are available solely to government agencies and similar specifically-approved users, such as:
- The UK National Cyber Security Centre Protective Domain Name Service, provided by Nominet
- The US NSA/CSS Protective Domain Name Service, provided by Accenture
Protective DNS Services Are NOT “Censorware” Products
Protective DNS services are NOT focused on attempting to block network access to “user-WANTED” content. Some user-WANTED content might be business INappropriate, but protective DNS is NOT about trying to censor that sort of “consensual” access.
Protective DNS is about “keeping you from accidentally stumbling into a minefield,” not keeping you from watching a hockey game during your lunch hour (or going shopping during your break). This difference is important – EVERYONE wants to avoid “stepping on a mine” (or the online equivalent thereof). Attempting to prevent users from going somewhere they WANT to go, well, that can be quite hard. As John Gilmore once said, “The Net interprets censorship as damage and routes around it.”
Some Challenges to Protective DNS Approaches
Before relying on a protective DNS service, be sure you understand some of the limitations to this approach:
- Protective DNS services can’t help if attackers don’t rely on the domain name system. For example, some malware or phishing attacks may use raw IP addresses (rather than domain names) in an effort to avoid DNS-based filtering. Other attackers may deploy DNS over HTTPS as a hidden internal “parallel” application-specific resolver service, intentionally bypassing the user’s normal DNS service by deploying their own alternative dedicated DNS service.
- Protective DNS services can’t help if users don’t (or won’t) use the protective DNS service. Some users may use another DNS service because that’s what their web browser uses “by default.” Other users may intentionally select a third party DNS service (such as 1.1.1.1, 8.8.8.8, or 9.9.9.9) because they think those services may be “faster” or “more private” than the protective recursive resolvers you provide for them. Depending on the alternative 3rd party DNS service users may choose, their choices may leave them without protective DNS coverage.
- Speaking of choices, most corporate users use the DNS servers their company provides by default. Similarly, most residential Internet users use the DNS servers their Internet Service Provider provides by default. Third-party VPN users, however, will normally use the DNS service the 3rd-party VPN service provides for them by default (at least whenever they’re using that 3rd-party VPN service). Many users of 3rd-party VPNs may not be aware of this.
- Users who use the same laptop (or smartphone or tablet) at the office AND at home (or at the office AND while traveling, or at the office AND while out at a coffee shop or having lunch) may only be shielded by a protective DNS service PART of the time – e.g., while in the office. They may end up using a non-protected recursive resolver the rest of the time. Patchwork protective DNS coverage of this sort is risky. Threats don’t target you only while you’re at the office!
- Pick a provider whose blocking policies meet your wants and needs. For example, do you only want to block malware and phishing? What about other unwanted content, such as online advertising? Some providers may ALSO block that, but blocking advertising may also result in some sites preventing you from visiting their site at all (e.g., “Won’t accept ads? Okay, no access to our site then!”)
- Protective DNS protection is only as good as the threat intelligence driving the protective DNS service. Good threat intelligence seeks to minimize both false negatives AND false positives:
Unfortunately, threat detection is a statistical matter, and minimizing false negatives normally tends to increase false positives (and vice versa) – you can’t simultaneously minimize both.
- Use of a 3rd-party protective DNS service may have privacy implications. Why? Well, recursive resolver operators have the ability to see what you’re doing online, literally query-by-query. Be sure you trust your recursive resolver provider, whomever that may be, to protect the potentially-sensitive data you’re sharing with them.
Conclusion
You now know the value of domain name service as a potential control point for dangerous online content: it is truly one of the few places where users can be protected from online badness at scale and with comparative ease. At the same time, you now also understand what protective DNS (and isn’t) – it’s not “nannyware,” and normally requires users to welcome (rather than attempt to avoid) the protection provided. You now also know that operators of recursive resolvers can tell a LOT about what you’re doing online, so it is critical that you trust the privacy policy of the DNS service you’re using.
We hope this article provides a good overview of what protective DNS is and is not, examples of how to implement a protective DNS service for your users, and an overview of some potential challenges to keep in mind.
If you have any questions about this article or would like to know more about the DomainTools Hotlist, please don’t hesitate to contact us:
