BIND DNS queries fail after upgrading to 24.7.12

[mvglasow]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/src/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/src/issues?q=is%3Aissue

Describe the bug

After updating 24.7.12, I suddenly get sporadic DNS failures. Symptoms are that the web browser on the client will suddenly report a page as down, at some point it works again. Issuing queries with nslookup will return SRVFAIL while the issue persists. Only recursive queries are affected, queries for the zones managed by the server still return a valid result.

To Reproduce

Steps to reproduce the behavior:

1. Configure a DNS server which is authoritative for some zones and acts as a recursive DNS server for others.
2. Update to OPNSense 24.7.12 (earlier 24.7 releases seem unaffected).
3. Use DNS for a while, i.e. issue queries.

Expected behavior

All DNS queries get processed. Both names in my own zones and external names get resolved.

Describe alternatives you considered

Restarting BIND via the web GUI provided no relief. The only alternative I can think of is to disable DNS on OPNsense (using only the Linux server) until the issue is fixed.

Screenshots

n/a

Relevant log files

The BIND log shows this entry:

2025-01-19T00:51:11	Informational	named	19-Jan-2025 00:51:11.358 query-errors: info: client @0x3790f6a70000 192.168.1.2#34589 (gitlab.com): query failed (quota reached) for gitlab.com/IN/A at query.c:7817

This is followed by multiple near-identical entries, except the cause for the failed query is SRVFAIL or just failed instead of quota reached.

Additional context

I upgraded to 24.7.12 today (I was on an earlier 24.7 release before, last upgraded in November).

I have two DNS servers, both serving some internal zones as well as accepting recursive queries, OPNSense is one of them (the other is a Linux machine). The Linux machine does not seem to have any issues, and OPNsense ran fine before the upgrade.

Anecdotal evidence seems to indicate BIND has some quota mechanism in place, but I don’t see that setting exposed through the OPNsense UI (and definitely never set a limit). Also, /usr/local/etc/namedb/named.conf has no entries which look related to quotas.

Has BIND introduced default quotas or lowered a previous default? That would explain the behavior. If not, I’m at a loss.

Environment

OPNsense 24.7.12 (amd64)

[mvglasow]

Update: After switching BIND to IPv4-only mode, I have been running for close to 24 hours without encountering any further issues. (I do not use IPv6 and have not actively configured it anywhere, but some interfaces have link-local IPv6 addresses. The only exception is my WAN connection uses DHCP, with both DHCPv4 and DHCPv6 enabled, but the ISP gives out only IPv4 addresses.)

I also see that one of my workstations prefers the other DNS server (not OPNsense), which may take some load off the server. I’ll keep monitoring the issue over the next few days and report back.

[fichtner]

@mvglasow why is this in src git? Have you pinned this to a kernel change? Bind is a third party tool (ports) the plugin lives in another git, but it might just be a setup issue for core (IPv6 connectivity problems).

[mvglasow]

My bad, I got lost between repos (and didn’t realize BIND is a plugin, not part of the standard package). If this is a bug, it might be either BIND or the plugin – where should I file this if the component is unclear and requires further testing to find out?

As for whether this is really a bug or a misconfiguration, I have to figure that out. Before I disabled IPv6, I was getting loads of errors about the IPv6 network being unreachable (every time a DNS lookup came across an NS record with an IPv6 address), which disappeared after disabling IPv6. However, it isn’t clear to me how this would cause the quota/SRVFAIL errors.

I never had that kind of issue before the upgrade (and the setup has been running like this for years now, including any possible misconfiguration), and the first time it appeared was within a few hours of the upgrade.

There are two workstations on the network: one very chatty company laptop, which causes roughly one lookup per minute, and another, which is less chatty and is the one on which I noticed the issues.

Since I reconfigured BIND to IPv4-only, the workstation on which I saw the issues has used the second DNS server (DHCP is set up to give out two DNS server addresses), so for the moment I cannot tell if the issue is actually gone with the config change or if it is just being obscured by the fact that the affected system no longer uses the potentially faulty DNS server.