DNSBL just Work when DNS Resolver Enable

sokeada

@bmeeks hello bro, would you mind to give the example of Domain Override back to AD DNS as you suggest?

SteveITS

@sokeada At the bottom of the DNS Resolver settings page, add an override.
Domain: your AD domain, e.g. example.local
IP: your AD DNS server LAN IP

Repeat for each DNS server.

sokeada

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

@sokeada At the bottom of the DNS Resolver settings page, add an override.
Domain: your AD domain, e.g. example.local
IP: your AD DNS server LAN IP

Repeat for each DNS server.

Thanks brother,

Domain: your AD domain -> my AD FQDN or just domain? example: domain is abc.com and FQDN of the AD is dc1.abc.com.

JeGr

@sokeada Fully depends on what you're trying to do. If you want to resolve all of your domain and subdomains via that override, then use your domain example.tld, if it's only AD stuff you want to resolve then use dc1.example.tld.

So if e.g. you're running an AD on lan.lab.test and you're trying to fix resolving addresses like dc1.lan.lab.test and dc2.lan.lab.test or exchange.lan.lab.test then you would create two overrides and enter the AD domain lan.lab.test as domain in both and the IP of both DCs as the lookup server IP. In this example let's assume your DCs are dc1/dc2 and they run at 10.5.0.11/12:

Thus your domain override would span lan.lab.test and all queries to *.lan.lab.test would be forwarded to either dc1 or dc2 in case one of them is down for maintenance. DNS queries to xyz.lab.test would still resolve but not be forwarded to those DCs but rather resolved via the public DNS of the zone lab.test so a public running www.lab.test would still resolve and have the public DNS entries that zone provides as you only directed the subdomain lan to your DCs.

Of course if you used an entire domain for your ad, you can set that up, too but shouldn't really use that domain in a public non-LAN context.

sokeada

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

@sokeada Fully depends on what you're trying to do. If you want to resolve all of your domain and subdomains via that override, then use your domain example.tld, if it's only AD stuff you want to resolve then use dc1.example.tld.

So if e.g. you're running an AD on lan.lab.test and you're trying to fix resolving addresses like dc1.lan.lab.test and dc2.lan.lab.test or exchange.lan.lab.test then you would create two overrides and enter the AD domain lan.lab.test as domain in both and the IP of both DCs as the lookup server IP. In this example let's assume your DCs are dc1/dc2 and they run at 10.5.0.11/12:

Thus your domain override would span lan.lab.test and all queries to *.lan.lab.test would be forwarded to either dc1 or dc2 in case one of them is down for maintenance. DNS queries to xyz.lab.test would still resolve but not be forwarded to those DCs but rather resolved via the public DNS of the zone lab.test so a public running www.lab.test would still resolve and have the public DNS entries that zone provides as you only directed the subdomain lan to your DCs.

Of course if you used an entire domain for your ad, you can set that up, too but shouldn't really use that domain in a public non-LAN context.

thanks brother for the detail. My case is like post owner, I've windows server as dns & dhcp for lan network and my solution is forward dns request in my windows domain to pfsense box to block ads using pfblockerng but in report shown my dc1 & dc2 request, not client ip or address request that's why I try to override dns but it seems doesn't work, I've tried like your example.

thus I've another vlan network for mobile devices by using dns & dhcp form pfsense, browsing internet is working fine but when i perform nslookup it shown default server UnKnown but IP shown correctly. Any suggestion, please. :)

JeGr

@sokeada Sorry not quite sure I understand your specific problem correctly. The DNS server showing up with name "unknown" would only be a reverse lookup not working. Sad but not a real problem with resolution, but should be fixable with setting a correct host name with a Host Override. But that aside I don't exactly understand what is NOT working? Could you be more specific?

You have another VLAN set up. DNS and DHCP come from pfSense. Browsing internet is fine - thus DHCP and DNS seem to work fine, too. Is the "unknown" the only "problem" you're seeing? Then I'd assume it's just your pfSense IP from that specific VLAN network, that doesn't resolve back to the correct name. You could just add a host override for that and set it up like

<IP for pfSense on mobile device VLAN> pfSense.your.name

Save & Apply and re-check your mobile client. Also check your DHCP settings for that VLAN and what DNS and what domain and search domain(!) you hand out to the client. I'd set that to something like "lab.test" (like in my example) or if you want to separate domain from non-domain DNS something like "mobile.lab.test" for that DHCP & interface and set a host override in DNS for pfSense with the IP from that VLAN to something like "pfs.mobile.lab.test".

Otherwise I'd need more details or screenshots of your setup. :)

sokeada

@JeGr thanks for your comments bro. I've some clues that the UnKnow issue when clients that received IP & DNS from pfSense when perform nslookup is could be from unbound python mode in DSBL Mode but I'm not yet try to change to default unbound mode yet, I'm happy with that because clients don't need to be seen my pfSense box.

Another issue is, I forwarded dns request from windows server dns to pfSense to block Ads. Everything work fine but in DNSBL report only shown my windows dns request, not clients behind my windows dns. I also get some clue that the only possible way to show clients ip or host name in DNSBL report is only point my clients behind windows dns to pfSense instead.

johnpoz

@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

SteveITS

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

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.