BIND9 – Fix IPv6 Queries Not Being Received

binddebianipv6

I'm testing the upgrade of a Debian 10 server to Debian 11.
The server runs bind9 as a primary authoritative DNS for a number of domains and on Debian 10 has been working fine for two years. (BIND v.9.11.5)
On a new test Debian 11 VPS (BIND 9.16.15), with site specific configuration files copied across (just for 1 test domain for now), bind9 is working normally when queries (A, AAAA, MX) are sent over IPv4, but there is no response when using IPv6.
I have an nftables firewall which allows incoming packets for port 53, and if I turn on firewall logging for UDP dport 53 the IPv6 and IPv4 query packets are all shown.
When bind9 starts up it reports in syslog that it is listening on the IPv6 address.
ss shows the process listening on IPv6.
If I use rndc querylog and watch the log file, the IPv4 queries are logged, but IPv6 queries are not.
It's as if the incoming UDP packets are being lost between the firewall and bind9.
No other process is listening on port 53, because if I stop bind9 from running, ss lists nothing.
Other services (e.g. SSH) work perfectly on IPv6.
My named.conf.options looks like this:

options {
    directory "/var/cache/bind";

  allow-query-cache { none; };
  allow-query { any; };
  recursion no;

    //========================================================================
    // If BIND logs error messages about the root key being expired,
    // you will need to update your keys.  See https://www.isc.org/bind-keys
    //========================================================================

  dnssec-validation auto;

  listen-on-v6 port 53 { any; };

};

So what other tests can I do to resolve this?

(There is a second problem with BIND which may be unrelated: a "permission denied" error during a zone transfer to a secondary DNS.)

Best Answer

Fixed by rebooting!
It's possible that I should have done this after an automatic kernel upgrade was done recently. The behaviour certainly wasn't making any sense.

UPDATE: Having run into similar problems again, I now suspect this happened because my system had iptables previously installed by some other software. If iptables is still installed, its rules may persist in the kernel's networking configuration, invisibly to nftables. To fix, I had to both remove the iptables package and clear any iptables rules in the kernel; the latter would have happened when I rebooted.