Last Updated on August 16, 2022 by Thiago Crepaldi
Configuring pfSense DNS Resolver
Many ISPs or other Internet service providers collect information for commercial reasons (selling your profile for directed advertisement) or otherwise. pfSense allows you to use DNS with TLS to encrypt your request in a way that only you and the DNS provider can see it.
DNS over TLS is not supported by all DNS providers, so in this post I will use CloudFlare, which is free, fast, support TLS and don’t keep logs. Visit https://1.1.1.1/dns/ for more information
On your pfSense dashboard page, click on System >> General Setup menu. At the DNS Server Settings tab, add 1.1.1.1 and 1.0.0.1 as DNS servers. For most cases, you don’t need to type anything for Hostname and Gateway. Uncheck the DNS Server Override check box to make sure your ISP will not override your preference. Complete the process by clicking Save at the bottom.
Now that your DNS is configured, let’s make sure we enable TLS on it. Click on Services >> DNS Resolver menu. Make sure Enable checkbox is checked and then check the following checkbox too:
- DNSSEC: Enable DNSSEC support
- DNS Query Forwarding: Enable Forwarding Mode
- DNS Query Forwarding: Use SSL/TLS for outgoing DNS Queries to Forwarding Servers
Click Save and Apply changes and you should be good to go. Sometimes settings are not applied correctly and a full reboot is needed (Diagnostics >> Reboot)
Some devices have hard coded DNS Servers on them, so they will use them instead of pfSense. To fix that, you can block external DNS Servers and/or redirect them to pfSense through Firewall rules.
Redirecting all DNS Requests to pfSense
The following instructions are originally published at https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html, but I will replicate them here too.
Before adding this rule, ensure the DNS Forwarder or DNS Resolver is configured to bind and answer queries on localhost, or All interfaces.
In the following example, the LAN interface is used, but it could be used for any local interface. Change the Interface and Destination as needed.
- Navigate to Firewall > NAT, Port Forward tab
- Click Add to create a new rule
- Fill in the following fields on the port forward rule:
- Interface: LAN
- Protocol: TCP/UDP
- Destination: Invert Match checked, LAN Address
- Destination Port Range: 53 (DNS)
- Redirect Target IP: 127.0.0.1
- Redirect Target Port: 53 (DNS)
- Description: Redirect DNS
- NAT Reflection: Disable
Any DNS request made to any external IP address will result in the query being answered by the firewall itself. Access to other DNS servers on port 53 is impossible.
Blocking DNS Queries to External Resolvers
The following instructions are originally published at https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-queries-to-external-resolvers.html, but I will replicate them here too
- Add a firewall rule on Firewall >> Rules, LAN tab allowing protocol TCP/UDP, source: any, destination: LAN Address, destination port range:
53 - Move this newly created rule from step #1 to the very top of the LAN rules
- Add a new rule blocking protocol TCP/UDP, source: any, destination: any, destination port range: 53
- Move the rule created in step #3 to the second position behind the permit rule that was moved in step #2.
- Save and Apply changes
If you followed the steps for redirecting all DNS requests to your local pfSense, ensure the rule to pass DNS to 127.0.0.1 is above any rule that blocks DNS!
Blocking other DNS over TLS servers
It is safer to have a single DNS server running on your network, so let’s add one more firewall rule to block any connection for any DoT other than your pfSense.
- Add a firewall rule on Firewall >> Rules, LAN tab blocking TCP protocol, Source: any, Destination any, Destination port range 853
- Move this newly created rule from step #1 to the very top of the LAN rules
- Save and Apply changes
Verify everything works
I have tried using 1.1.1.1/help to see whether my settings were working, but found out that when DNSSEC is enabled on pfSense, CloudFlare’s test fails, but it is actually working. To verify your settings, go to Diagnostics >> State, select all interfaces and set Filter Expression as your DNS IP. You should see that the only connections on port 53 are for your localhost and all other connections to your DNS are over port 853, the DNS over TLS port.
Another test is capturing some packages through Diagnostics >> Packet capture page. Set the Interface as WAN and Port as 853. Click on Start button and use your browser to visit some pages, such as pfsense.org. Stop and View capture. You should see several packages flowing from/to 1.1.1.1:853. Repeat the capture for port 53 and note that the capture will be empty.
Visit https://dnssec.vs.uni-due.de and click Start test. If you get a thumbs up, your DNS is safe!
You mention enabling DNSSEC support under Services >> DNS Resolver, but that won’t do much good if you are in forwarding mode. You should be relying on the forwarding server to perform the DNSSEC validation, so there is no need to do this check (again) in Unbound/PFsense. You could, but I don’t see a point unless you don’t trust the forwarding server (in which case, why use it?) That also means you won’t need to harden DNSSEC data under Services >> DNS Resolver >> Advanced Settings.
Hey there, thanks for the discussion. If DNSSEC is not enforced, isn’t there a chance someone could alter the content of the response and corrupt whatever content the forwarding servers returned? It is not a matter of not trusting the forwarding server, but not trusting the media in which servers communicate through
In forwarding mode you loose the end to end validation, since you do not independently talk to each NS server in the chain down from roots to get to the authoritative server. Instead you are trusting the DNS forwarding server to get this information for you and provide the validated response back. In your example all someone would need to do is not send back the DNSSEC info and pfSense/unbound would interpret that as DNSSEC isn’t enabled for the domain and pass the record on to the client as valid. DNSSEC enabled in pfSense/unbound wouldn’t prevent this scenario from happening in forwarding mode as all DNSSEC is doing is validation that the a record in a domain has been signed by the owner of the domain, which is done from the information in the DNS reply it receives back.