Bindungszonenübertragung abgelehnt

10

AKTUALISIEREN:

BIND-Version:

[root@10.224.45.130] $ named -v
BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5

Betriebssystem:

CentOS release 5.6 (Final)

Nach dem Laufen [root@10.224.45.131] $ dig @10.224.45.130 example.com. axfr:

Sklave:

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @10.224.45.130 example.com. axfr
; (1 server found)
;; global options:  printcmd
; Transfer failed.

Meister:

28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: query: example.com IN AXFR -
28-Aug-2011 12:29:01.384 client 10.224.45.131#60553: zone transfer 'example.com/AXFR/IN' denied

Gleiche Fehlermeldung wie zuvor.

UPDATE 2:

[root@10.224.45.130 ~] # iptables -L -n -v
Chain INPUT (policy DROP 30235 packets, 1747K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 171K   23M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun0   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap0   *       0.0.0.0/0            0.0.0.0/0           
57196 6930K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
  688 57376 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
37869 6120K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  392 21216 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:53 
   74  5275 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:53 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    3   192 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:389 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:465 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
   13   832 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:636 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:694 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:843 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:873 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:953 
  119  7584 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:993 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:1194 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    1    48 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 
    1    64 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5901 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            10.224.45.130       tcp dpt:10000 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11211 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11212 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11213 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11511 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11512 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:11513 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2987  372K ACCEPT     all  --  br0    *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      br0     0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 

Chain OUTPUT (policy ACCEPT 246K packets, 37M bytes)
 pkts bytes target     prot opt in     out     source               destination

Ich habe mir wahrscheinlich jede einzelne Seite bezüglich des BIND-Master / Slave-Setups angesehen und kann die Zonenübertragung für mein ganzes Leben nicht zum Laufen bringen.

Hier ist mein Setup: (zur Beschreibung des Problems nach unten scrollen)

Master: 10.224.45.130

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify explicit;
    allow-transfer {
        10.224.45.131;
    };
    also-notify {
        10.224.45.131;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type master;
    file "data/example.com.hosts";
};

Slave: 10.224.45.131

/etc/named.conf

options {
    directory "/var/named";
    version "unknown";
    pid-file "/var/run/named/named.pid";
    recursion yes;
    allow-recursion { localhost; localnets; };
    notify yes;
    allow-transfer { "none"; };
    allow-notify {
        10.224.45.130;
    };
};

zone "." {
    type hint;
    file "named.root";
};

zone "example.com" IN {
    type slave;
    file "slaves/example.com.hosts";
    masters {
        10.224.45.130;
    };
};

Hier ist das Problem. Beim Neustart mit dem Namen auf dem Slave-Server wird festgestellt, dass die Zonendateien noch nicht vorhanden sind, und eine Übertragung vom Master-Server angefordert:

named.log (Slave)

[10.224.45.131] zone example.com/IN: no database exists yet, requesting AXFR of initial version from 10.224.45.130#53

... wonach der Master-Server die Übertragungsanforderung empfängt:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: query: example.com IN AXFR -

... und antwortet mit der Übertragungsanforderung, die abgelehnt wird:

named.log (Master)

[10.224.45.130] client 10.224.45.131#53467: zone transfer 'example.com/AXFR/IN' denied

... auf dem Slave-Server wird es als VERWEIGERT angezeigt:

named.log (Slave)

[10.224.45.131] transfer of 'example.com/IN' from 10.224.45.130#53: failed while receiving responses: REFUSED

Wenn ich mir alle Konfigurationen immer wieder ansehe, kann ich nichts falsches an den Einstellungen finden. Ich habe die IP-Adresse des Master-Servers in der mastersEinstellung der Slave-Zonen-Konfiguration aufgeführt. Ich habe die IP-Adresse des Slave-Servers in der allow-transferEinstellung der Einstellungen für die Master-Optionen aufgeführt.

Alle IP-Adressen sind so, wie sie sein sollten. Es ist nicht so, als würde versucht, die öffentliche IP-Adresse zu verwenden, und sie werden abgelehnt, weil die IP-Adresse nicht übereinstimmt. Ich habe iptables eingerichtet, um TCP / UDP-Verbindungen an Port 53 (und 953) auf beiden Servern zuzulassen. Ich habe die Dateiberechtigungen ordnungsgemäß eingerichtet, sodass das Verzeichnis / Slaves, in dem die Slave-Zonendateien gespeichert sind, vom namedBenutzer beschreibbar ist .

Egal was ich mache, ich bekomme immer den gleichen Fehler. Wenn mir jemand einen Hinweis geben kann, was ich vermisse, würde ich es wirklich schätzen!

— Sarah Ryan
quelle

2

Haben Sie versucht (vorübergehend) einzustellen allow-transfer, anyum festzustellen, ob das Problem dadurch behoben wird? Ihre allow-transferKlausel sieht korrekt aus, aber dies wird jede Möglichkeit von Problemen ausschließen ...

— voretaq7

Nein, ich bekomme immer noch den gleichen Fehler. Ich habe auch nur versucht, die WAN-IP-Adresse des Master-Servers für alle Fälle zur Einstellung "Master" hinzuzufügen, und das hat es auch nicht behoben.

— Sarah Ryan

1

Wurden Sie ausgeführt, rndc reconfignachdem Sie die Konfiguration auf dem Master geändert haben?

— Cakemox

3

Überprüfen Sie zunächst, ob eine Zonenübertragung funktioniert.

Geben Sie auf dem Slave dig @master your-domain aus. axfr

Welche Versionen von BIND und welches Betriebssystem?

— dmourati
quelle

Ich habe meine Frage mit der Ausgabe und den Protokollen dieses Befehls aktualisiert. Es zeigt, dass es wie in der regulären Zonenübertragungsanforderung abgelehnt wird. Ich habe auch Informationen zu Versionen und Betriebssystem hinzugefügt. Entschuldigen Sie, dass Sie diese wichtigen Informationen ausgelassen haben.

— Sarah Ryan

1

OK, die Tatsache, dass der Befehl dig fehlschlägt, zeigt an, dass auf dem Master immer noch ein Problem vorliegt. @ voretaq7 oben vorgeschlagen, die Übertragung auf einen zuzulassen, dem ich zustimme, ist ein vernünftiger Schritt zur Fehlerbehebung. Fügen Sie localhost hinzu, um die Übertragung zuzulassen, und versuchen Sie es mit dem Befehl dig vom Master bei localhost. Richten Sie außerdem einen "tcpdump -i any port 53" auf dem Master ein, um die Quell- / Ziel-IP-Adressen zu überprüfen. Sie sagen "Ich habe iptables eingerichtet, um TCP / UDP-Verbindungen an Port 53 (und 953) auf beiden Servern zuzulassen", aber fügen Sie bitte die Ausgabe von "iptables -L -n -v" auf dem Master hinzu. Das oder iptables auf dem Master herunterfahren und erneut testen.

— Dmourati

Ich habe localhost (sowie alle anderen möglichen Hostnamen und IP-Adressen) zur Einstellung für die Übertragung hinzugefügt und erhalte immer noch den gleichen Fehler. Ich habe die Ausgabe des von Ihnen angeforderten Befehls iptables hinzugefügt und iptables deaktiviert, während ich es erneut versuche. Immer noch kein Glück.

— Sarah Ryan

3

Habe das Problem gefunden. Ich verwende eine chrooted BIND, aber ich habe die conf-Dateien in / etc und nicht in / var / named / chroot / etc. Bearbeitet. Die Änderungen, die ich vornahm, wurden also nicht gesehen. Ich habe die conf-Dateien in das chroot-Verzeichnis kopiert und jetzt funktioniert alles einwandfrei.

— Sarah Ryan
quelle

1

Gute alte Chroot. Ich bin froh, dass du es gefunden hast.

— Dmourati

1

Es mag so aussehen, als ob dies bereits in der allow-transferAnweisung in behandelt wird options, aber versuchen Sie, eine explizite allow-transferAnweisung unter der Zone hinzuzufügen .

Ich sehe nicht wirklich etwas falsch mit Ihrer Konfiguration. Es sieht so aus, als ob es funktionieren sollte . Lauscht bind überhaupt an diesem Port? (Dh, sind irgendwelche Anfragen erfolgreich? Oder scheitern sie alle?)

Nun, ich habe noch zwei Ideen, die es wert sind, ausprobiert zu werden.

Stellen Sie sicher, dass Ihre Uhren auf beiden Servern auf dem neuesten Stand sind (zumindest innerhalb eines angemessenen Bereichs).
Möglicherweise stört SELinux. Deaktivieren Sie es vorübergehend, um es zu testen.

— Bahamat
quelle

Ich habe versucht, die Option "Übertragung zulassen" in die Zonenkonfiguration aufzunehmen, und es wird immer noch der gleiche Fehler angezeigt. Es sind nur Übertragungsanforderungen, die fehlschlagen. Ich kann den Server erfolgreich nach jedem Datensatztyp abfragen und er wird wie erwartet zurückgegeben. Wenn ich jedoch versuche, die Zonenübertragung durchzuführen, werden Fehlermeldungen abgelehnt / abgelehnt.

— Sarah Ryan

Überprüfen Sie meine Antwort auf ein Update.

— Bahamat