Authoritative DNS server behind resolver (unbound)

[Derelict]

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.

[scelario]

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 gw1.contoso.com.
 - gw1.contoso.com is running an unbound DNS resolver for an internal LAN. It does not use forwarding mode.
 - gw1.contoso.com port forwards DNS queries from WAN to an internal DNS server authoritative for contoso.com.
 - contoso.com has a nameserver record, ns1.contoso.com, that I will resolve to test DNS.
 - Let the public IP for all contoso.com names be 172.200.4.4.

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 contoso.com, 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 contoso.com, finds that it resolves to 172.200.4.4, then sends a request to gw1's own WAN address, 172.200.4.4:

Code: [Select]

debug: sending to target: <ns1.contoso.com.> 172.200.4.4#53

Unbound is bound to 127.0.0.1 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/services.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][admin@gw1.contoso.com]/root: nslookup google.com 172.200.4.4
Server:         172.200.4.4
Address:        172.200.4.4#53

** server can't find google.com: REFUSED

[2.4.2-RELEASE][admin@gw1.contoso.com]/root: nslookup ns1.contoso.com 172.200.4.4
Server:         172.200.4.4
Address:        172.200.4.4#53

Name:   ns1.contoso.com
Address: 172.200.4.4

Now Unbound sends requests to hacked DNS Forwarder listening on 172.200.4.4, 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]

USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS     
dhcpd    dhcpd      31055 7  udp4   *:67                  *:*
nobody   dnsmasq    24521 4  udp4   172.200.4.4:53     *:*
nobody   dnsmasq    24521 5  tcp4   172.200.4.4:53     *:*
root     php-fpm    21690 4  udp4   *:*                   *:*
unbound  unbound    65258 3  udp4   192.168.1.1:53         *:*
unbound  unbound    65258 4  tcp4   192.168.1.1:53         *:*
unbound  unbound    65258 5  udp4   192.168.100.1:53        *:*
unbound  unbound    65258 6  tcp4   192.168.100.1:53        *:*
unbound  unbound    65258 7  udp4   127.0.0.1:53          *:*
unbound  unbound    65258 8  tcp4   127.0.0.1:53          *:*
unbound  unbound    65258 12 tcp4   127.0.0.1:953         *:*
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 [192.168.100.1] 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.