Netgate SG-1000 microFirewall

Author Topic: Authoritative DNS server behind resolver (unbound)  (Read 2374 times)

0 Members and 1 Guest are viewing this topic.

Offline Derelict

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10257
  • Karma: +1175/-313
    • View Profile
Re: Authoritative DNS server behind resolver (unbound)
« Reply #15 on: September 06, 2015, 06:50:40 pm »
No.  It has to use the WAN interface to get at the WAN IP to get NAT reflected.  That's why the damn thing isn't working unless you do the overrides which tells it to NOT go out to the internet but to go out LAN to resolve the names instead.
Las Vegas, Nevada, USA
Use this diagram to describe your issue.
The pfSense Book is now available for just $24.70!

Offline scelario

  • Newbie
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: Authoritative DNS server behind resolver (unbound)
« Reply #16 on: December 31, 2017, 04:24:16 am »
I realize this is an old topic, but I recently faced the same problem as OP and would like to share an alternative solution I implemented. To illustrate:
 - My pfSense gateway is
 - is running an unbound DNS resolver for an internal LAN. It does not use forwarding mode.
 - port forwards DNS queries from WAN to an internal DNS server authoritative for
 - has a nameserver record,, that I will resolve to test DNS.
 - Let the public IP for all names be

LAN clients are able to resolve using the WAN IP thanks to NAT redirection, however asking Unbound for contoso records results in SERVFAIL after an initial timeout. My authoritative server runs several domains in addition to, so I'm very interested in Unbound resolving everything on behalf of internal clients rather than offloading any work to them. I also do not like the idea of maintaining two sets of DNS records; NAT reflection works fine so I'd rather just fix DNS.

I added verbosity: 3 to the custom DNS resolver settings, and the debug log indicates that Unbound does in fact send a request to find the NS address for, finds that it resolves to, then sends a request to gw1's own WAN address,
Code: [Select]
debug: sending to target: <>

Unbound is bound to and the LAN address; by some testing, it seems packets originating from gw1 do not get processed for NAT. Since no DNS service is listening on the WAN IP, and Unbound wants to check the WAN IP, I figured the easiest/quickest workaround would be to set up the DNS forwarder service to listen on that address.

DNS Forwarder is therefore enabled and configured to bind only to WAN Interface address. I received an angry message about conflicting port 53, so I hacked /etc/inc/ to always put --port=53 and entered port 54 into the web interface :)

The next step was to replace "--all-servers" with "--server=AUTHORITATIVE-SERVER --no-resolv" so dnsmasq is only used to query my own records and will still work if WAN is down. This change is totally optional if you don't care. You'll know it's set up right if you can do this:

Code: [Select]
[2.4.2-RELEASE][]/root: nslookup

** server can't find REFUSED

[2.4.2-RELEASE][]/root: nslookup


Now Unbound sends requests to hacked DNS Forwarder listening on, and DNS Forwarder redirects to the authoritative DNS server. All is working. And since no firewall rules are changed, WAN DNS requests and LAN requests to WAN IP are still directly NATed to the authoritative server. Perfect.

sockstat -4 -l
Code: [Select]
dhcpd    dhcpd      31055 7  udp4   *:67                  *:*
nobody   dnsmasq    24521 4  udp4     *:*
nobody   dnsmasq    24521 5  tcp4     *:*
root     php-fpm    21690 4  udp4   *:*                   *:*
unbound  unbound    65258 3  udp4         *:*
unbound  unbound    65258 4  tcp4         *:*
unbound  unbound    65258 5  udp4        *:*
unbound  unbound    65258 6  tcp4        *:*
unbound  unbound    65258 7  udp4          *:*
unbound  unbound    65258 8  tcp4          *:*
unbound  unbound    65258 12 tcp4         *:*
unbound  unbound    65258 26 udp4   *:11960               *:*
unbound  unbound    65258 27 udp4   *:25771               *:*
unbound  unbound    65258 28 udp4   *:51981               *:*
unbound  unbound    65258 30 udp4   *:7219                *:*

Note: In reality I am running my servers in a DMZ [] that LAN clients access through NAT reflection, however I did not include details previously to simplify the problem. The only extra configuration needed is to enable Pure NAT redirection for relevant fw rules, change NAT mode from automatic to hybrid, and create a NAT profile for any LAN -> DMZ traffic that is allowed by the firewall rules.
« Last Edit: December 31, 2017, 11:36:20 am by scelario »