BIND with Authorative Zone not Visible on WAN
-
Greetings!
I've been trying to set up BIND to be authoritative for several zones, and to be master for those zones. It needs to run on WAN. I have a second DNS server that will become slave once pfSense's master is working and visible.
I went to http://mxtoolbox.com/SuperTool.aspx, pointed the tool at one of my zones, selected DNS Check, and let fly. This is what I got:
The .113 is my pfSense box. The .114 is the other server.Port open? See here (both TCP & UDP in the rules):
There is nothing in the help files on using BIND within pfSense, and there are plenty of settings I don't get. Let me run through a few screens (or partial screens).
First, these appear to be the most relevant settings:
A chunk of my zone:
Allow update: none. Allow Query: any. Allow transfer: localnets.It'd be nice to have info on how to set up access control lists. They were set to blank. After not working, I guessed and set them like this for any:
And localnets:
Actually I should probably create an ACL for transfer and point it at the slave DNS server IP address.Finally, what the heck are views, and is this even remotely useful?
What am I doing wrong?
Thanks.
-
Where's your firewall WAN rule allowing the inbound TCP/UDP traffic to WAN port 53?
P.S. Horrible idea…
-
Although the port scan screenshot is more diagnostic, as a port can be open, but there may be no service behind it."Horrible" is a strong word. You'll have to explain why running BIND on this box is "horrible" compared to running BIND on some other box.
Thanks.
-
So, you allow queries from a single /29 and are testing with mxtoolbox.com which doesn't match that ACL at all?
P.S. Regarding views: https://kb.isc.org/article/AA-00851/0/Understanding-views-in-BIND-9-by-example.html
-
Thanks for the quick response.
It's supposed to be accepting queries from "all" and transfers from "localnets" (the /29). Since mxtoolbox isn't doing a transfer (or it would fail on my other DNS server too) it should see BIND just fine. Of course I have no clue how that actually works, or how to set up ACLs.
As an experiment I set queries, updates, and transfers to "all", reset all four default ACLs back to their default settings (two blank value/description pairs), set BIND to listen on "all interfaces/IP addresses", and disabled Unbound. Before the change the system logs for resolver had only entries from Unbound. After the change I stopped and restarted BIND. Now the system logs were filled with entries from BIND (and none from Unbound). I turned off BIND and did a port scan (from mxtoolbox.com)–port 53 showed red (nothing there). Restarting BIND caused port scan to show green for 53. I tried DNS Check from mxtoolbox.com again--no luck. I had deleted the View I created, thinking it was unnecessary complexity. I created a new view--it still fails.
The log shows a ton of denied entries:
Sep 9 10:15:00 named[68830]: client 74.125.183.164#52713 (NS2.SCOTTYDM.NET): view wan1: query (cache) 'NS2.SCOTTYDM.NET/A/IN' denied
Sep 9 10:15:00 named[68830]: client 74.125.183.163#56265 (keithb.frobozz.us): view wan1: query (cache) 'keithb.frobozz.us/A/IN' denied
"Denied" seems like a powerful clue, but I have no idea what to do about it.Goals:
Authoritative DNS (BIND?) on WAN.
Recursive DNS (Unbound?) on LAN and DMZ.Is BIND horrible? This may well be. It's overly complex and does tons of stuff (like caching, recursion, etc.) I don't want it to do. It's also buggy (100 patches for security bugs in BIND 9 alone). A nice alternate might be NSD, but it's not supported by pfSense. TinyDNS only talks UDP, so no zone transfers (doesn't support slaves).
Thanks again.
-
There's nothing horrible about bind. Running public DNS server on your firewall is entirely different matter. Frankly, unless this is running on some fat line serverhosting/VPS, I'd just completely forget about running my own DNS server. It can be run for free by your domain registrar, or by HE Free DNS service, or whatever.
No idea what do you mean by "default" ACLs. Would assume default is just deny which your logs are pretty much confirming.
-
There's nothing horrible about bind. Running public DNS server on your firewall is entirely different matter. Frankly, unless this is running on some fat line serverhosting/VPS, I'd just completely forget about running my own DNS server. It can be run for free by your domain registrar, or by HE Free DNS service, or whatever.
No idea what do you mean by "default" ACLs. Would assume default is just deny which your logs are pretty much confirming.
This ^^
