I am puzzled. A DNS request for servers.rmnoise.com returns IP address 100.64.3.4 while the real IP addresses are 184.80.221.105 AND 174.170.161.132. 192.168.1.1 is my Opnsense FW. Here is a Wireshark capture.
(https://i.ibb.co/w7ygHx5/tempsnip.png) (https://ibb.co/hcs95t3)
I don't have any DNS issues at all besides the one with servers.rmnoise.com.
Any ideas?
overrides on your dns server giving the answer (opn but dnsmasq, bind, unbound, etc.)
No overrides configured
dig is your friend but you probably want to look at the corresponding packet capture on the WAN interface.
This is what your OPN is giving back, but that would be what is either received from its configured upstreams, or overrides.
The FW gets the correct IP's
16:23:46.614491 IP 84-73-XXX-XXX.dclient.hispeed.ch.48804 > dns.google.domain: 61194+ [1au] A? servers.rmnoise.com. (48)
16:23:46.633358 IP dns.google.domain > 84-73-XXX-XXX.dclient.hispeed.ch.48804: 61194 2/0/1 A 174.170.161.132, A 184.80.221.105 (80)
In that case I assume that unbound gives you the wrong answers for some reason.
100.64.3.4 is from 100.64.0.0/10 that is used for CG/NAT and or DS-Lite.
Here (https://www.reddit.com/r/OPNsenseFirewall/comments/16hc1z8/dhcp_unbound_issues_again/) is someone with a similar problem.
There are several possibilities:
- Wireguard or other VPN with broken routing
- Did you setup servers on you LAN and had their "final" hostnames already configured or are they really in your own LAN and building up a VPN to somewhere else?
In the latter case, note that DHCP registers the hostnames in unbound if so configured. You can look into this by finding the IP or the name in your OpnSense configuration like this:
fgrep -r 100.64.3.4 /var/unbound/*.conf
Nope, wrong direction. Zenarmor was the problem. Zenarmor -> servers.rmnoise.com -> parked domain, returns 100.64.3.4. Now fixed
Oh well, you did not tell that you use it.
Zenarmor can do stranger things than that being a 3rd party extension. Consider disabling it first when you notice something strange/unexpected happens. Be careful with OpnSense updates as well - because often, Zenarmor breaks with these for a while.
I don't want to hijack this thread, but I'm really curious why Zenarmor breaking and doing weird things after updates is still an issue today. I first tried it out when it was still called Sensei, had it on multiple firewalls, but after a few failed updates I've decided not to use it anymore.
I wonder if Zenarmor could be integrated more neatly since it's an official partnership. Maybe Zenarmor could hook into the actual "Check for Updates" when Zenarmor is installed, and block the ability to install an update until they verified it not breaking their integration. Their users would then get OPNsense Updates more slowly than the rest, but maybe it would at least minimize the risk?
It has integrated a lot more in my opinion. I wouldn't call it does weird things but we are reminded if using it, that dns results like in this case that look odd, shoud cause to check or disable as meyergru says.
It seem to have a few false steps in the last couple of months I think with an update but otherwise seems fine.
That said, I'd like to have more than one policy on the free tier and improvements on live tracing but not complaining.