Configuring DNS With pfSense

Configuring DNS With pfSense

Learn how to configure DNS with pfSense in this guest post by David Zientara, a software engineer with over 20 years of experience.

You may never have the occasion to set up your own DNS server, but there are compelling reasons to do so. Having your own DNS server can reduce administrative overhead and improve the speed of DNS queries, especially as your network grows. Moreover, the ease with which a DNS server can be set up with pfSense makes it that much more appealing.

It should be noted that pfSense has two separate services for DNS. Prior to version 2.2, DNS services were configurable via Services | DNS Forwarder, which invokes the dnsmasq daemon. For version 2.2 and later, Unbound is the default DNS resolver, and it is configurable by navigating to Services|DNS Resolver.

New installs of version 2.2 or above have DNS Resolverenabled by default, while upgrades from earlier versions will have DNS Forwarder enabled by default. You can still use DNS Forwarder on newer versions, but if you do, you will have to disable DNS Resolver or change the port settings for it. By default, both DNS Forwarder and DNS Resolver are configured to bind to port 53, and both services cannot bind to the same port.

DNS Resolver

The first tab is labeled General Settings and the first section on the page is General DNS Resolver Options. The first option is Enable, which enables unbound, and is checked by default.

The next option is Listen Port, which allows you to set the port used for responding to DNS queries. The default port is port 53. DNS traditionally uses port 53 and the User Datagram Protocol (UDP), although DNS also uses TCP for responses larger than a datagram, including DNSSEC and some IPv6 lookups. So take this into account when creating firewall rules for DNS.

The Enable SSL/TLS Service check-box, if checked, will allow the DNS resolver to respond to DNS over TLS queries, thus making clients less vulnerable to DNS-spoofing. The SSL/TLS Certificate drop-down box allows you to select the certificate to be used in such queries. The default port for DNS over TLS is 853, but you can change this by entering a different port number in the SSL/TLS Listen to Port edit box.

The Network Interfaces list box allows you to select which interface IPs are used by unbound to respond to queries from clients. Queries to interfaces that are not selected are discarded. If unbound is enabled, however, you must select either All or localhost for this option.

The Outgoing Network Interfaces list box allows you to choose which network interfaces the DNS Resolver may use to send queries to authoritative servers and receive their replies.

When there is no domain match from local data, System Domain Local Zone Type determines how the DNS Resolver handles the query. There are several options available in this drop-down box:

  • Deny: The DNS Resolver will only answer the query if there is a match in the local data. If there is no match, the query will be dropped silently.
  • Refuse: This option is similar to Deny, except that when there is no match from the local data, the rcode REFUSED will be returned, so the client knows the query was refused.
  • Static: The DNS Resolver looks for a match in the local data. If there is no match, it returns no data or nxdomain, but it will also return the Start of Authority (SOA) for the root domain, provided that such information exists in the local data.
  • Transparent: The DNS Resolver will answer the query from local data if there is a match. If there is no match in local data, the query will be passed to upstream DNS servers. If there is a match in the local data, but the type of data for which the query is being made doesn’t exist in the local data, the DNS Resolver will return a no error/no data message.
  • Type transparent: This option is similar to Transparent, but in where there is a match in the local data but the type of data being asked for doesn’t exist, the DNS Resolver will pass the query to upstream DNS servers.
  • Redirect: The DNS Resolver will attempt to answer the query from local data. If there is no local data other than the zone name, the query will be redirected.
  • Inform: Identical to Transparent, except that the client IP address and port number will also be logged.
  • Inform/Deny: Identical to Deny, except that the query will be logged.
  • No default: Default contents for AS112 zones will not be returned by queries.

The next option, enabled by default, is Enable DNSSEC Support. DNSSEC is a means of protecting DNS data from attacks that use forged or manipulated DNS data, such as DNS cache poisoning. If you enable it and the upstream DNS server to which you’ll be forwarding DNS requests does not support DNSSEC, the DNS resolution may not work.

The Enable Forwarding Mode checkbox allows you to control whether unbound will query root servers directly (if this option is unchecked) or whether queries will be forwarded to the upstream DNS servers. You should only enable this option if the upstream DNS servers are trusted. If you have enabled DNSSEC support, and you consider this to be important, you should also ensure that the upstream DNS servers provide DNSSEC support.

The next option is the Enable DNSSEC Support checkbox. This option is checked by default. DNSSEC provides a means of digitally signing DNS data. Although the roll-out of DNSSEC has been slow, it has become an increasingly popular method of thwarting DNS cache-poisoning. If the upstream DNS server does not support DNSSEC, enabling this option may prevent DNS resolution from working.

In general, Enable DNSSEC Support should be enabled unless you know the upstream DNS server does not support it. If DNS resolution does not work and you are troubleshooting the problem, you might try disabling this option.

Enable Forward Mode, if checked, will cause unbound to send queries to upstream DNS servers rather than querying root servers directly, which is what would happen if this option is unchecked. Leaving this option unchecked is the safer choice if Enable DNSSEC Support is checked, as DNSSEC has been deployed at the root level since 2010. If you choose to check both Enable DNSSEC Support and Enable Forwarding Mode, you will definitely want to make sure that the upstream DNS server supports DNSSEC.

The forwarding mode is necessary if you’re using a multi-WAN configuration, which does not have default gateway switching.

Register DHCP leases in the DNS Resolver allows you to register DHCP static mappings. This, in turn, enables the resolving of host names that have been assigned IP addresses by the DHCP server.

Register DHCP static mappings in the DNS Resolver is similar to Register DHCP leases in the DNS Resolver, except the former allows you to register DHCP static mappings instead of DHCP leases. The Custom Options button reveals a text box when you click on it. You can enter any additional parameters here.

The next two sections are Host Overrides and Domain OverridesHost Overrides allows you to configure a specific hostname to resolve differently than it otherwise would with the DNS servers being used by the DNS forwarder.

This can be used for split DNS configurations; it also provides one possible way of blocking access to certain sites (although the user could always defeat this measure by simply entering the correct IP address of the target domain).

Domain Overrides is similar, except that it allows you to specify a different DNS server to use when resolving a specific domain. This can be useful in certain scenarios; for example, if you have a Windows Active Directory configuration and DNS queries for Active Directory, servers must be directed to the Active Directory’s DNS server.

There are two sections called Host Overrides and Domain Overrides. The former is a powerful option as it allows us to force a hostname to resolve differently than it would with the DNS servers that were specified. This can be used in a number of different scenarios, such as split DNS configurations.

You can also use it to block access to certain sites, although the end user could circumvent this by entering the IP address of the site. It can also be used in incredibly arbitrary ways (for example, the Bing search engine, https://www.bing.com/, could be redirected to https://www.google.com/).

Clicking on the +Add button will bring up a page where you are asked to input the Host, the Domain, the IP address (the address to which traffic to the hostname specified in Host will be sent), and a brief Description. You may also enter additional hosts and domains.

If you want to specify a different DNS server when resolving certain domains, you can use Domain Overrides, which will allow you to specify the IP address of a different DNS server. This is useful in a number of cases: for example, to specify Active Directory DNS servers in Windows Active Directory setups.

The next tab is Advanced Settings. Here are some of the interesting settings:

  • Prefetch DNS Key Support: Enabling this option causes DNSKEYs to be fetched earlier in the validation process, thus lowering the latency of requests (but increasing CPU usage).
  • Message Cache Size: This controls the size of the message cache, which stores DNS response codes and validation statuses. The default size is 4 MB.
  • Experimental Bit 0x20 Support: The small bit size (16 bits) of a DNS transaction ID makes it a frequent target for forgery, which creates a security risk. One of the ways to improve the security of DNS transactions is to randomize the 0x20 bit in an ASCII letter of a question name. For example, the www.mydomain.com and WWW.MYDOMAIN.COM names will be treated the same by a requester but could be treated as unequal by a responder. It can thus serve as a sort of covert encryption channel and make DNS transactions more secure.

The last tab on the DNS Resolver page is called Access Lists. As the name implies, this tab gives you the ability to either allow or deny (and the denial can be either universal or only for nonlocal data, as we will see) access to your DNS servers for specified subnets (netblocks).

This can be useful if you need to have different policies for different networks, or if you need to grant access to your DNS servers to certain users, such as remote users connecting through VPNs. Click on the +Add button to add an access list entry; you can add as many as you wish. When the page loads, the first field on the page will be Access List.

Here you can specify a (parsed) list name. The second option is Action, which is a drop-down box. Here you can specify what will happen to DNS queries originating on the specified netblock. The currently supported  options are:

  • Deny Stops queries from the defined netblock. Queries are dropped silently.
  • Refuse: Stops queries from the defined netblock. Instead of dropping the query silently, it sends back a REFUSED DNS rcode.
  • Allow: Allows queries from hosts within the defined netblock.
  • Allow Snoop: Similar to Allow, but allows both recursive and non-recursive access from hosts within the defined netblock. This should only be configured for the administrator for such uses as troubleshooting.
  • Deny Nonlocal: Allows only authoritative local-data queries from hosts within the defined netblock; other queries are dropped silently.
  • Refuse Nonlocal: Also allows only authoritative local-data queries from hosts within the defined netblock; other queries send back the REFUSED DNS rcode.

The Description field allows you to enter a (non-parsed) description. Finally, the Networks field is where you enter the netblock (subnet) on which the access list takes effect. You must also select the CIDR of the subnet in the adjacent drop-down box. To the right, you can enter a description of this netblock. You can add the newly defined access list by pressing the green Add Network button at the bottom of the page.

DNS Forwarder

Although theDNS Resolver is the default DNS service in pfSense 2.2 and later, you can useDNSForwarderinstead. To do so, navigate to Services|DNS Forwarder and click on theEnable DNS forwarder checkbox (make sure to disable DNS Resolver first). Many of the settings for DNS Forwarder are identical to the DNS Resolver settings. In this section, we will focus on the settings that are unique to DNS Forwarder.

As with the DNS Resolver, you can register DHCP leases and static mappings, but there is also an option called Resolve DHCP mappings first. Invoking this option causes the DHCP mappings to be resolved before the names provided in theHostOverridesandDomainOverridestables.

Starting with pfSense 2.2, the DNS Resolver is the default DNS service. Although in many ways, it is more advantageous to use the DNS Resolver because it implements features not available in DNS Forwarder (for example, access lists), you can still use the DNS Forwarder. To do this, first, disable the DNS Resolver, then navigate to ServicesDNS Forwarder and enable the DNS Forwarder.

Although the DNS Forwarder lacks many of the features of the DNS Resolver, there is considerable overlap between the two, and thus our focus will be on features that the DNS Resolver does not have. You can register DHCP leases and DHCP static mappings with DNS Forwarder, just as you can with the DNS Resolver, but DNS Forwarder also has a unique option called Resolve DHCP mappings first, which allows you to resolve DHCP mappings before names in the Host Overrides and Domain Overrides tables (Host Overrides and Domain Overrides are examples of features available in both the DNS Resolver and DNS Forwarder).

The DNS Query Forwarding section has several unique options. The Query DNS servers sequentially checkbox, as the name implies, causes the DNS servers specified on the General Setup page to be queried sequentially instead of being queried at the same time.

The Require domain checkbox will drop DNS queries from upstream servers if they do not contain a domain (in other words, queries for plain names). The Do not forward private reverse lookups option, if enabled, results in the DNS Forwarder not forwarding reverse lookups for RFC 1918 private addresses (10.0.0.0 addresses, 172.16.0.0 to 172.31.0.0addresses, and 192.168.0.0 addresses).

The Strict interface binding checkbox causes the DNS Forwarder to only bind to the IP addresses of interfaces selected in the Interfaces list box. If this option is not enabled, DNS Forwarder will bind to all interfaces.

Some of the settings available in the DNS Resolver are also available in the DNS Forwarder, such as the ability to set the port for resolving DNS queries, and the ability to bind only to selected interfaces.

One significant limitation of the DNS Forwarder is that Strict Interface Binding does not work with IPv6 addresses. As with the DNS Resolver, the DNS Forwarder allows you to add Host Overrides and Domain Overrides, and there is a field for Custom Options as well.

DNS Firewall Rules

After you have been diligent enough to configure pfSense to act as a DNS server, it would be a shame if end users on your network could circumvent pfSense and specify whatever DNS server they want. Yet that’s exactly what most modern OSes allow the end user to do. The following screenshot shows part of the IPv4 configuration page in a recent version of Mint Linux:

As you can see, the end user has disabled automatic DNS configuration and specified one of the Google DNS servers instead. Thus, even if we have set up pfSense to act as the DNS server for the local network, the user’s computer will bypass pfSense and go directly to 8.8.4.4. Other than the fact that the user is subverting the policy we were trying to enforce, this is bad for a number of reasons:

  • Every time the user accesses a site that requires a new DNS lookup, their computer will only cache the results on his computer. If the user had used pfSense as his DNS server, the results of the lookup would be cached on the pfSense system, and therefore would be available to everyone else on the local network.
  • The user could specify a DNS server whose security has been compromised, and their computer would now be vulnerable to DNS cache poisoning and other attacks.

Fortunately, there are ways of preventing this sort of end user behavior. Although we have not covered firewall rules yet, it might prove useful to demonstrate how such rules can be used to block users from manually specifying a DNS server.

We know that DNS uses port 53 to communicate, so rules blocking or allowing port 53 traffic is what we need. Specifically, we need the following:

  • A rule allowing port 53 traffic on the LAN network whose destination is a LAN node.
  • A rule blocking all other port 53 traffic on the LAN network.

We begin by creating the rule allowing port 53 traffic to a LAN node. Using the top menu in the web GUI, navigate to Firewall | Rules and click on the LAN tab. There should already be at least two rules there: default Allow LAN to any rules for IPv4 and IPv6, respectively.

Since firewall rules are applied from top to bottom with the first rule encountered that applies to the traffic being applied, we want to create a rule above those rules. Otherwise, pfSense will apply one of the Allow LAN to any rules first to the DNS traffic, which will defeat the purpose of our rule. Therefore, we click on the green +Add button with an up arrow next to the word Add to create a rule at the top of the list.

We want this rule to allow traffic, so we leave the Action set to Pass. We know that DNS traffic uses the UDP protocol, so we set Protocol to UDP. Scrolling down, we leave the Source set to Any, but we want to change the Destination to LAN address.

We want to change the Destination port range to port 53, and we can do that either by selecting it in the From drop-down box, or by just typing 53 into the first Custom edit box. You can enter a brief description in the Description edit box (for example, Allow DNS to LAN nodes) and then click on the Save button, which will return us to the main Firewall page and the rules table for LAN.

We still need the rule to block all other DNS traffic. Actually, what we will be doing is creating a rule that blocks all DNS traffic on the LAN network and placing it after the rule we just created so that all DNS traffic on the LAN network whose destination is not a LAN address will be blocked.

It will be easiest to modify the rule we just created, so navigate to the rule in the table and, in the Actions column, click on the icon that looks like two sheets of paper to copy the rule. This will create a duplicate of the rule, which we can now modify. Change Action to either Block or Reject, and change Destination to any. You probably also want to change the Description (for example, Block all DNS). That is all you need to do, then click on Save.

When you return to the main Firewall page, make sure that the rule for allowing DNS traffic to a LAN node comes before the block DNS rule. If the order is incorrect, you can drag and drop the rules until they are in the correct order. When you are done, click on the green Apply Changes button at the top right of the page.

You probably want to confirm that the rules we added do what they are supposed to do, so go ahead and use nslookup to try to look up a domain name using a different server. The nslookup utility is available on Linux, Windows, and macOS, and by specifying a domain name as the first parameter and a DNS server as the second parameter, you can bypass the default DNS server, for example:

Copy

nslookup packtpub.com 8.8.4.4

The preceding command will do a DNS lookup for packtpub using one of the Google DNS servers. If the rules we created work, this should fail, while invoking the same command when omitting the second parameter (so nslookup will use the default DNS server) should work.

These rules can be fairly effective in preventing the end user from bypassing the pfSense DNS server, but there are at least two major flaws:

  • The rules only apply to the LAN network. On a larger network, there will be several network segments. We want a means of applying these rules to more than one network.
  • The end user can still defeat the rules we created by connecting to a VPN.

If you found this article interesting and want to learn more about pfSense, you can explore Learn pfSense 2.4. Written by David Zientara, Learn pfSense 2.4 follows a step-by-step approach to explain the basic functionality of pfSense 2.4 and covers everything you need to know to get started with pfSense.

Leave a Reply

Your email address will not be published. Required fields are marked *