DNSBL just Work when DNS Resolver Enable

[sokeada]

@johnpoz said in DNSBL just Work when DNS Resolver Enable:

@sokeada what is 192.168.50.1 ?

Is that pfsense itself, or your DC?

All that is as mentioned is there is no PTR for 192.168.50.1, If you set a host override in pfsense for what 192.168.50.1 is then its name would be returned when nslookup does the ptr..

If that is pfsense IP, it should always return its own name..

I normally point my clients to my pihole, I like the eye candy and its easy to see what is being asked for, what is being blocked.. pfblocker can do pretty much the same thing as pihole, but I like the eye candy pihole presents more than pfblocker ;)

But see when I change the server over to unbound on pfsense, it returns the name via the ptr the nslookup does on the server IP.

$ nslookup
Default Server:  pi.hole
Address:  192.168.3.10

> server 192.168.9.253
Default Server:  sg4860.local.lan
Address:  192.168.9.253

the above IP is not pfSense's IP, it's IP range for my PDA VLAN, DHCP, DNS Resolver from pfSense. In pfBlockerNG DNSBL mode, I used Unbound python mode. In DNS Setting in General setup, I use default DNS Resolution Behavior. I see some of user said when they change DNSBL mode from python mode to default unbound, name resolve normally but I didn't try it yet.

[sokeada]

@SteveITS said in DNSBL just Work when DNS Resolver Enable:

@sokeada With Windows AD and pfBlocker you can either

• forward Windows DNS to pfSense, and set PCs to use Windows DNS, or

• use a Domain Override in pfSense to send AD domain requests to your Windows servers, and use pfSense for DNS

Re:unknown, is your PC on pfSense LAN or another interface?

I used option one by forwarding Windows DNS to pfSense and all my LAN clients are getting local DNS from Windows Server and Ads blocker and other stuff works fine but when I check DBSBL log or report, it show my Windows Server IP instead of client LAN IP.

UnKnown from another interface that use everything from pfSense including DNS Resolver and DHCP.

LAN client is fine, when perform nslookup it shows Windows DNS name & IP and reply from domain I want to check as normal.

[johnpoz]

@sokeada said in DNSBL just Work when DNS Resolver Enable:

the above IP is not pfSense's IP

So it is a pfsense (just not its lan IP), its just the IP on a vlan - that you listen for dns on and is the gateway for that vlan.. Ok - then create a host record for it and then it will resolve.

Example

$ nslookup
Default Server:  pi.hole
Address:  192.168.3.10

> server 192.168.2.253
Default Server:  sg4860.wlan.local.lan
Address:  192.168.2.253

That 2.253 address is pfsense IP on one of my vlans for wifi.. Another IP for me dmz network 192.168.3/24 resolves as such

> server 192.168.3.253
Default Server:  sg4860.dmz.local.lan
Address:  192.168.3.253

I setup host records for these IPs, so I can easy identify them.. Which is kind of the whole point of dns - to be able to refer to something by a fqdn, or via a ptr to find the fqdn of an IP from the IP..

[sokeada]

@johnpoz said in DNSBL just Work when DNS Resolver Enable:

I setup host records for these IPs, so I can easy identify them

sorry bro, setup host records is where I put host override in pfSense?

[SteveITS]

@sokeada So use option two so devices query pfSense directly, if that’s what you want.

“UnKnown” is not a functional problem, you can ignore it. You would need to add a reverse DNS zone and PTR record for that IP to whatever DNS server is being used. Or, just ignore it.

[johnpoz]

@sokeada my typo, yeah host overrides in pfsense.

[johnpoz]

@SteveITS said in DNSBL just Work when DNS Resolver Enable:

“UnKnown” is not a functional problem, you can ignore it.

While technically true - If I get an unknown for the dns I am using - it points to badly managed dns... Why would there not be a PTR for everything on your network ;)

If your going to setup forward zones, you might as well setup the reverse zones for the IP ranges you use on your network. pfsense makes it easy because you put in the host override, the ptr is auto there for that host, etc.