pfBlockerNG not blocking domain after first DNS lookup attempt

[vjizzle]

Hi,

So pfBlockerNG is not blocking a blocked domain when I retry the query again. I can reproduce this again and again on my pfSense. Running the latest version of pfSense CE (2.7.1) and the latest version of pfBlockerNG. This makes me believe that it must allow blocked domains which are being retried. Please check my output below:

> server 192.168.100.1
Default Server:  XXXXXXXXXX
Address:  192.168.100.1

> www.msn.com
Server:  XXXXXXXXXX
Address:  192.168.100.1

Non-authoritative answer:
Name:    www.msn.com
Addresses:  ::
          0.0.0.0

> www.msn.com
Server:  XXXXXXXXXX
Address:  192.168.100.1

Non-authoritative answer:
Name:    a-0003.a-msedge.net
Address:  204.79.197.203
Aliases:  www.msn.com
          www-msn-com.a-0003.a-msedge.net

> www.msn.com
Server:  XXXXXXXXXX
Address:  192.168.100.1

Non-authoritative answer:
Name:    a-0003.a-msedge.net
Address:  204.79.197.203
Aliases:  www.msn.com
          www-msn-com.a-0003.a-msedge.net

[jrey]

@vjizzle

I can recreate this but only if the client has multiple DNS paths.

where are you running this lookup from and;
how exactly are you blocking?

0.0.0.0 DNSBL on the pfSense Box,
then the next query most likely gets the response from the second DNS Server,

from a client System I can do this all day long and the DNSBL will always block it, in my case the 10.10.10.1 address being returned is the "you are blocked webpage"

the client machine can only ever talk to the Resolver on pfSense if DHCP assign it there, or static, (or if you can't set it some devices that use DHCP, but don't listen to setting the DNS, in these cases if needed you can any non-complying client lookup, with a RULE)

Anything telling the client is has another DNS will return an address at some point.

Running the same lookup on pf shell itself will result the expected block local, but because the resolver has another DNS it can talk to (roots or others), and has to have it) you will get this.

has everything to do with order and path DNS query traffic is allowed to follow..

a device that as redirected with a RULE, (so one where you can't set static or DHCP can't assign the DNS) even if you did a

dig @8.8.8.8 www.msn.com

would respond with 10.10.10.1 in this case, and the dig (depending on the client would tell you it got the response from 8.8.8.8, even though it clearly did not)

so on a client it blocks, on pf it does not and this is fine.

[vjizzle]

@jrey
I am using a Windows client with only 1 DNS server configured and pfBlockerNG is running in Python mode:

Ethernet adapter Ethernet Instance 0 2:

   Connection-specific DNS Suffix  . : XXXXXX.lan
   Description . . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter
   Physical Address. . . . . . . . . : 02-11-3XXXXXXXXX
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.100.25(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : zondag 26 november 2023 15:28:28
   Lease Expires . . . . . . . . . . : vrijdag 1 december 2023 15:00:32
   Default Gateway . . . . . . . . . : 192.168.100.1
   DHCP Server . . . . . . . . . . . : 192.168.100.1
   DNS Servers . . . . . . . . . . . : 192.168.100.1
   NetBIOS over Tcpip. . . . . . . . : Enabled
   Connection-specific DNS Suffix Search List :
                                      XXXXXXXX.lan

C:\Users\Administrator>nslookup
Default Server:  XXXXXXXX.lan
Address:  192.168.100.1

> www.msn.com
Server:  XXXXXXXXXX.lan
Address:  192.168.100.1

Non-authoritative answer:
Name:    www.msn.com
Addresses:  ::
          0.0.0.0

> www.msn.com
Server:  XXXXXXXX.lan
Address:  192.168.100.1

Non-authoritative answer:
Name:    a-0003.a-msedge.net
Address:  204.79.197.203
Aliases:  www.msn.com
          www-msn-com.a-0003.a-msedge.net

There are no redirects etc, and DNS server is being handed out by DHCP. This is a leak as far as I can see with pfBlockerNG. If I change my DNS server to a pihole with the same blocklists as on my pfSense, blocking is working as expected.

[jrey]

@vjizzle

Okay that helps, now the second part

how exactly are you blocking?

I can't recreate this "leak" as you describe, it just blocks every time as expected. (edit: unless I introduce another DNS in the PATH that can respond)

Let's take at your DNS Resolver (pfSense DNS settings in general would be helpful) and pfBlocker settings.

[vjizzle]

@jrey

Please find an overview of my DNS Resolver and DNSBL settings in the screenshots below.

[jrey]

@vjizzle said

Ethernet adapter Ethernet Instance 0 2:

Do you have more than one network card on your Windows machine?
Appears it might be a virtual machine?

had to spin up my windows virtual and I don't block msn on this network, but do block twitter.com here are the results

[vjizzle]

@jrey
It is a virtual machine yes. Check the screenshot below showing the difference between using pihole vs pfblockerng.

[jrey]

@vjizzle

Okay where are you making the entry to block msn.com ?

You have a couple of items checked that I don't use/require however... I'll have to check and see if any of them make a difference

[johnpoz]

@jrey if you set unbound on pfsense to block something, or via pfblocker... It will be blocked every single time..

If your having a client get an answer, then it got it elsewhere - doh in your browser would be the most likely suspect.

[vjizzle]

@johnpoz Yes I know about the DOH in browsers indeed, that is not what this problem is in my opinion.

@jrey www.msn.com is blocked via CNAME a-0003.a-msedge.net. This record exists in the following blocklist: https://raw.githubusercontent.com/WindowsLies/BlockWindows/master/hostslist

I just tried changing pfBlockerNG to Unboud mode and a force reload afterwards. Also cleared the dns cache of my client but still the same. pfSense/pfBlocker still resolves www.msn.com unfortunately.

[vjizzle]

I just tested this out from my Macbook. It's still the same problem. www.msn.com is being resolved. It doesn't matter if pfBlockerNG is in Unbound mode or Python mode. After reloading pfBlockerNG, the first query for www.msn.com results in a 0.0.0.0 answer, but every query after the first one is resolved.

XXXX@caldigit-dock ~ % nslookup
> > server 192.168.100.1
> Default server: 192.168.100.1
> Address: 192.168.100.1#53
> > www.msn.com
> Server:		192.168.100.1
> Address:	192.168.100.1#53
> 
> Non-authoritative answer:
> Name:	www.msn.com
> Address: 0.0.0.0
> > www.msn.com
> Server:		192.168.100.1
> Address:	192.168.100.1#53
> 
> Non-authoritative answer:
> www.msn.com	canonical name = www-msn-com.a-0003.a-msedge.net.
> www-msn-com.a-0003.a-msedge.net	canonical name = a-0003.a-msedge.net.
> Name:	a-0003.a-msedge.net
> Address: 204.79.197.203
> > 
> > 
> 

[jrey]

@johnpoz said in pfBlockerNG not blocking domain after first DNS lookup attempt:

doh in your browser would be the most likely suspect.

unlikely doh, it is an nslookup - port 53

it is a good question, I've preformed the same tests as the OP, and my DoH rule has never tripping, but at the same time it just blocks every single time.

Let's ask this @vjizzle are you loading / have you loaded msn at any point during testing in a browser.

as for the browser, on my windows machine

and the nslookup all still returned 0.0.0.0 after. No DoH recorded.

but something could be loading the cache,

"Message cache elements are prefected..."
"Serve cache records even with TTL of 0"

Personally I've never had much use for either those settings, OP may have a requirement ?

[vjizzle]

I have not loaded www.msn.com (or the CNAME) in my browser or other device in my network. The DNS options for prefetch and server TTL of 0 is only there to speedup host lookups. The same options are enabled on my pihole which is using local installed unbound in resolver mode.

Somehow the pfSense resolver manages to bypass pfBlockerNG or CNAME blocking fails in pfBlockerNG, looks like to me at least.

[johnpoz]

@vjizzle said in pfBlockerNG not blocking domain after first DNS lookup attempt:

CNAME blocking fails in pfBlockerNG

you could have some problem with something looking up the cname but not the original that is blocked..

;; QUESTION SECTION:
;www.msn.com.                   IN      A

;; ANSWER SECTION:
www.msn.com.            11194   IN      CNAME   www-msn-com.a-0003.a-msedge.net.
www-msn-com.a-0003.a-msedge.net. 56 IN  CNAME   a-0003.a-msedge.net.
a-0003.a-msedge.net.    56      IN      A       204.79.197.203

Blocking msn.com doesn't prevent lookup of a-msedge.net.

If I wanted to block msn.com what I would do is put this directly in unbound custom box, since I don't use blocking in pfblocker..

local-zone: "msn.com" always_nxdomain

[jrey]

@vjizzle said in pfBlockerNG not blocking domain after first DNS lookup attempt:

www.msn.com is blocked via CNAME a-0003.a-msedge.net

look above when I ran the test the canonical name returned is not on the list you provided.

I'd like to see the specific setup you have for this list you are providing.
(ie the DNSBL setup containing that list)

Hopefully you have it added under an entry within DNSBL Groups?

also in the pfblockerng.log there should be a section showing it being processed.
provide that log section please.
anything in the error.log (pfblockerng)

then most likely what you are seeing is that www.msn.com is not on the list, and you are returning the CNAME on subsequent queries some of those are multi-named

not also that the CNAME I returned is www.msn.com.a-0003.a-msedge.net
and the CNAME you see is a-0003.a-msedge.net

traceroute a-0003.a-msedge.net
traceroute to a-0003.a-msedge.net (204.79.197.203), 64 hops max, 52 byte packets

traceroute www.msn.com.a-0003.a-msedge.net
traceroute to a-0003.a-msedge.net (204.79.197.203), 64 hops max, 52 byte packets

on your DNSBL category, where you have the list being added, goto the bottom DNSBL Custom_list and add the entry msn.com
no quotes, no other sub just msn.com

then force reload the DNSBL on the update tab

check the same 2 logs referenced above, for the processing of the list and the new custom entry

try the test again.

[jrey]

@johnpoz

yup, I really want to see the settings of the specific DNSBL category. being used,

using the local-zone would also work, but in this case the OP already has a "list" in pfBocker, that blocks a bunch of other specific things, just not all the "specific things"

msn.com on the DNSBL category, would keep it all together for the OP.

certainly I don't use the list, and blocking the lookup by DNSBL works and does not return a CNAME.

However there might be a problem with the TLD because from the list
a-0003.a-msedge.net is listed.

The setting, CNAME Validation set being enable MIGHT be the source of the "leak". Still trying to recreate the OP's various settings to see if I can recreate the issue.

[vjizzle]

When I add msn.com to a custom DNSBL Group for blocking, pfBlockerNG works perfectly and keeps blocking msn.com and www.msn.com. That goes for every domain I add to my custom blocklist.

The problems starts to occur when there is CNAME resolving involved. As you can see www.msn.com resolves to a CNAME a-0003.a-msedge.net. This hostname is in the blocklist I am using:

I have TLD blocking and CNAME blocking options enabled in pfBlockerNG:

That is why I would expect pfBlockerNG to keep blocking www.msn.com because the CNAME it resolves to is in the blocklist.

This is also the behaviour in pihole. When it resolves to a CNAME in a blocklist, the initial domain is blocked:

[vjizzle]

@jrey Please find the screenshots below on how I have setup the DNSBL group:

[jrey]

@vjizzle

That's why I want to see the log files ;-)
Edit and the DNSBL Groups settings for the specific group/list you have setup containing the list you referenced. oops your second post appeared lated.

You also have Regex Blocking enabled, do you have any entries in the list that appears below on the screen when that is enabled?

[vjizzle]

@jrey Ah yes. Are the screenshots I just posted enough? What logfiles do you want to see?