Unbound not resolving Microsoft domains

[nerf]

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.

[karlson2k]

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"?

[nerf]

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.

[newsense]

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

[CJ]

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?

[nerf]

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.

[CJ]

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.

[nerf]

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

[CJ]

Can you post a screenshot of your DNSBL page with advanced turned on and one of the Unbound reporting screen?

[nerf]

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.

[BoodahsFever]

Why do you have DNS64 Support enabled? You might want to disable that if you don't have a explicit need for it.

[CJ]

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.

[adk20]

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...

[CJ]

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.

[Patrick M. Hausen]

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.