Company Blog


Uncle Sam Wants You... To Control Outbound DNS

The U.S. Department of Homeland Security’s Computer Emergency Readiness Team (US-CERT) released an alert on Aug. 28, 2015, regarding the importance of controlling outbound DNS access ( In particular, US-CERT notes an increase in the number of client systems sending queries directly to Internet name servers, and stresses the need to prevent this, both for security’s and efficiency’s sake.


I’ve been saying this for years!

There are two common security policies with respect to outbound Domain Name System (DNS) access.  Some organizations allow any internal Internet Protocol (IP) address to send DNS queries to any name server on the Internet.  In fact, that’s the default policy in some Internet firewalls.  This provides a lot of flexibility, of course:  Users can configure their clients to use OpenDNS or Google Public DNS instead of their IT department’s name servers, and an experienced user can use a DNS query tool such as dig or nslookup to troubleshoot DNS resolution problems.


Other organizations only permit a limited set of authorized internal name servers to send DNS queries to Internet IP addresses.  Users must use the approved set of internal name servers to resolve domain names; they can’t just opt to use OpenDNS or Google Public DNS, and troubleshooting DNS problems is more cumbersome.


Admittedly, I was a little late to the “limited DNS access” party, requiring a nudge from my friend Nate Campi to accept the wisdom of not allowing internal stub resolvers and name servers to query any old Internet name server they like (see this 2012 blog post for my mea culpa).  The last straw was DNSChanger, a Trojan that reconfigured stub resolvers to point them to hostile open recursive name servers on the Internet, which would substitute, uh, legitimate web advertising with advertising from another company (see this Wikipedia article for details).


Given that the DNSChanger infrastructure has been taken down, what’s the danger of allowing queries from internal clients to any Internet name server?

  • Subverting DNS security mechanisms, such as Response Policy Zones.  More and more often, enterprise name servers employ security mechanisms such as RPZ to protect internal clients from the resolution of known malicious domain names or resolution to known malicious IP addresses.  Sending queries directly to Internet name servers circumvents these mechanisms.
  • DNS tunneling.  Allowing traffic directly between internal clients and Internet addresses makes DNS tunneling trivial.  If your firewall isn’t smart enough to distinguish legitimate DNS traffic from, say, file transfers, malware may be able to easily exfiltrate your data to servers on the Internet masquerading as name servers by running on UDP or TCP port 53.  Even if your fancy-schmancy, application-smart Internet firewall does recognize DNS traffic, malware can use sophisticated techniques for tunneling data in DNS queries or responses that your firewall may not catch.
  • Loss of visibility.  If you log name resolution requests from your internal clients, you’ve got a goldmine of forensic data:  If there’s a breach, you can determine where the bad guys went, what internal resources they accessed, and more.  If your clients use an external name server, you’ve lost that data.
  • Loss of efficiency.  One of the operational benefits of funneling queries through a set of well-connected internal name servers is that your clients can take advantage of the rich cache of data those name servers accumulate.  If all your clients independently resolve domain names using different Internet name servers (or even local name servers), they can’t capitalize on that shared cache.

For all these reasons, it’s a best practice to restrict outbound DNS queries to only authorized internal name servers. Generally speaking, this is a subset of your internal name servers designated as forwarders, to which other internal name servers forward DNS queries they can’t answer, including queries for Internet domain names.  That’s just a simple firewall rule, but adding it can have wide-ranging positive effect.


‎09-09-2015 03:56 PM

Incredible that only now, in 2015, that people are talking about filtering OUTBOUND data. DNS is great, no question, but ALL outbound data should be scanned/logged, and potentially filtered. I did security assessments, vulnerability assessments, and penetration tests for years (2003-2006) and found without exception that no organization filtered or even looked at outbound data. Everyone assumed that they should only care about inbound "bad stuff."


Great to see CERT finally commenting on this, at the very least with respect to DNS and maybe from here they'll start recommending this for all outbound data.



Showing results for 
Search instead for 
Did you mean: