OpenDNS is a powerful tool to control Internet access on both enterprise and home networks. The ability to manipulate DNS responses based on categories and analytics along with policy customizations can protect users from known threats and provide a layer of content filtering. However, the network needs to route all outbound DNS queries through OpenDNS to be effective. With well known public DNS offerings such as Google’s 8.8.8.8, everyone from malicious application developers to benevolent slightly technical users can easily specify alternate DNS servers. What controls do OpenDNS provide when a simple configuration can bypass them? The answer is very little, however network controls such as firewall and NAT policy can help lock that down.
Enabling the service is fairly simple, just point your recursive DNS servers or clients to the IPs of the OpenDNS servers (208.67.222.222 and 208.67.220.220). The setup guides cover various types of devices and provide a test link to verify OpenDNS is handling DNS lookups. In my case, the setup is on an Edgerouter Lite based on Vyatta code. The configuration below directs the router to send all DNS queries to OpenDNS while the default internal DHCP options direct all clients to use the Edgerouter for DNS.
ubnt@ubnt: ~$ show configuration commands | match name-server
set system name-server 208.67.222.222
set system name-server 208.67.220.220
To ensure all DNS queries route through OpenDNS, there are a few extra steps for devices that are capable. Two basic options are discussed below.
Option 1 - Firewall Policy
Some guides cover this, but you can configure a firewall policy to block any outbound DNS query not directed to OpenDNS. This is fairly simple and effective from the network perspective. If a DNS resolver tries to contact a server other than OpenDNS, it has to detect a timeout and handle a retry appropriately.
For our Edgerouter, this firewall policy will block outbound port 53 on the LAN interfaces eth1 and eth2. DNS queries to the router itself on the local LAN will be ignored.
ubnt@ubnt:~$ show configuration commands | match LAN_IN
set firewall name LAN_IN default-action accept
set firewall name LAN_IN description 'Traffic from LAN'
set firewall name LAN_IN rule 22 action drop
set firewall name LAN_IN rule 22 description 'Internet DNS'
set firewall name LAN_IN rule 22 destination port 53
set firewall name LAN_IN rule 22 log disable
set firewall name LAN_IN rule 22 protocol tcp_udp
set interfaces ethernet eth1 firewall in name LAN_IN
set interfaces ethernet eth2 firewall in name LAN_IN
After the firewall policy has been applied, verify their effectiveness. A lookup to a random internet site (www.aol.com in this case) will be successful with the default local nameserver.
C:\>nslookup www.aol.com
Server: Unknown
Address: 192.168.10.1
Non-authoritative answer:
Name: ipv4.portal.aol.com.aol.akadns.net
Addresses: 34.202.119.59
52.7.156.60
Aliases: www.aol.com
portal.aol.akadns.net
The same lookup will fail when directed to Google’s 8.8.8.8 because traffic is blocked.
C:\>nslookup www.aol.com 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
Server: Unknown
Address: 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to Unknown timed-out
You can verify the firewall rule counters also, which show how many packets have been blocked.
ubnt@ubnt: ~$ show firewall statistics
----------------------------------------------------------------------------------
IPv4 Firewall "LAN_IN" [Traffic from LAN]
Active on (eth2,IN) (eth1,IN)
rule packets bytes action description
---- ------- ----- ------ -----------
22 133 9307 DROP Internet DNS
10000 1778 980898 ACCEPT DEFAULT ACTION
----------------------------------------------------------------------------------
Option 2 - NAT Policy
You can configure a NAT policy to reroute all outbound DNS queries to the OpenDNS servers. This is my preferred setup as client DNS queries are silently redirected without error. This also allows OpenDNS to log and process any port 53 traffic.
Here is the NAT policy that is applied on both LAN segments which use different subnets. The Edgerouter is listening on both already.
ubnt@ubnt: ~$ show configuration commands | match "nat rule"
set service nat rule 1 description 'LANI DNS Redirect'
set service nat rule 1 destination port 53
set service nat rule 1 inbound-interface ethl
set service nat rule 1 inside-address address 192.168.10.1
set service nat rule 1 inside-address port 53
set service nat rule 1 1og disable
set service nat rule 1 protocol tcp_udp
set service nat rule 1 type destination
set service nat rule 2 description 'LAN2 DNS Redirect'
set service nat rule 2 destination port 53
set service nat rule 2 inbound-interface eth2
set service nat rule 2 inside-address address 192.168.20.1
set service nat rule 2 inside-address port 53
set service nat rule 2 1og disable
set service nat rule 2 protocol tcp_udp
set service nat rule 2 source
set service nat rule 2 type destination
set service nat rule 5010 description 'masquerade for WAN'
set service nat rule 5010 outbound-interface eth0
set service nat rule 5010 type masquerade
Performing the same DNS lookups above, the nat policy can be verified by looking at active translations. In this case however, the DNS query did not fail with timeouts.
ubnt@ubnt: ~$ show nat translations destination
Pre-NAT Post-NAT Type Port Timeout
8.8.8.8 192.168.10.1 dnat udp 20
8.8.8.8 192.168.10.1 dnat udp 20
8.8.8.8 192.168.10.1 dnat udp 20
Nothing is Perfect
While these methods work for standard DNS traffic, determined individuals can still get around OpenDNS. For example, if an application sends queries to a port other that 53 then neither of these approaches will apply. However, these will catch the most common DNS setups that rely on standard port 53 Internet lookups.
Implications with IPv6
There is one area OpenDNS is currently lacking, and that is with IPv6 DNS service. While making IPv6 DNS servers available, they do not currently perform any query filtering. Therefore you will want to ensure your clients and/or network devices are not using them. Additional firewall policies can be applied to block IPv6 DNS queries which should force a fallback to IPv4 DNS queries.