The DNS Resolver in pfSense® utilizes
unbound, which is a validating,
recursive, caching DNS resolver that supports DNSSEC and a wide variety of
options. The DNS Resolver is enabled by default in current versions of pfSense.
By default, the DNS Resolver queries the root DNS servers directly and does not use DNS servers configured under System > General Setup or those obtained automatically from a dynamic WAN. This behavior may be changed, however, using the DNS Query Forwarding option. By contacting the roots directly by default, it eliminates many issues typically encountered by users with incorrect local DNS configurations, and the DNS results are more trustworthy and verifiable with Domain Name System Security Extensions (DNSSEC).
DNS Resolver and IPv6¶
The DNS Resolver is fully compatible with IPv6. It accepts and makes queries on IPv6, supports AAAA records, and has no known issues with any aspect of IPv6 and handling DNS.
DNS Resolver Configuration¶
To configure the DNS Resolver, navigate to Services > DNS Resolver
Checking this box turns on the DNS Resolver, or uncheck to disable this functionality. The DNS Forwarder and DNS Resolver cannot both be active at the same time on the same port, so disable the DNS Forwarder or move one service or the other to a different port before attempting to enable the DNS Resolver.
- Listen Port
By default, the DNS Resolver listens on TCP and UDP port
53. This is normal for any DNS server, as it is the port clients will try to use. There are some cases where moving the DNS Resolver to another Listen Port, such as 5353 or 54 is desirable, and then specific sources may be forwarded there via port forwards.
By default, the DNS Resolver listens on every available interface and IPv4 and IPv6 address. The Interface control limits the interfaces where the DNS forwarder will accept and answer queries. This can be used to increase security in addition to firewall rules. If a specific interface is selected, both the IPv4 and IPv6 addresses on that interface will be used for answering queries. The
unbounddaemon will only bind to the selected interface. Queries sent to other IP addresses on the firewall will be silently discarded.
- Outgoing Network Interfaces
By default the DNS Resolver utilizes all interfaces for outbound queries, so it will source the query from whichever interface and IP address is closest to the target server from a routing perspective. Selecting specific interfaces will limit the choices to only specific interfaces that may be used as a source of queries.
- System Domain Local Zone Type
This option determines the type of
local- zoneconfigured in
unboundfor the system domain. The zone type governs the type of response to give clients when there is no match in local data such as Host Overrides, DHCP hosts, etc. In each case, if there is a local match, the query is answered normally. The available types to govern non- matching responses are:
Drops the query and does not answer the client.
Notifies the client that the query was refused (Using
NXDOMAINresponse to the client.
This is the default behavior. If the query is for a name that does not exist locally, it is resolved as usual. If the name has a local match but the type is different, a
NODATAresponse is sent to the client
- Type Transparent
Similar to transparent, it also passes through queries where the name matches but the type does not. For example, if a client queries for an AAAA record but only an A record exists, the AAAA query is passed on rather than receiving a negative response.
Handles queries from local data and redirects queries for zones underneath the local zone (e.g. subdomains). This can be used to control queries for all subdomains under the given domain.
Answers normally, but logs the client query.
- Inform Deny
Denies and logs the query.
- No default
Disables any default content for the zone without affecting query behavior.
Enables Domain Name System Security Extensions (DNSSEC), which allows clients to trust the origin and content of DNS responses. This is enabled by default. DNSSEC protects against manipulation of DNS responses, such as DNS cache poisoning or other query interception, but it does not make the contents of responses secret. DNSSEC works best when using the root servers directly, unless the forwarding servers support DNSSEC. If upstream DNS servers do not support DNSSEC in forwarding mode or with domain overrides, DNS queries are known to be intercepted upstream, or clients have issues with over-size DNS responses, DNSSEC may need to be disabled.
- DNS Query Forwarding
Disabled by default. When enabled,
unboundwill use the system DNS servers from System > General Setup or those received from a dynamic WAN, rather than using the root servers directly. This is better for a multi-WAN scenario where fine control of DNS query routing is desired, but typically also requires disabling DNSSEC due to a lack of support by upstream DNS servers or other problems forwarding the queries.
- DHCP Registration
When active, internal machine names for DHCP clients can be resolved using DNS. This only works for clients that specify a hostname in their DHCP requests. The domain name from System > General Setup is used as the domain name on the hosts.
- Static DHCP
This works the same as Register DHCP leases in DNS forwarder, except that it registers the DHCP static mapping addresses instead.
- Custom Options
A text area for placing advanced directives for
unboundthat are not supported by the GUI directly. If
unbounddoes not start correctly after entering custom options, add
server:on a line before the custom options.
Custom DNS entries can be created in the Host Overrides section of the page. Host overrides can define new records, or override existing records so that local clients receive the configured responses instead of responses from upstream DNS servers. This is also useful for split DNS configurations (see Split DNS), and as a semi-effective means of blocking access to certain specific websites.
Multiple records may be defined for the same hostname, and all IP addresses will be returned in the result. This can be used to supply both an IPv4 (A) and IPv6 (AAAA) result for a single hostname.
We do not recommend using only the DNS override functionality as a means of blocking access to certain sites. There are countless ways to get around this. It will stop non-technical users, but it is easy to circumvent for those with more technical aptitude.
This field defines only the hostname portion of the DNS record (without the domain), e.g.
www. It may be left blank to make an override record for the domain itself (Similar to an “@” record in bind.)
This field is required, and defines the domain name for the override entry, e.g.
- IP Address
The IP address (either IPv4 or IPv6) to return as the result for a DNS lookup of this entry.
A text description used to identify or give more information about this entry.
- Additional Names for This Host
Defines additional hostnames for the same IP address (much like CNAME records) to keep them in a single override entry.
Domain overrides are found at the bottom of the DNS Resolver page. These entries specify an alternate DNS server to use for resolving a specific domain.
One example of where this is commonly deployed is in small business networks with a single internal server with Active Directory, usually Microsoft Small Business Server. The DNS requests for the Active Directory domain name must be resolved by the internal Windows Server for Active Directory to function properly. Adding an override for the Active Directory domain pointing to the internal Windows server IP address ensures these records are resolved properly whether clients are using this firewall as a DNS server or the Windows Server directly.
In an Active Directory environment the best practice is to have clients always use the Windows DNS server as the primary DNS server so dynamic name registration and other domain-related DNS tasks function properly. In environments with only one Windows DNS server, enable the DNS Resolver with an override for the Active Directory domain and use this firewall as the secondary DNS server for the internal machines. This ensures DNS resolution (except for Active Directory) does not have a single point of failure, and loss of the single server won’t mean a complete Internet outage. The loss of a single server in such an environment will usually have significant consequences, but users will be more apt to leave the administrator alone to fix the problem if they can still check out their lolcats, Facebook, Twitter, et al in the meantime.
Another common use of DNS overrides is to resolve internal DNS domains at remote sites using a DNS server at the main site accessible over VPN. In such environments all DNS queries are typically resolved at the central site for centralized control over DNS, however some organizations prefer letting Internet DNS resolve with pfSense at each site, and only forwarding queries for internal domains to the central DNS server. Note a static route is necessary for this to function over IPsec. See pfSense-initiated Traffic and IPsec for more information.
The Domain field sets the domain name that will be resolved using this entry. This does not have to be a valid TLD, it can be anything (e.g.
lab), or it can be an actual domain name (
- IP Address
Specifies the IP Address of the DNS server to which the queries for hostnames in Domain are sent. If the target DNS server is running on a port other than
53, add the port number after the IP address with an
@separating the values, for example:
A text description used to identify or give more information about this entry.
DNS Resolver and Multi-WAN¶
With the default settings, the DNS Resolver will have issues in a Multi-WAN environment. The main issue is that the DNS Resolver wants to query the root DNS servers directly. These queries will only be sent out using the default gateway. If the WAN containing the default gateway fails then DNS queries will also likely fail. There are ways to work around this limitation, however:
Enable DNS Query Forwarding and configure at least one DNS server per WAN gateway under System > General Setup. DNSSEC may also need to be disabled, depending on upstream DNS server support.
Default Gateway Switching¶
Enable Default Gateway Switching under System > Advanced, Miscellaneous tab. This will move the default gateway to the next available gateway if the preferred default fails. However, this option is still considered experimental and may have problems in certain cases.
DNS Resolver and DNS Rebinding Protection¶
By default, DNS Rebinding protection is enabled and private IP address responses are rejected. To allow private IP address responses from a known domain, use the Custom Options box in the DNS Resolver settings to configure allowed domains as follows:
server: private-domain: "example.com"
Unbound provides various command line utilities to manage the DNS Cache server. The following control commands are currently not available in the webGUI but can be executed from the command line.
Unbound does not use the default conf file location; Use the
flag to tell Unbound the configuration file location:
unbound-control -c /var/unbound/unbound.conf <unbound-command-to-run>
To remove items from the cache:
unbound-control flush <name>
<name>from the cache, all record types which include A, AAAA, NS< SOA, CNAME, DNAME, MX, PTR, SRV and NAPTR records.
unbound-control flush_type <name> <type>
<type>from the cache where
<type>is a particular record type.
unbound-control flush_zone <name>
Removes all information at or below the
<name>from cache. For example,
.comwill remove all entries below
.com. Note this process is slow as the entire cache must be inspected.
To determine the name servers Unbound will Query to lookup a zone:
unbound-control lookup <name>