Topics

To anyone in the know, is public-dns.info still actively updated? Thier last changelog entry is from 2020, and on the main front page the recent server last checked times all show 2 years ago. Thier Contact link also forwards to a different site.

If they aren't active anymore, is there another such actively updated public DNS server list that I can use in Opnsense as an alias for blocking purposes?

I have a wierd issue on my network and I'm stumped as to the origin. Opnsense, for the 2nd time in a week, has gotten rate limited by Pi-Hole, even with the limit set to 6000 DNS quieres in a minute by a client. I wasn't able to see anything in the Pi-hole logs the last time it happened (I didnt noticed it before "old" logs were purged), but this time I caught it. Seems like Opnsense is making DNS requests for "quantumwarp-dot-com", almost 8k requests in less then 15 seconds. I don't have any logging on the Opnsense side that would show why that is happening, but from the looks of Pi-hole, it's originating from Opnsense, as all LAN DNS requests must go through Pi-hole first, even those from Opnsense, before going through Unbound (on Opnsense) and out to the WAN. The last time I had malformed DNS requests, it was because of a old alias that was trying to update a no-longer installed script in Opnsense. Currently, I have nothing custom installed in Opnsense, and it is up to date. I do have some "new" to my network docker apps running, but again, the origin is showing as Opnsense.

Anyone else seeing these requests?

How should I go about finding the origin of these requests? Just start logging all DNS requests from Unbound on Opnsense?

My LANs DNS flow is as follows: Unbound on Opnsense makes WAN DNS queries, and is firewalled to only accept DNS request from the 2 Pi-hole DNS servers on my LAN. All LAN devices via DHCP settings are directed to the Pi-holes, and any attempts by LAN devices to connect to WAN DNS servers via port 53, are redirected to the 2 Pi-hole DNS servers. All DNS request which go through Pi-hole, would show up in the Pi-hole logs with the LAN client origin, which means if it was some other device other the Opnsense making those 8k requests, the log would show which client. In this case, it shows that its Opnsense.

Just checked 2nd DNS server logs and that one had over 3k requests in the same time frame. So all in total, Opnsense is making 11k DNS requests in less then 15 seconds for that one domain.

I just noticed today that when I perform a nslookup of the Opnsense firewall FQDN on the LAN side, it responds with the GUA, the fixed IPv4 address, AND the external WAN IPV4 address.

Code Select Expand

Server:  dns.lan.internal
Address:  fe80::xxxx:xxxx:xxxx:xxxx

Non-authoritative answer:
Name:    opnsense.lan.internal
Addresses:  xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
          192.168.2.1
          xxx.xxx.xxx.xxx
Is this normal or some bad configuration on my end that I've made? I wouldn't have noticed it if my PC suddenly was unable to connect to the firewall via the FQDN.

Just updated to 25.1.7_4 today. Everything seemed to be working fine. I closed out my browser, a few hours later I reopened my browser and am now getting a 404 error when trying to access the Web GUI via https and FQDN. Changing to http only changes the 404 error to "CSRF check failed. Your form session may have expired, or you may not have cookies enabled." when trying to login. Access via IPv4 address works as normal.

Anyone else having the same issue? Any suggestions? I didn't change anything from yesterday to today other then updating Opnsense, which was a small update. I had updated just last week so I believe I was on the latest update prior to 25.1.7_4

I've come across a possible bug in DNS resolution of a local LAN FQDN address using ISC DHCPv6 static assignment.

My ISP issues dynamic IPv6 GUA prefixes in the /56 range. LAN is set to Tracking, RA is set to assisted, and I have Unbound setup as the main DNS server, and ISC handling DHCP for both v4 and v6 addresses, as well as passing both dynamic and static assignment DNS information to Unbound.

I normally have IPv6 addresses given out in a certain range (isp:isp:isp:isp::xxxx) via ISC DHCPv6, but am attempting to give out a Static IPv6 address to a single server for access outside my LAN. I configured this Static setting in ISC DHCPv6 by using the 'DUID Identifier', assigning a 'IPv6 address' in the form of (::1.2.3.4) since I have a dynamic IPv6 prefix, and used the same 'Hostname' for the client that I use in the DHCPv4 configuration. The client gets both the correct IPv4 and IPv6 addresses and I am able the forward traffic from the WAN side to the server in my network using its GUA IPv6 address that I assigned it.

The problem (bug?) comes when I try to access that server in my LAN using the FQDN (not IP). I noticed it would take some seconds (sometimes well over 30 seconds) before the server would respond when I tried to connect to it. Seeing as how I had made that ISC DHCPv6 entry just before the issue started happening I ran a simple 'ping server.lan.internal', and it was trying to ping the Static IPv6 portion of the address assigned to that server, *without* the ISP assigned prefix.

Code Select Expand

ping server.lan.internal

Pinging server.lan.internal [::1.2.3.4] with 32 bytes of data:
Running a nslookup resulted in the same portion of the IPv6 being reported without the ISP assigned GUA prefix.

Removing the 'Hostname' in the ISC DHCPv6 entry, restarting ISC DHCPv6 *and* Unbound services, did not clear the DNS responce. I had to reboot Opnsense in order to clear that responce. Once rebooted I was no longer getting any IPv6 address in nslookup, but this means that if I was trying to connect to the server on my LAN using only IPv6, I'd have to use the actual IP, and wouldn't be able to use a FQDN.

TL:DR -  It seems that ISC DHCPv6 is passing a incomplete IPv6 address to Unbound when using a dynamic IPv6 entry (::a.b.c.d) along with it's 'Hostname', and it won't clear without rebooting Unbound.

Going through the release notes of the recent Opnsense version, I'm planning to eventualy switch over from ISC to DNSmasq for my home network. As I was going through setting up the Hosts entries for Static ips, I noticed that the VM I have Pi-hole running on with 2 virtual NICs, has the same DUID for each NIC, which makes sense since it's the same client. Currently ISC DHCPv6 shows that each NIC has a unique IPv6 GUA address, which I assume is because of the client host OS using SLAAC to assign the GUA IPs.

I'm probably just not reading the help documents correctly, or maybe there is a setting I need to toggle, or maybe make use of something else in Opnsense (alias? Unbound Overrides?), but I don't see any way it's possible for me to assign a Static IPv6 GUA address to each individual NIC, if they both use the same DUID (though they do have different MACs). Other then making a 2nd VM for the pi-hole (I abosuletely don't want to do this), what can I do?

Yet another issue I've found which does cause minor problems. I switched the hardware I was running my DNS server (Pi-hole) on, updated any and every entry in Opnsense in regards to IPv6 address (I use fixed link-local fe80: addresses for this), and many of my devices are still using the old IPv6 addresses for DNS server. I've deleted all the leases, I've stopped the ISC DHCPv6, disabled the service entirely, deleted all IPv6 leases in Opnsense list, re-enabled, restarted, forced clients to renew DHCP, and yet they are still getting and using the old IPv6 addresses for the IPv6 DNS servers. Only 1 of my computers so far has changed the IPv6 DNS server address entries to the updated ones.

I exported a configuration to see if I could find where that old IPv6 was showing up and found them in the <dhcpdv6> section.

Code Select Expand

<dhcpdv6>
    <lan>
      <domainsearchlist>home.lan</domainsearchlist>
      <ddnsdomainalgorithm>hmac-md5</ddnsdomainalgorithm>
      <enable>1</enable>
      <range>
        <from>::0</from>
        <to>::ffff</to>
      </range>
      <prefixrange>
        <from/>
        <to/>
        <prefixlength>48</prefixlength>
      </prefixrange>
      <dnsserver/>
      <ntpserver>fe80::xyz</ntpserver>
      <numberoptions>
        <item/>
      </numberoptions>
      <ramode>assist</ramode>
      <rapriority>medium</rapriority>
      <ramininterval>200</ramininterval>
      <ramaxinterval>600</ramaxinterval>
      <radomainsearchlist/>
      <radnsserver>fe80::aaaa</radnsserver> #This contains the old IPv6 DNS server address
      <radnsserver>fe80::bbbb</radnsserver> #This contains the old IPv6 DNS server address
    </lan>
  </dhcpdv6>

The <radnsserver> entries contain the old IPv6 DNS server entries, and I have no idea how to change that in the GUI. I can't even find any reference to that in the ISC DHCPv6 panel at all.

I did however manage to "fix" the issue by editing the configuration file and uploading/applying the new configuration to Opnsense. Now the new IPv6 DNS server addresses are being given to the DHCPv6 clients on my network. If I simply deleted those entries, Opnsense would start giving out the IPv6 address for my ISP dns server (definetely not what I want) even though I have the IPv6 DNS server address entries in System>Settings>General tab setup. I had to change the IPv6 addresses for both of the <radnsserver> entries.

Again, that did fix the issue, but I still have no idea where in the Opnsense GUI that can be changed, if at all, nor why Opnsense continued to use those old entries, and ignore the new ones, when the appropiate changes where made in the ISC DHCPv6 panel.

After updating to OPNsense 24.7.9_1-amd64 via GUI, I'm having 2 issues, 1 very similar to a previous issue in the previous version(s) (22.x-23.x).

First issue; netdata daemon in both the Dashboard>Services info box, and under Services>Netdata>General, shows as not running (Stopped with option available to start), when in fact it is running and available. Attempting to resolve the discrepency in the Opnsense GUI by either Restarting the service, or Stopping then Starting the service, results in Netdata failing to restart at all, and it wont restart until Opnsense itself is rebooted.

This was similar to an issue in 22.x-23.x when certain VPN services would exhibit the same exact issues. I don't believe it was ever fixed. There was a work around but I didn't know how to perform it since there were never any clear instrustions given on how to do so.

Issue 2; ever since update to 24.7.9_1, I now have over 11.5k DNS queries for "<html" and "<!doctype" every 24 hours orginating from my Opnsense box. I'm still going through the various services I have running on some of VMs in my network, but so far it does seem to be Opnsense making those queries, not any of my other VM/PC in my network.

Neither issue is affecting my network or causing downtime, both appear to be just annoyances.