Can't reach internal resources when NextDNS Profile is active
I have a homelab setup with multiple servers and an Nginx proxy setup. I have NextDNS configured on my pfSense firewall (which handles all DHCP), and I am using the pfSense's DNS Resolver to enable Split DNS for accessing my internal resources via FQDN so that https works without error. This all works fine.
However, if I enable a profile on my Mac so that I can identify my computer in the NextDNS logs, then I am no longer able to access my internal servers by their FQDN, only by IP. Removing the profile immediately restores the ability to access my internal servers by name.
I have my domain listed as a whitelist in NextDNS, is there something else I am needing to do?
2 replies
-
Enabling the profile effectively bypasses your router, so your local setup is ignored.
It might be possible to fix by using the DNS Rewrite function, to point local domains to your local network IPs.
-
More complicated, but I'll give an example of how I do split-horizon DNS with NextDNS at my office.
At my office I have (2) BIND9 DNS servers serving an authoritative DNS zone, as well as (2) NextDNS servers. All clients are pointed to the (2) NextDNS servers, which are running the linux NextDNS client. Using the syntax of the NextDNS client, I can configure "forwarders" for my internal DNS Zone, and tell NextDNS to forward requests for that zone to my two BIND9 servers where the authoritative zone is hosted.
This allows me to capture, log, and filter all DNS requests both for external zones as well as internal zones. It also allows for client computer identification.
Don't forget to create forwarder config entry for your appropriate network reverse DNS zone, as well as disable the NextDNS client default of providing bogus reverse DNS responses.
Here is an example config of one of my two NextDNS daemon servers in my network, which all clients are configured to point DNS lookups to. Note how my discovery-dns and forwarder entries are pointed to my internal DNS zone's authoritative DNS servers, 10.1.80.11 and 10.1.80.12. Change yours as appropriate. In the below example, "COMPANY.TLD" is where I forward the internal DNS zone. The other forwarder lines cause private address reverse zones to be forwarded there as well.
Hope this helps.
root@cdns1:~# nextdns config|sort auto-activate false bogus-priv false cache-max-age 15s cache-size 1G control /var/run/nextdns.sock debug false detect-captive-portals false discovery-dns 10.1.80.11,10.1.80.12 forwarder 10.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 16.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 168.192.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 17.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 18.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 19.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 20.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 21.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 22.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 23.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 24.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 25.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 254.169.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 26.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 27.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 28.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 29.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 30.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder 31.172.in-addr.arpa.=10.1.80.11,10.1.80.12 forwarder COMPANY.TLD.=10.1.80.11,10.1.80.12 hardened-privacy false listen localhost:53 log-queries false max-inflight-requests 256 max-ttl 30s mdns disabled profile 192.168.5.25/32=e5f6g7 profile a1b2c3 report-client-info true setup-router true timeout 5s use-hosts false
Remember, the key lines to accomplish what you want are:
bogus-priv false discovery-dns 10.1.80.11,10.1.80.12 forwarder COMPANY.TLD.=10.1.80.11,10.1.80.12 report-client-info true setup-router true
bogus-priv: enables or disables providing bogus responses to private IP address reverse DNS lookups. If you want reverse lookups to be handled correctly, set this to false.
discovery-dns: this helps NextDNS lookup a client's hostname by specifying your authoritative DNS servers that would contain those records
forwarder: this is the split horizon entry; put your internal dns zone here with the appropriate IPs of the authoritative DNS zone hosts. Create as many lines as needed for each of your internal DNS zones, including PTR zones
report-client-info: enables sending client details to the NextDNS logs online so you can see the client details in the logs
setup-router: enables the NextDNS daemon to bind to routable IPs on the server, to listen for and handle incoming DNS requests on your network for other clients
Content aside
-
1
Likes
- 7 days agoLast active
- 2Replies
- 55Views
-
3
Following