☰

BIND9 erhält keine Abfragen über IPv6

tag-icon • tag-icon debian bind ipv6
BIND9 erhält keine Abfragen über IPv6

Ich teste das Upgrade eines Debian-10-Servers auf Debian 11. Der Server führt bind9 als primären autoritativen DNS für eine Anzahl von Domänen aus und funktioniert unter Debian 10 seit zwei Jahren einwandfrei. (BIND v.9.11.5) Auf einem neuen Test-Debian-11-VPS (BIND 9.16.15) mit kopierten standortspezifischen Konfigurationsdateien (derzeit nur für 1 Testdomäne) funktioniert bind9 normal, wenn Abfragen (A, AAAA, MX) über IPv4 gesendet werden, aber es gibt keine Antwort bei Verwendung von IPv6.
Ich habe eine nftables-Firewall, die eingehende Pakete für Port 53 zulässt, und wenn ich die Firewall-Protokollierung für UDP-Dport 53 einschalte, werden alle IPv6- und IPv4-Abfragepakete angezeigt.
Wenn bind9 startet, meldet es im Syslog, dass es auf der IPv6-Adresse lauscht.
ss zeigt den Prozess an, der auf IPv6 lauscht.
Wenn ich rndc querylogdie Logdatei verwende und beobachte, werden die IPv4-Anfragen protokolliert, die IPv6-Anfragen jedoch nicht.
Es ist, als würden die eingehenden UDP-Pakete zwischen der Firewall und bind9 verloren gehen.
Kein anderer Prozess lauscht auf Port 53, denn wenn ich bind9 beende, listet ss nichts auf.
Andere Dienste (z. B. SSH) funktionieren auf IPv6 einwandfrei.
Meins named.conf.optionssieht so aus:

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; };

};

Welche anderen Tests kann ich durchführen, um das Problem zu beheben?

(Es gibt ein zweites Problem mit BIND, das möglicherweise nichts damit zu tun hat: ein „Zugriff verweigert“-Fehler während einer Zonenübertragung auf einen sekundären DNS.)

Antwort1

Durch Neustart behoben!
Möglicherweise hätte ich dies tun sollen, nachdem vor Kurzem ein automatisches Kernel-Upgrade durchgeführt wurde. Das Verhalten ergab jedenfalls keinen Sinn.

UPDATE: Nachdem ich wieder auf ähnliche Probleme gestoßen bin, vermute ich nun, dass dies daran lag, dass auf meinem System zuvor iptables von einer anderen Software installiert worden war. Wenn iptables noch installiert ist, bleiben seine Regeln möglicherweise in der Netzwerkkonfiguration des Kernels bestehen, unsichtbar für nftables. Um das Problem zu beheben, musste ich sowohl das iptables-Paket entfernen als auch alle iptables-Regeln im Kernel löschen; Letzteres wäre beim Neustart passiert.

verwandte Informationen