Home
Help
Search
Login
Register
OPNsense Forum
»
Archive
»
23.7 Legacy Series
»
Incorrect handling of CNAME records which resolve to CNAME records
« previous
next »
Print
Pages: [
1
]
Author
Topic: Incorrect handling of CNAME records which resolve to CNAME records (Read 676 times)
CJ
Hero Member
Posts: 832
Karma: 30
Incorrect handling of CNAME records which resolve to CNAME records
«
on:
September 20, 2023, 05:20:36 pm »
TLDR: Handling of CNAME records that resolve to CNAME records are broken and do not work as CNAME records which resolve to A/AAA records do.
It appears that CNAME lookups are still be processed by Unbound and stored in the cache despite being on the DNSBL. The Unbound reporting shows a resolve time of 0ms for A and AAA records from the cache or DNSBL. But CNAME queries show a resolve time indicative of an actual query despite being blocked by the DNSBL.
You can test this by enabling the EasyPrivacy list in DNSBL settings and then doing a DNS lookup for "g.live.com". It will show as blocked but have a non-zero resolve time. The "g.live.com" CNAME resolves to "g.msn.com" but if you do a lookup for "g.msn.com" it will be blocked as an A record and show a resolve time of 0ms.
The especially odd part is the "g.msn.com" is actually a CNAME record. It resolves to "g-msn-com-nsatc.trafficmanager.net" which is an actual A record and not on the DNSBL.
In a default Unbound setup, when testing with dig or nslookup "g.live.com" returns no records while "g.msn.com" returns the 0.0.0.0 from the DNSBL default. Using the OPNSense DNS lookup page returns a TXT and MX record for "g.live.com" resolving to "g.msn.com" CNAME which resolves to "g-msn-com-nsatc.trafficmanager.net"
Using the OPNSense DNS lookup page returns an A record of 0.0.0.0 for "g.msn.com" but the CNAME TXT and MX records which resolve to "g-msn-com-nsatc.trafficmanager.net"
The end result to most users is the same whether getting no record returned for "g.live.com" or the 0.0.0.0 returned for "g.msn.com" in that the attempted access is blocked.
The wrinkle happens if you configure Unbound to server expired cache entries. Because the "g.live.com" CNAME lookup takes some time, Unbound returns the cache entry from the previous lookup. Despite showing in Unbound reporting as being blocked, the "g.live.com" cache entry resolving to "g.msn.com" which resolves to "g-msn-com-nsatc.trafficmanager.net" is provided to the client and they can successfully connect to the provided ip.
Because "g.msn.com" is treated as an A record instead of the CNAME it is, it immediately gets resolved by the DNSBL and 0.0.0.0 gets sent to the client instead of using a cache entry.
"g.live.com" is the only DNS record I've managed to see this with. Everything else seems to work like the "g.msn.com" CNAME and get properly blocked.
«
Last Edit: September 21, 2023, 06:23:37 pm by CJ
»
Logged
Have Answer, Will Blog
CJ
Hero Member
Posts: 832
Karma: 30
Re: Incorrect handling of CNAME records which resolve to CNAME records
«
Reply #1 on:
September 21, 2023, 06:24:05 pm »
Updated title and added TLDR which more clearly explains the problem.
Logged
Have Answer, Will Blog
Print
Pages: [
1
]
« previous
next »
OPNsense Forum
»
Archive
»
23.7 Legacy Series
»
Incorrect handling of CNAME records which resolve to CNAME records