Der CentOS bind9 Server erhält ständig Fehlermeldungen von Master-ADDNS

In den letzten Tagen habe ich versucht, meinen Bind9-Server als sekundäre Zone mit dem DNS meiner AD zu verbinden, ohne Erfolg. Dies geschieht alles auf VMware, wobei pfSense die beiden miteinander verbindet (ja, Port 53, TCP / UDP ist auch dort offen).

Das Problem scheint zu sein, dass beim Versuch, eine Zone vom Master übertragen zu bekommen, die Pakete verworfen werden, obwohl es keine Firewalls gibt, die sie ablehnen sollten.

Ich kann alle ohne Probleme pingen, und ich kann die Zone auch über nslookup von einem normalen Windows-Client übertragen.

Betrachten wir Wireshark und tcpdump -i an jedem Port 53, wenn Sie den Bind-Server mit dem ADDNS-Server verbinden, erhalten Sie Folgendes:

https://i.imgur.com/soToiCM.png

Ja, es sieht so aus, als würde eine Firewall die Abfragen blockieren, aber glauben Sie mir, das kann nicht sein. Ich habe versucht, alle Firewalls zu deaktivieren, und fügte außerdem Dienste und Portnummern hinzu.

Sie können auch sehen, dass der Windows-Server einen Timeout-Fehler ausgegeben hat, obwohl er begonnen hat, "Der Server mit dieser IP-Adresse ist nicht autorisierend für die Zone" Dieser Fehler tritt auf, unabhängig davon, wo ich ihn anwende. NS-Datensatz, Verbindung zum Server herstellen usw.)

Und wenn ich mir den genannten Status anschaue, gibt es mir eine Menge Probleme, hauptsächlich in Bezug auf nicht autorisierende Antworten:

managed-keys-zone: loaded serial 97 zone 0.in-addr.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone localhost.localdomain/IN: loaded serial 0 all zones loaded running zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: non-authoritative answer from master 192.168.64.64#53 (source 0.0.0.0#0) 

-

managed-keys-zone: loaded serial 97 zone 0.in-addr.arpa/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone localhost.localdomain/IN: loaded serial 0 all zones loaded running zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: CNAME at top of zone in master 192.168.64.64#53 (source 0.0.0.0#0) error (host unreachable) resolving 'dlv.isc.org/DNSKEY/IN': 192.5.5.241#53 error (host unreachable) resolving './DNSKEY/IN': 192.5.5.241#53 error (host unreachable) resolving 'dlv.isc.org/DNSKEY/IN': 198.97.190.53#53 error (host unreachable) resolving './NS/IN': 192.5.5.241#53 

- Dies ist nach dem Festlegen eines CNAME-Datensatzes in ADDNS für den Server. Ich habe zwar kein DNSSEC eingerichtet.

-

managed-keys-zone: journal file is out of date: removing journal file managed-keys-zone: loaded serial 101 zone 0.in-addr.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone localhost/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone localhost.localdomain/IN: loaded serial 0 all zones loaded running zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: unexpected rcode (NXDOMAIN) from master 192.168.64.64#53 (source 0.0.0.0#0) received control channel command 'stop' shutting down: flushing changes stopping command channel on 127.0.0.1#953 stopping command channel on ::1#953 no longer listening on 127.0.0.1#53 no longer listening on 192.168.64.128#53 exiting managed-keys-zone: loaded serial 101 zone 0.in-addr.arpa/IN: loaded serial 0 zone localhost.localdomain/IN: loaded serial 0 zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0 zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0 zone localhost/IN: loaded serial 0 all zones loaded running zone centns.bliss.lan/IN: refresh: NODATA response from master 192.168.64.64#53 (source 0.0.0.0#0) zone centns.bliss.lan/IN: refresh: NODATA response from master 192.168.64.64#53 (source 0.0.0.0#0) 

- Also die Probleme scheinen einfach zu sein, es wird als autoritärer Server angesehen, obwohl ich es als Sklave bezeichne?

Hier ist meine named.conf

[root@centns ~]# cat /etc/named.conf // // named.conf // // Provided by Red Hat bind package to configure the ISC BIND named(8) DNS // server as a caching only nameserver (as a localhost DNS resolver only). // // See /usr/share/doc/bind*/sample/ for example named configuration files. // // See the BIND Administrator's Reference Manual (ARM) for details about the // configuration located in /usr/share/doc/bind-/Bv9ARM.html  options { listen-on port 53 { 192.168.64.128; 127.0.0.1; }; filter-aaaa-on-v4 yes; directory "/var/named/"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; // auth-nxdomain no; // allow-query { 192.168.64.0/24; }; // allow-transfer { 127.0.0.1; 192.168.64.64; }; // allow-notify { 127.0.0.1; 192.168.64.64; }; // allow-recursion { 127.0.0.1; 192.168.64.64; }; /* - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion. - If you are building a RECURSIVE (caching) DNS server, you need to enable recursion. - If your recursive DNS server has a public IP address, you MUST enable access control to limit queries to your legitimate users. Failing to do so will cause your server to become part of large scale DNS amplification attacks. Implementing BCP38 within your network would greatly reduce such attack surface */ recursion no;   dnssec-enable no; dnssec-validation auto; dnssec-lookaside auto; /* Path to ISC DLV key */ bindkeys-file "/etc/named.iscdlv.key";  managed-keys-directory "/var/named/dynamic";  pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; };  logging { channel default_debug { file "data/named.run"; severity dynamic; };   }; zone "centns.bliss.lan" IN { type slave; file "centNS.bliss.lan"; masters { 192.168.64.64; }; allow-query { 192.168.64.0/24; }; allow-transfer { 192.168.64.0/24; }; // allow-recursion { 192.168.64.0/24; }; }; /* zone "64.168.192.in-addr.arpa" IN { type slave; file "rev.centNS.bliss.lan"; masters { 192.168.64.64; }; notify yes; }; */ zone "." IN { type hint; file "named.ca"; };  include "/etc/named.rfc1912.zones"; include "/etc/named.root.key"; 

Wie Sie aus allen kommentierten Zeilen sehen können, habe ich jetzt ein paar Dinge ausprobiert.

Ich habe versucht:

* Deaktivieren der Firewall unter Windows und CentOS

* Einstellen eines A- und CNAME-Datensatzes im AD-DNS für meinen CentNS-Server

* Sicherstellen, dass Windows BIND aktiviert hat

Wenn Sie weitere Informationen benötigen, fragen Sie bitte. Ich möchte, dass dies funktioniert.