BIND config reset

[curtisgrice]

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.

[johnpoz]

@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.

[Gertjan]

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.

[johnpoz]

My bad - I read that as external, not internal.. Yah if internal record need some details of the zone file, etc.

[curtisgrice]

@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

[johnpoz]

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.

[curtisgrice]

@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

[johnpoz]

what do you mean you would get nothing - you would get timeout?

[curtisgrice]

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.

[curtisgrice]

@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.

[johnpoz]

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..

[curtisgrice]

Thanks for your help. We can consider this closed.

[johnpoz]

We seem to be missing each others edits ;) Did you get my edit about views to prevent recursion.

[curtisgrice]

@johnpoz Yes I did find the recursion setting in the view view. Thank you.