25.7.8 Unbound blocklist source nets

[gpfountz]

After upgrading to 25.7.8, I configured unbound's blocklist's source nets to include my LAN and IoT networks, excluding my GUEST network.  The problem is as soon as someone on the guest network does a lookup of a blocked domain, that domain's IP lookup is cached. After this, that blocked domain's IPs are served to my LAN.

Is there a solution for this?  I know I can use a different DNS server for my GUEST network. That is what I was doing before the source nets feature was added to 25.7.8.

Thanks in advance!

[cat2devnull]

Unfortunately I'm seeing the same effect. Once a domain is cached by a user in a source net that is allowed access. The users from a source net that are blocked can now retrieve a cached request. It seems that source net blocking only blocks recursive DNS not cached DNS. :(

[OPNenthu]

What happens if you disable the caches?

Advanced->Message Cache Size = 0
Advanced->RRset Cache Size = 0

[OzziGoblin]

I'll second this!

I've done quite a bit of testing, moving from Adguardhome to unbound and its BL's. Even using the same BL's with the URL's added to unbound make them identical, I'm still getting AD's coming through when using unbound, that I don't when using Adguardhome.
A restart of Opnsense also doesn't appear to make any difference, local client dns cache and browser cache clears as well as rebooted the client.

I'll give it a second go after the next upgrade

[Javier®]

One solution for distributing blocklists across your networks is to use RPZ.
The problem is that you have to do it manually in /usr/local/etc/unbound.opnsense.d
https://unbound.docs.nlnetlabs.nl/en/latest/topics/filtering/rpz.html

[OPNenthu]

I haven't enabled the per-network DNSBL on my end as of yet, but for those who are seeing this- are you using dynamic IPv6 prefixes?  I'm looking at the Source Nets field and I don't know how you would even configure it for e.g. IA_PD.

AFAIK, we don't (yet) have any mechanism to track those for use in form fields like this.  Am I misinformed, or is this feature presently limited to IPv4 and IPv6 networks where the prefixes are not changing?

In any case: https://github.com/opnsense/core/issues/9474

[gpfountz]

Thanks for filing the issue.

In my case, all my clients are assigned only an ipv4 address for the DNS server; so no IPv6 issues here.

My thoughts are that we need to query the blocklist prior to querying the cache and blocklist results should not update the cache.  Not sure what a change like this would do to performance.

[OPNenthu]

The good news is it looks like a fix was quickly proposed in the ticket and it involves not caching domains which have a blocklist policy (I think on any network).  If I understand correctly, the performance hit would then be limited to lookups in which the domain is blocked by another network's policy.

So, basically, ads and other garbage would be served more slowly on unfiltered networks :-)  I can live with that.

Unfortunately the feature is still a non-starter for me, personally, if dynamic IPv6 prefixes aren't handled.  There's a feature request to add dynamic prefix type Aliases (https://github.com/opnsense/core/issues/7000), but I still don't see any way to configure those types of networks in UI forms that require text input rather than Aliases.  Is this something being worked on in OPNsense in order to make IA_PD more usable?

[franco]

The alias support wouldn't help with Unbound, though. It's a situation where ISPs and software authors involved said: we don't care and the user or integrator can script it, wich leads to dissatisfaction as much as satisfaction.

For one you'd need to invent a suffix notation that includes the interface and the netmask:

::123:0:0:0:0/64%lan

And then you need to translate it all the time and support it seamlessly across a inhomogeneous software landscape?


Cheers,
Franco

[gpfountz]

I haven't enabled the per-network DNSBL on my end as of yet, but for those who are seeing this- are you using dynamic IPv6 prefixes?  I'm looking at the Source Nets field and I don't know how you would even configure it for e.g. IA_PD.

AFAIK, we don't (yet) have any mechanism to track those for use in form fields like this.  Am I misinformed, or is this feature presently limited to IPv4 and IPv6 networks where the prefixes are not changing?

In any case: https://github.com/opnsense/core/issues/9474

I have applied the patch for issue 9474 and can confirm the fix is working properly.

Thanks to the developers for making this change!!

[OPNenthu]

For one you'd need to invent a suffix notation that includes the interface and the netmask:

::123:0:0:0:0/64%lan

Hmm... but if I'm not concerned with hosts and instead I want to just specify a network to the Unbound config, could we not have a syntax to reference that information from either Track Interface or a network Alias on the back end?

I was imagining that the Unbound form could take something like this for input:

"192.168.1.0/24, [LAN/64]"

Of course there would need to be accompanying code to interpret that... somewhere.  :-(

Or, better, expose an option to select an interface (no IPs needed).

If not then, are we already at an impasse with IPv6 PD as a viable migration path from IPv4?

[Monviech (Cedrik)]

The issue is if you implement outside scripting that is not natively supported by the application, your only chance is to restart it all the time whwn the environment changes.

If applications would support more features like dnsmasq (which can track IPv6 addresses on interfaces, partial ones as well) it would be better. But it speaks books even KEA cannot work with dynamic prefixes (Lol btw).

[franco]

[LAN/64]

is the same as

::123:0:0:0:0/64%lan

except that in the latter you can merge the prefix from LAN with a suffix for better targeting.

Though we were talking today about the possibility to design a simple "LAN" (per-interface) type setting that latches on to all networks currently present on the interface. I'm not saying it will happen, but it would be the simplest solution although in reality it will require a number of changes and additions to get it to the finish line in a pretty full schedule we already have.

> If not then, are we already at an impasse with IPv6 PD as a viable migration path from IPv4?

As long as ISPs will milk users for static prefixes or not offer them at all... yes.

We've been at the trying to handle end with DHCPv6, ISC, DHCP, Radvd and Unbound and it's spaghetti code that produced unnecessary bugs and reworks over the years. Even today we need a daemon to watch a modern software daemon like Kea writing a lease file so that we can extract a PD assignment to add a route. You'd think by now bindings would do that in modern software, but they don't do this in a consistent way.

I don't understand it actually... everyone is asking here to fix PD for users but we're not the ones who hand out PDs or write the actual software based on the RFCs to do it?!


Cheers,
Franco

[OPNenthu]

I don't understand it actually... everyone is asking here to fix PD for users but we're not the ones who hand out PDs or write the actual software based on the RFCs to do it?!

I understand, but if the firewalls can't work with the RFCs or vice-versa, then something is broken.  The RFC people didn't talk with the network admins, I guess.  This is a mess because the internet is in transition to IPv6 and us non-corporate users without elaborate DHCP setups will be stuck holding the bag.

Maybe I can do something with NPT, but a point of IPv6 was to do away with address translation and centralized control mechanisms.

I'm so confused. :-/

As long as ISPs will milk users for static prefixes or not offer them at all... yes.

Maybe we will all sooner win the lottery :-)

[franco]

> I understand, but if the firewalls can't work with the RFCs or vice-versa, then something is broken.

This isn't about the RFCs. It's about asking a firewall/router/distro to reload everything while reconnecting the WAN to a new prefix.

I think to this day Unbound doesn't even have a proper reload. Dnsmasq is the only software I know that has a built in for a prefix matching. pf doesn't have it either but it would be so useful, but apparently not for the use cases it is written. Maybe that's the real issue here why home users are sidelined. They are not considered a use case.


Cheers,
Franco