23.01 Unable to answer DNS queries after upgrade

michmoor

After the upgrade, all clients are not able to resolve certain domains. reddit or microsoft or google.com
I made sure pfsense is able to resolve and it can without issue so the problem is isolated o clients <> pfsense.
All clients point to pfsense as the default gateway and dns server. PF cannot provide DNS answers.
This was not a problem prior to the upgrade.
The solution so far has been to change DNS Servers from 1.1.1.1 to 8.8.8.8. That seems to fix it for the moment. I havent tried restarting Unbound.
I do not have pfblockerNG installed.

MoonKnight

@michmoor
The best thing to do is probably to a restart of the system after upgrading. I haven't upgrade yet, but going to to it later this evening.

stephenw10

You see any errors in the DNS Resolver logs?

Do you see those domains listed in Status > DNS Resolver?

jimp

Are you using anything special in your forwarding, such as DNS over TLS? Or are they just plain forwards?

I have systems in my lab that are running 23.01 and hit 1.1.1.1 OK.

Bob.Dig

No problems here.

What is still a problem is Query refused if using an ULA for LAN.

*** UnKnown can't find reddit.com: Query refused

thebear

@bob-dig said in 23.01 Unable to answer DNS queries after upgrade:

No problems here.

What is still a problem is Query refused if using an ULA for LAN.
*** UnKnown can't find reddit.com: Query refused

Did you correct the ACL to allow these addresses to query DNS?

Bob.Dig

@thebear No, I changed nothing and the ULA is the only or lets say main IPv6 address on LAN.

hn0.100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	description: LAN
	options=80000<LINKSTATE>
	ether 00:15:5d:09:1e:19
	inet6 fe80::215:5dff:fe09:1e19%hn0.100 prefixlen 64 scopeid 0x18
	inet6 fd7b:97bf:48b9:100:192:168:100:1 prefixlen 64
	inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
	groups: vlan GroupNTP
	vlan: 100 vlanproto: 802.1q vlanpcp: 0 parent interface: hn0
	media: Ethernet autoselect (10Gbase-T <full-duplex>)
	status: active
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

michmoor

Update for everyone.

So far the fix for this was to re-do the DoT settings again. I went into DNS Resolver settings. Unchecked and then rechecked the following options.

2hrs later the firewall is still answering queries so that seems to have fixed it.

Bob.Dig

@thebear For the record, manually creating an ACL solves the problem but it shouldn't be necessary to begin with.

thebear

@bob-dig why? I also needed to add a IPv6 ACL next to my IPv4 ACL I got with 22.05. Somehow the behavior has changed with 23.01.

Without the ACL's, where is the allow all option? If that not exists then the ACL is needed, right?

Bob.Dig

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

Without the ACL's, where is the allow all option?

Here it is:

thebear

@bob-dig Yeah I know, without the boxes checked pfSense should add the auto rules to unbound right?

And you confirming, my experiences, that is starts working after adding a manual IPv6 ACL.

Get my point there might be a bug involved in the default/auto ACL's for IPv6?

thebear

Here is the proof, without ACL's IPv4 remains functional and IPv6 stops.

status: REFUSED

~ % dig @172.16.1.1 forum.netgate.com

; <<>> DiG 9.10.6 <<>> @172.16.1.1 forum.netgate.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57847
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;forum.netgate.com.		IN	A

;; ANSWER SECTION:
forum.netgate.com.	1485	IN	A	208.123.73.199

;; Query time: 134 msec
;; SERVER: 172.16.1.1#53(172.16.1.1)
;; WHEN: Thu Feb 16 11:18:34 CET 2023
;; MSG SIZE  rcvd: 62

~ % dig forum.netgate.com

; <<>> DiG 9.10.6 <<>> forum.netgate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 58561
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 43 msec
;; SERVER: 2a02:a469:<cut>#53(2a02:a469:<cut>)
;; WHEN: Thu Feb 16 11:18:40 CET 2023
;; MSG SIZE  rcvd: 12

With the ACL added:

 ~ % dig forum.netgate.com

; <<>> DiG 9.10.6 <<>> forum.netgate.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44698
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1432
;; QUESTION SECTION:
;forum.netgate.com.		IN	A

;; ANSWER SECTION:
forum.netgate.com.	1267	IN	A	208.123.73.199

;; Query time: 41 msec
;; SERVER: 2a02:a469:435b:<cut>#53(2a02:a469:<cut>)
;; WHEN: Thu Feb 16 11:22:13 CET 2023
;; MSG SIZE  rcvd: 62

Bob.Dig

@thebear I thought it would only be a "bug" with ULA but yours even look like a GUA.

thebear

@bob-dig said in 23.01 Unable to answer DNS queries after upgrade:

@thebear I thought it would only be a "bug" with ULA but yours even look like a GUA.

Indeed. Glad we came to the same conclusion.

stephenw10

So to be clear you did not need those ACLs in 22.05? The auto added ACLs were passing v6 queries there?

Steve

thebear

@stephenw10 well as IT expert you change a lot every week, I think the short answer is yes. We did not need the extra v6 ACL to get the IPv6 DNS queries flowing.

If you want I can BE boot to an older release tot verify, need to wait until later tonight.

Bob.Dig

@stephenw10 I even had dns problems in Windows, it would prefer the IPv6 that is given by pfSense and then it doesn't worked. Only because of the DNS problem in Windows I had to look closer.
Later Windows switched to the IPv4 and DNS worked again "on its own". But I never encountered that problem before so my guess is, it must have worked before. And again, pfSense is giving this address... its interface address. Like seen here.

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.