This is a weird one.
Since upgrading to the 23.x.x firmware unbound has been causing me no end of issues.
Config:
Services: Unbound DNS: General: Enable DNS64 Support - checked
Services: Unbound DNS: General: DNS64 Prefix - 64:ff9b::/96
Services: Unbound DNS: General: Flush DNS Cache during reload - checked
Services: Unbound DNS: General: Local Zone Type - transparent
Services: Unbound DNS: Overrides - none
Services: Unbound DNS: Advanced: General Settings - nothing checked, all values at defaults.
Services: Unbound DNS: Query Forwarding: Use System Nameservers - checked
If I do a DNS lookup from the firewall via diagnostics I get this
Response
Type Answer Server Query time
A www.msn.com. 11115 IN CNAME www-msn-com.a-0003.a-msedge.net.
www-msn-com.a-0003.a-msedge.net. 130 IN CNAME a-0003.a-msedge.net.
a-0003.a-msedge.net. 238 IN A 204.79.197.203 127.0.0.1 0 msec
MX www.msn.com. 7978 IN CNAME www-msn-com.a-0003.a-msedge.net.
www-msn-com.a-0003.a-msedge.net. 65 IN CNAME a-0003.a-msedge.net. 127.0.0.1 28 msec
TXT www.msn.com. 7978 IN CNAME www-msn-com.a-0003.a-msedge.net.
www-msn-com.a-0003.a-msedge.net. 65 IN CNAME a-0003.a-msedge.net. 127.0.0.1 0 msec
I then do a lookup form the host ok, however, when I do second lookup I get this error
Server: OPNsense.localdomain
Address: <my LAN interface IP>
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for www.msn.com
and when I do a second internal lookup no A record is returned ONLY the TXT and MX record.
Here is a snip from the log viewer for a good lookup
2023-09-28T18:15:38 Informational unbound [18005:1] info: 127.0.0.1 www.msn.com. TXT IN NOERROR 0.000000 1 145
2023-09-28T18:15:38 Informational unbound [18005:1] info: 127.0.0.1 www.msn.com. TXT IN
2023-09-28T18:15:38 Informational unbound [18005:3] info: 127.0.0.1 www.msn.com. MX IN NOERROR 0.037137 0 145
2023-09-28T18:15:38 Informational unbound [18005:3] info: 127.0.0.1 www.msn.com. MX IN
2023-09-28T18:15:38 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. AAAA IN NOERROR 0.010582 0 29
2023-09-28T18:15:37 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. AAAA IN
2023-09-28T18:15:37 Informational unbound [18005:0] info: 127.0.0.1 www.msn.com. A IN NOERROR 0.000000 1 104
2023-09-28T18:15:37 Informational unbound [18005:0] info: 127.0.0.1 www.msn.com. A IN
2023-09-28T18:15:36 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. TXT IN NOERROR 0.000000 0 145
2023-09-28T18:15:36 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. TXT IN
2023-09-28T18:15:36 Informational unbound [18005:3] info: 127.0.0.1 www.msn.com. MX IN NOERROR 0.026181 0 145
2023-09-28T18:15:36 Informational unbound [18005:3] info: 127.0.0.1 www.msn.com. MX IN
2023-09-28T18:15:36 Informational unbound [18005:1] info: 127.0.0.1 www.msn.com. AAAA IN NOERROR 0.043634 0 29
2023-09-28T18:15:36 Informational unbound [18005:1] info: 127.0.0.1 www.msn.com. AAAA IN
2023-09-28T18:15:36 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. A IN NOERROR 0.022878 0 29
2023-09-28T18:15:36 Informational unbound [18005:2] info: 127.0.0.1 www.msn.com. A IN
Here is the second lookup - the one that returns no A records
2023-09-28T18:17:02 Informational unbound [18005:2] info: 192.168.3.2 www.msn.com. AAAA IN NOERROR 0.057046 0 29
2023-09-28T18:17:02 Informational unbound [18005:2] info: 192.168.3.2 www.msn.com. AAAA IN
2023-09-28T18:17:02 Informational unbound [18005:1] info: 192.168.3.2 www.msn.com. A IN NOERROR 0.020184 0 29
2023-09-28T18:17:02 Informational unbound [18005:1] info: 192.168.3.2 www.msn.com. A IN
2023-09-28T18:17:02 Informational unbound [18005:0] info: 192.168.3.2 www.msn.com.localdomain. AAAA IN NXDOMAIN 0.000000 1 116
2023-09-28T18:17:02 Informational unbound [18005:0] info: localdomain. transparent 192.168.3.2@54870 www.msn.com.localdomain. AAAA IN
2023-09-28T18:17:02 Informational unbound [18005:0] info: 192.168.3.2 www.msn.com.localdomain. AAAA IN
2023-09-28T18:17:02 Informational unbound [18005:2] info: 192.168.3.2 www.msn.com.localdomain. A IN NXDOMAIN 0.000000 1 116
2023-09-28T18:17:02 Informational unbound [18005:2] info: localdomain. transparent 192.168.3.2@51736 www.msn.com.localdomain. A IN
2023-09-28T18:17:02 Informational unbound [18005:2] info: 192.168.3.2 www.msn.com.localdomain. A IN
I have had to revert to DNSmasq till I get this sorted.
Any help appreciated. :-\
Quote from: nerf on September 28, 2023, 10:19:13 AM
Services: Unbound DNS: Query Forwarding: Use System Nameservers - checked
Why you forward queries to system DNS?
Unbound is good on resolving DNS names by itself.
How you configured "the system DNS"?
Additional note, "msn.com" resolves fine.
Ok. Now, disabled query forwarding. Same result.
System: Settings: General: Prefer IPv4 over IPv6 - checked
System: Settings: General: DNS servers - 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1 (use gateway - none)
Other options unchecked.
Some lists in the blocklist section will even lock Microsoft updates, seems like you're in that situation.
If that's not the case your upstream DNS is doing something weird, and you should consider encrypting all your queries outbound
There's also something going on with CNAME resolution in Unbound if you're using blocklists. I haven't dug into it enough to know if it also happens when not using blocklists.
I don't recall if Unbound will still hit the root servers if you have DNS entries in System:General.
What happens if you use the DNS Lookup page in OPNSense and put in the various upstream DNS servers you have configured? Do you see A records then?
What does the Unbound Reporting tab show?
Blocklists are not enabled.
A DNS lookup from the firewall works just fine, see my original post.
When a lookup is done from a client machine the first lookup is successful, a second lookup fails,
I have to do a lookup form the firewall (twice as the first one does not return A records) again for the A and AAAA records are populated again.
I am on DNSmasq now but I will turn on DNS reporting and switch over to Unbound and do another test.
Quote from: nerf on September 30, 2023, 02:44:30 AM
Blocklists are not enabled.
A DNS lookup from the firewall works just fine, see my original post.
When a lookup is done from a client machine the first lookup is successful, a second lookup fails,
I have to do a lookup form the firewall (twice as the first one does not return A records) again for the A and AAAA records are populated again.
I am on DNSmasq now but I will turn on DNS reporting and switch over to Unbound and do another test.
Your original post is doing DNS lookups against Unbound. That's not what I asked you to do. Put in your upstream servers on the DNS lookup page instead of leaving the server field blank. See if it changes after multiple lookups like it does with the client.
Ok - did that, got the A records just fine however a lookup from a client still has issues with Microsoft domains BUT I checked the reporting page for Unbound and it looks like the blocklists are kicking in even though I don't have them enabled??
From the client -
nslookup www.outlook.com
Server: 192.168.3.1
Address: 192.168.3.1#53
*** Can't find www.outlook.com: No answer
From Opnsense (server field left blank)
A www.outlook.com. 299 IN CNAME outlook.office365.com.
outlook.office365.com. 59 IN CNAME ooc-g2.tm-4.office.com.
ooc-g2.tm-4.office.com. 59 IN CNAME outlook.ms-acdc.office.com.
outlook.ms-acdc.office.com. 59 IN CNAME SYD-efz.ms-acdc.office.com.
SYD-efz.ms-acdc.office.com. 9 IN A 40.99.133.242
SYD-efz.ms-acdc.office.com. 9 IN A 52.98.142.210
SYD-efz.ms-acdc.office.com. 9 IN A 52.98.8.34
SYD-efz.ms-acdc.office.com. 9 IN A 52.98.0.178 1.1.1.1 10 msec
MX www.outlook.com. 154 IN CNAME outlook.office365.com.
outlook.office365.com. 58 IN CNAME ooc-g2.tm-4.office.com.
ooc-g2.tm-4.office.com. 60 IN CNAME outlook.ms-acdc.office.com.
outlook.ms-acdc.office.com. 59 IN CNAME SYD-efz.ms-acdc.office.com. 8.8.4.4 16 msec
TXT www.outlook.com. 300 IN CNAME outlook.office365.com.
outlook.office365.com. 60 IN CNAME ooc-g2.tm-4.office.com. 1.1.1.1 20 msec
Can you post a screenshot of your DNSBL page with advanced turned on and one of the Unbound reporting screen?
During my troubleshooting I removed the blocklists entirely rather than just disabling and lookups started to work. I have reinstated the blocklists and enabled it and still working ok. I will keep unbound in service for now and see what happens.
If I get an error I will post the screenshots. :-\
Why do you have DNS64 Support enabled? You might want to disable that if you don't have a explicit need for it.
Quote from: nerf on October 02, 2023, 09:43:29 AM
During my troubleshooting I removed the blocklists entirely rather than just disabling and lookups started to work. I have reinstated the blocklists and enabled it and still working ok. I will keep unbound in service for now and see what happens.
If I get an error I will post the screenshots. :-\
Did you restart Unbound after disabling the blocklists? Otherwise you can end up in the case where it's serving things from the cache that you don't expect. Especially in the case of CNAMEs.
I haven't dug into this topic too much but I also notice that many Microsoft domains do not resolve on my internal network. Lookups on OPN directly work.
Example: g.msn[.]com
I was hoping that some update would fix that issue...
Quote from: adk20 on November 06, 2023, 08:18:11 PM
I haven't dug into this topic too much but I also notice that many Microsoft domains do not resolve on my internal network. Lookups on OPN directly work.
Example: g.msn[.]com
I was hoping that some update would fix that issue...
Start a new thread and post the results of the various troubleshooting steps listed in this thread.
Quote from: adk20 on November 06, 2023, 08:18:11 PM
I haven't dug into this topic too much but I also notice that many Microsoft domains do not resolve on my internal network. Lookups on OPN directly work.
Example: g.msn[.]com
I was hoping that some update would fix that issue...
Are you using blocklists? If you do there most probably is no "issue". Microsoft domains frequently end up on blocklists, all the more so if you pull in a lot of them managed by volunteers.
Disable all block lists. Working now? If yes, then it's one of the blocklists, none of which are managed by the OPNsense project and none of which can be fixed by the OPNsense project.
If no,
then we have an issue.
Hello,
I was having the same issue.
Brand new installation, only the DHCP configured, used openDNS as dns IPs. unbound DNS was by the absolutest default configuration possible (brand new install and server).
My test computer connected on the LAN side could go on the internet, it could actually search for updates, but couldn't download the updates. And i couldn't figure out why until i found this post: somehow the blocklist is activated and is actively blocking some microsoft websites despite being unchecked (bing, msn, outlook, microsoft.com...) I had to whitelist those for the updates to work.
Quote from: newsense on September 29, 2023, 08:32:13 AM
Some lists in the blocklist section will even lock Microsoft updates, seems like you're in that situation.
If that's not the case your upstream DNS is doing something weird, and you should consider encrypting all your queries outbound
Quote from: CJ on October 01, 2023, 03:11:14 PM
Can you post a screenshot of your DNSBL page with advanced turned on and one of the Unbound reporting screen?
Quote from: Patrick M. Hausen on November 07, 2023, 02:53:01 PM
Are you using blocklists? If you do there most probably is no "issue". Microsoft domains frequently end up on blocklists, all the more so if you pull in a lot of them managed by volunteers.
Disable all block lists. Working now? If yes, then it's one of the blocklists, none of which are managed by the OPNsense project and none of which can be fixed by the OPNsense project.
If no, then we have an issue.
Still not clear which lists are enabled at all, but there are some blocklists built in that explicitely blocks microsoft stuff:
- WindowsSpyBlocker (spy)
- WindowsSpyBlocker (update)
- WindowsSpyBlocker (extra)
If one simly enables all blocklists without reading, this may lead to described behaviour too.
More details on these lists can be found here https://crazymax.dev/WindowsSpyBlocker/blocking-rules/
For extra list it explicitely says:
QuoteONLY use if you know what you do
Be aware that these rules can also block Windows Update and other services.
Therefore, no support will be provided on them.
Quote from: marunjar on January 12, 2024, 03:54:19 PM
Still not clear which lists are enabled at all, but there are some blocklists built in that explicitely blocks microsoft stuff:
- WindowsSpyBlocker (spy)
- WindowsSpyBlocker (update)
- WindowsSpyBlocker (extra)
While that's true, I think a lot of these cases are due to the way the current blocklist implementation handles CNAMEs. If the blocklist itself is actively blocking the initial query it's relatively easy to troubleshoot.