23.01 Unable to answer DNS queries after upgrade

stephenw10

Ok, I'll try to replicate it.

jimp

We've had a couple threads with similar reports but I've never been able to trigger it in my lab. It could be a timing issue where at the moment it collects the networks for the ACLs they aren't on the interface (yet?) but then they appear later, but there is no interface event when the delegated prefix gets added to the LAN(s) so Unbound doesn't restart after to pick up the change in ACLs.

No amount of fiddling with options is likely to have any more impact than simply saving in Unbound without changing anything, triggering it to rewrite its config files.

Bob.Dig

@jimp Is this regarding to OP or "to the rest", because OPs problem is gone as far as I can see.
For me I have ULAs so no delegated prefix at all and unbound still only allows IPv4. Also I am rebooting my pfSense on a daily bases via cron. Restarting Unbound doesn't solves this. If it helps you could move my thread in an active forum.

jimp

Adding a manual ACL works around the issue but it doesn't solve the root cause of the problem.

By default the IPv4 and IPv6 networks of all local (non-WAN) interfaces used by Unbound should be allowed through Unbound. If the list is incomplete in some way then the networks were not on the interface when the Unbound config was generated.

Bob.Dig

@jimp I will delete it manually if you tell a windows noob where to find it, I have not that much options set.

jimp

The ACLs are in /var/unbound/access_lists.conf so that's where I'd look.

Even with your manual ACL entry the automatic ones will still be there.

Anyone who sees this should check the file before touching anything else and then again after restarting Unbound to see if there is a difference.

thebear

@jimp

It seems only the loopbacks are in the auto config. I'm using DHCP-PD for my LAN.

With my manual IPv6 ACL

[23.01-RELEASE][admin@pfSense.high.local]/root: cat /var/unbound/access_lists.conf
access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.10.10.0/24 allow
access-control: 10.81.240.0/22 allow
access-control: 10.110.1.0/24 allow
access-control: 10.110.2.0/24 allow
access-control: 127.0.0.0/8 allow
access-control: 172.16.1.0/24 allow
access-control: 172.16.2.0/24 allow
access-control: 172.16.6.0/24 allow
access-control: 172.16.7.0/24 allow
access-control: 172.16.8.0/24 allow
access-control: 172.16.26.0/24 allow
access-control: 172.16.27.0/24 allow
access-control: ::1/128 allow
#WireGuard
access-control: 10.10.10.0/24 allow
#IPv6
access-control: 2a02:a469:<cut>::/48 allow

With the default auto generated ACL where the DNS request at the IPv6 address are REFUSED.

[23.01-RELEASE][admin@pfSense.high.local]/root: cat /var/unbound/access_lists.conf
access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.10.10.0/24 allow
access-control: 10.81.240.0/22 allow
access-control: 10.110.1.0/24 allow
access-control: 10.110.2.0/24 allow
access-control: 127.0.0.0/8 allow
access-control: 172.16.1.0/24 allow
access-control: 172.16.2.0/24 allow
access-control: 172.16.6.0/24 allow
access-control: 172.16.7.0/24 allow
access-control: 172.16.8.0/24 allow
access-control: 172.16.26.0/24 allow
access-control: 172.16.27.0/24 allow
access-control: ::1/128 allow
#WireGuard
access-control: 10.10.10.0/24 allow

jimp

@thebear So your LAN interface(s) use track6 and get allocations from a DHCPv6 WAN?

thebear

@jimp yes

EDIT extra info regarding the WAN its PPPoE @jimp

via unmanged SLAAC

Bob.Dig

@jimp said in 23.01 Unable to answer DNS queries after upgrade:

The ACLs are in /var/unbound/access_lists.conf so that's where I'd look.

Yes but that was already done in some other threads around this problem. I am willing to delete my whole resolver config if it helps.

Bob.Dig

There is a working fix here.