BIND config reset
-
I have had BIND installed in the past but removed it due to bugs in the pfsense-pkg version. I have since reinstalled but I am having a few odd issues. With no external DNS servers configured anywhere on pfSense or packages, as soon as BIND is enabled, my guests are able to resolve external addresses. I double checked flushing local DNS cache too. I'm also having an issue where one particular internal record will not resolve no matter what I do.
I would like to uninstall BIND and flush any and all config remnants to start fresh. I tried uninstalling and reinstalling the package but the old config was pulled back in. I even verified /usr/local/etc/namedb was gone after removing the package.
I'm on pfSense 2.4.3 p1 on a Netgate SG-2440.
-
@curtisgrice said in BIND config reset:
as soon as BIND is enabled, my guests are able to resolve external addresses
Well that is what resolver's do ;) I would have to fire up bind package - but if your saying stuff resolves once enabled have to assume it defaults to resolver mode, or is forwarding to dns you get from dhcp on your wan (which you can turn off).
What is this domain you can not resolve and can look into why that might be.
-
Hi,
Now we know that the first issue isn't an issue but the principale goal of the package :
@curtisgrice said in BIND config reset:I'm also having an issue where one particular internal record will not resolve no matter what I do.
Do you have more information about this particular internal record ?
I advise you to backup your pfSense config.
Normally, you'll put it in a safe place, but this time I advise you to look into it. You'll see how easy it is to find the place were all the "bind" related configs are placed. You will also find further information about this "particular internal record".As you might have guessed, "/usr/local/etc/namedb" is build with the information found in the pfSense config file.
-
My bad - I read that as external, not internal.. Yah if internal record need some details of the zone file, etc.
-
@gertjan said in BIND config reset:
Now we know that the first issue isn't an issue but the principale goal of the package :
I guess I didn't think about the root hints. But yes that would allow external resolution without an external DNS server configured. Though its odd that there is not option to enable/disable root hints.
the record with issue is "FreeNAS IN A 192.168.1.5"
I pulled in a long-ish list of hostnames and as such I added them in the "Custom Zone Domain Records" section.
BK01 IN A 192.168.99.50 DC01 IN A 192.168.1.10 ESXi01 IN A 192.168.99.101 ESXi02 IN A 192.168.99.102 minecraft IN A 192.168.1.20 Emby IN A 192.168.1.21 Operations IN A 192.168.99.100 Orchestrator IN A 192.168.99.52 pfSense IN A 192.168.1.1 FreeNAS IN A 192.168.1.5 Plex IN A 192.168.1.6 Transmission IN A 192.168.1.7 UniFi IN A 192.168.1.3 vcsa IN A 192.168.99.99 psc01 IN A 192.168.3.98 vcsa-Lab IN A 192.168.3.99 vESXi01 IN A 192.168.3.101 vESXi02 IN A 192.168.3.102 vESXi03 IN A 192.168.3.103 vESXi04 IN A 192.168.3.104
With a resulting zone file of:
$TTL 43200 ; $ORIGIN rack.center. ; Database file rack.center.DB for rack.center zone. ; Do not edit this file!!! ; Zone version 2535673374 ; rack.center. IN SOA ns1. zonemaster.rack.center. ( 2535673374 ; serial 1d ; refresh 2h ; retry 4w ; expire 1h ; default_ttl ) ; ; Zone Records ; @ IN NS ns1. @ IN A 192.168.1.1 ns1 IN NS 192.168.1.1 iDRAC-FreeNAS IN A 192.168.50.15 ; ;custom zone records ; BK01 IN A 192.168.99.50 DC01 IN A 192.168.1.10 ESXi01 IN A 192.168.99.101 ESXi02 IN A 192.168.99.102 minecraft IN A 192.168.1.20 Emby IN A 192.168.1.21 Operations IN A 192.168.99.100 Orchestrator IN A 192.168.99.52 pfSense IN A 192.168.1.1 FreeNAS IN A 192.168.1.5 Plex IN A 192.168.1.6 Transmission IN A 192.168.1.7 UniFi IN A 192.168.1.3 vcsa IN A 192.168.99.99 psc01 IN A 192.168.3.98 vcsa-Lab IN A 192.168.3.99 vESXi01 IN A 192.168.3.101 vESXi02 IN A 192.168.3.102 vESXi03 IN A 192.168.3.103 vESXi04 IN A 192.168.3.104
-
So your saying none of those resolve? What do you get back when you ask NX or ServFail?
If you don't want bind client to be able to resolve - then set that up in your view.. Set it to no recursion if you only want to return what your authoritative for.
-
@johnpoz I would get nothing. This is internal only. I see you responded before my edit. the host that would not resolve was freenas.rack.center
-
what do you mean you would get nothing - you would get timeout?
-
I just reinstalled again to pull everything. While the old config was still there, it seems to be working now.
I don't like when things fix themselves and offer no explanation. -
@johnpoz Excuse my ignorance I thought you were referencing and external DNS lookup service like mxtoolbox. I was getting not a valid domain from nslookup even though pfsense.rack.center worked fine.
-
Yeah that can be frustrating for sure - but if you were getting timeout, maybe it was restarting or for whatever reason it was trying to resolve it.. If it didn't think it had the record and it was authoritative for that zone you should of gotten NX.
Maybe the client did query for FreeNAS without the suffix or maybe it did FreeNAS.rack.center.rack.center but that should of returned NX..
-
Thanks for your help. We can consider this closed.
-
We seem to be missing each others edits ;) Did you get my edit about views to prevent recursion.
-
@johnpoz Yes I did find the recursion setting in the view view. Thank you.