pfsense dashboard show "Unable to check for update" via Quad9 DNS
-
If the query answer from " 9.9.9.9#853" is sympathetically "THROWAWAY" you can do 2 things :
Stop using TLS or even stop using 9.9.9.9.You're sure nothing is filtered upstream ?
I sawdebug: tcp error for address 9.9.9.9 port 853
As TLS over port 853 needs TCP, and TCP is bad, then 9.9.9.9 doesn't even receive your request correctly ( ? ) ....
When the quad9 issues go away (thrown away ;) ) I advise you to look at other threads in this forum. Because this :
@maverickhl said in pfsense dashboard show "Unable to check for update" via Quad9 DNS:
Jul 13 12:34:45 dhcpleases 14363 Could not deliver signal HUP to process 45787: No such process
is also a possible issue, and discussed a lot on the forum.
It means unbound was in the process of getting restarted - and while it was restarting, it was informed to restart again.
For now : how often does yours restart ?
Go to the page and search for "info: start of service (unbound 1.15.0)." and count them.
How many a day ? per hour ? even more ? -
Still not seeing any logs for
info: resolving. Everything in your logs appears to be reverse lookup for PTR. So I'd suggest it's not using Unbound for those lookups. Something is not configured as you expect it to be.
However even if that is that case it's hard to explain why pkg update works but the dashboard check does not.
Try to resolve ews.netgate.com in Diag > DNS Lookup. Make sure all the defined servers there can resolve it.Steve
-
ews.netgate.com does resolve returning an IP of 208.123.73.93
I turned off DoT and the results are not any better and can't find any info: resolving lines during the update check:
Jul 14 08:59:42 unbound 12183 [12183:0] info: control cmd: stats_noreset
Jul 14 08:59:42 unbound 12183 [12183:0] debug: new control connection from 127.0.0.1 port 40927
Jul 14 08:59:42 unbound 12183 [12183:0] debug: cache memory msg=158472 rrset=215935 infra=8306 val=95561
Jul 14 08:59:42 unbound 12183 [12183:0] info: validator operate: query 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 08:59:42 unbound 12183 [12183:0] debug: validator[module 0] operate: extstate:module_wait_module event:module_event_moddone
Jul 14 08:59:42 unbound 12183 [12183:0] debug: return error response SERVFAIL
Jul 14 08:59:42 unbound 12183 [12183:0] debug: configured stub or forward servers failed -- returning SERVFAIL
Jul 14 08:59:42 unbound 12183 [12183:0] info: processQueryTargets: 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 08:59:42 unbound 12183 [12183:0] info: query response was THROWAWAY
Jul 14 08:59:42 unbound 12183 [12183:0] info: reply from <.> 9.9.9.9#53
Jul 14 08:59:42 unbound 12183 [12183:0] info: response for 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 08:59:42 unbound 12183 [12183:0] info: iterator operate: query 4.4.8.8.in-addr.arpa. PTR IN -
Mmm, so exactly what settings do you have in System > General Setup and in Unbound?
-
Nothing fancy, but here are the main things I have setup:
System General Setup:
Added DNS 9.9.9.9 and 149.112.112.112
Set DNS behavior to Use Local then remote (default)
DNS Resolver Settings:
Network Interface = All
Outgoing Network Interface = WAN
Domain Local Zone Type = Transparent
DNSSEC = FALSE
DNS Query Forward = TRUE
Use SSL/TLS = TRUE
DHCP Reg = TRUE
Static DHCP = TRUE
Advanced Config =server:include: /var/unbound/pfb_dnsbl.*conf
server:
log-queries: yesAdvanced Tab:
Everything left default except when changing log level to 3.
-
Hmm, the only thing different I have is the custom entry you have:
server: log-queries: yesBut I see all the queries logged so I suspect you may have created a conflict there. Try removing that.
Steve
-
Sadly, nope same odd response back and no info: resolve lines -_-;
Jul 14 10:45:31 unbound 88800 [88800:0] debug: cache memory msg=68474 rrset=68889 infra=8306 val=0
Jul 14 10:45:31 unbound 88800 [88800:0] debug: return error response SERVFAIL
Jul 14 10:45:31 unbound 88800 [88800:0] debug: configured stub or forward servers failed -- returning SERVFAIL
Jul 14 10:45:31 unbound 88800 [88800:0] info: processQueryTargets: 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: query response was THROWAWAY
Jul 14 10:45:31 unbound 88800 [88800:0] info: reply from <.> 9.9.9.9#853
Jul 14 10:45:31 unbound 88800 [88800:0] info: response for 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: iterator operate: query 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Jul 14 10:45:31 unbound 88800 [88800:0] debug: cache memory msg=68284 rrset=68889 infra=8306 val=0
Jul 14 10:45:31 unbound 88800 [88800:0] debug: sending to target: <.> 9.9.9.9#853
Jul 14 10:45:31 unbound 88800 [88800:0] info: sending query: 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: processQueryTargets: 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: query response was THROWAWAY
Jul 14 10:45:31 unbound 88800 [88800:0] info: reply from <.> 9.9.9.9#853
Jul 14 10:45:31 unbound 88800 [88800:0] info: response for 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: iterator operate: query 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] debug: iterator[module 0] operate: extstate:module_wait_reply event:module_event_reply
Jul 14 10:45:31 unbound 88800 [88800:0] debug: cache memory msg=68284 rrset=68889 infra=8306 val=0
Jul 14 10:45:31 unbound 88800 [88800:0] debug: sending to target: <.> 9.9.9.9#853
Jul 14 10:45:31 unbound 88800 [88800:0] info: sending query: 4.4.8.8.in-addr.arpa. PTR IN
Jul 14 10:45:31 unbound 88800 [88800:0] info: processQueryTargets: 4.4.8.8.in-addr.arpa. PTR INI do think it is Quad9's issue and mostly likely regional. I had to send a few DNS resolution request for their upstream provider to fix since some websites were not resolving but was apparently accessible based on their domain checker.
-
Hmm. Weird that it's not showing queries in unbound though. Seems like however it's failing could be because it's not going via Unbound...
