After you have Tested Your Connection with one computer to DNSFilter servers, you can change your network configuration to point all outbound DNS traffic to our servers. This will ensure comprehensive filtering and security coverage for all devices on your network.
Depending on how your network is setup, there are several different ways to make the change:
- If you operate an Active Directory environment, you can configure DNSFilter as your Forward Zone.
- If you run a non-AD environment, you can configure DNSFilter on your:
- Router (good for smaller networks)
- DHCP Server (good for any size network and for use with NAT IPs )
- Firewall (can be used standalone to force query traffic or in concert with router/DHCP options)
Do not mix DNS Providers
Many DNS clients are configured to send queries in a round-robin style. Because of this, it is necessary only to list DNSFilter servers on your configuration. Otherwise, some queries will not come to us and will escape the filtering policies that you have set.
Do not assign DNS directly to endpoints
It is recommended that you do not assign DNS Filter's servers directly to your client devices. This is because you will break resolution with local named resources (servers, computers, printers). It is far better to set DNSFilter as a DNS forwarder through the means outlined in this article.
Configure DNSFilter on Active Directory
Many larger organizations utilize Microsoft Active Directory to manage their computing resources. DNSFilter can be configured as a Forward Zone so that your entire network is protected by a filtering Policy. Only a simple configuration change is required, and there is no interference on your LAN. You can also install our Roaming Client via Active Directory so that individual devices have different policies. This is useful in situations where staff or executives need to have an alternate policy from the main site.
As shown in the diagram below, the endpoints are already set to communicate with Active Directory for DNS resolution. When local queries are sent, they are resolved by the Domain Controllers. When an internet query is sent, the Domain Controller recognizes that it cannot resolve locally, so it will send the queries to DNSFilter for resolution. DNSFilter never sees or charges for your local queries.
The fastest way to configure DNS forwarding is by logging on to the Domain Controllers and issuing the PowerShell command below to replace the forwarders with the DNSFilter Anycast IPs.
# Get the current list of forwarders
# Useful to save before overwriting
# Set forwarders to DNSFilter
Set-DnsServerForwarder -IPAddress '126.96.36.199','188.8.131.52' -UseRootHint $False -PassThru
You may also refer to the screencast below for the GUI method of replacement:
Once this has been set, changes will instantly take effect. This is because LAN devices already go to the Domain Controllers (DCs) for resolution. The DCs will now forward internet queries from all devices through DNSFilter and allow/block based on what you have set in the dashboard.
If you wish to put some devices on a different policy, you can install our Roaming Client via Active Directory.
Configure DNSFilter on Your Router
Setting DNSFilter servers on the router is a common setup for smaller locations, such as in a small office/home office (SOHO). This configuration uses the router as a DNS forwarder. Queries from network clients go to the router for resolution. The router then sends WAN queries through the network gateway to DNSFilter.
- Home / Personal
- Small Offices
- No Local Authentication (Active Directory, LDAP, Radius, etc)
Due to the variety of router manufacturers in existence, DNSFilter does not provide directions for this procedure. You should easily be able to find this by searching Google for the instruction manual for your particular make and model of router. You will look to add the DNSFilter Anycast IPs into the DNS forwarding section of your router's configuration.
Configure DNSFilter on Your DHCP Server
You may use your DHCP server to hand out DNSFilter’s IPs directly to clients. Remember the warning at the beginning of this article that to do so will break local by-name resolution (e.g. Jeff-PC, Jane-Printer). On some networks, this may not be an issue, such as Guest WiFi.
This configuration is also desirable for utilizing our NAT IPs feature, which allows you to create multiple filtering policies that correspond to your network subnets.
- Guest Wi-Fi
- No LAN Resources (printers, servers, resource sharing)
- Utilizing the NAT IPs feature
Due to the variety of equipment manufacturers in existence, DNSFilter does not provide detailed directions for this procedure. If you are using a router, this setting is commonly found under the "DHCP Server" section of the configuration. You will replace the DNS server IPs with the DNSFilter Anycast IPs. For Cisco Meraki equipment, there are instructions here.
Configure DNSFilter on Your Firewall
Hardware firewalls / virtual appliances can be configured to forward DNS queries to DNSFilter, regardless of what network clients have set on their network adapters. This is useful in scenarios where users are likely to attempt to circumvent the filtering by changing the DNS settings on their device. It is also useful if your Internet Service Provider is running a transparent proxy (redirecting DNS queries to their servers) because you can forward queries to port 5353 or 5354(udp only).
- School networks
- ISP has a transparent proxy
- Locations where users have access to change their DNS settings
In order to set this on your firewall, you'll create either a NAT rule or port-forwarding rule to set all UDP and TCP port 53 traffic to DNSFilter's Anycast IPs. You can check the Preventing Circumvention and Transparent Proxying articles for example of firewall rules that can be set.
Check packet size
The DNS protocol originally had a 512-byte maximum packet size. Modern usage of the DNS protocol can sometimes require a packet size of up to 4096 bytes. If the firewall is set to block/drop DNS packets less than 4096 bytes, this could result in DNS timeouts. Please check your firewall ruleset to be sure.
Connection Ports / Protocols
In order to enable customers to overcome Transparent Proxying, DNSFilter receives DNS traffic on the following ports:
- 53 (udp/tcp)
- 5353 (udp/tcp)
- 5354 (udp)
- 853 (tcp)(DNS-over-TLS)
DNSFilter fully supports DNSSEC by pointing your equipment to these DNS addresses:
- Low internet adoption - Most internet domains (including well-known email providers) do not support DNSSEC, which means turning the feature on will cause failures in resolving a large portion of internet domains. This will be perceived by the end user as a failure with their ISP or with our service.
- DNSSEC outages - Even domains which do support DNSSEC have been known to have failures that last several days or weeks.
In a multi-site environment, systems should be configured to use the DNS servers at their local site before those at a different site. This minimizes the amount of DNS traffic crossing slower WAN links.
If you have a multi-site environment, but only a single DNS resolver for all sites, the site where the DNS resolver is located will ultimately determine the policies applied to the traffic for all sites. To allow for site-specific policies (based on each site’s IP address), the DNS queries must not traverse your WAN and instead should go directly to DNSFilter via the respective site’s internet connection. If placing DNS servers at each site is not feasible, there are a few solutions to ensure local domain DNS queries are resolved correctly, and internet domain DNS queries do not traverse your WAN to a single site:
- Deploy Roaming Client: By installing our Roaming Client on the systems and configuring Local Domains, DNS queries for internal resources will be sent to your internal DNS resolver while DNS queries for internet domains will be resolved by the Roaming Client and policies assigned to the Roaming Client will be enforced.
- Deploy Relay: By placing a Relay at each site without an existing DNS resolver and configuring Local Domains, DNS queries for internal resources will be sent to your internal DNS resolver while DNS queries for internet domains will be resolved by the Relay and policies assigned to that Relay and that site’s LAN Subnet(s) will be enforced.
Article is closed for comments.