Wir verwenden BIND 9.7.3 in der stabilen Version von Debian (wöchentlich aktualisiert) und sehen ein sehr seltsames Verhalten für eine bestimmte Domain. Wir beherbergen ein paar hundert, aber dieser gehört uns.
Grundsätzlich versucht der sekundäre DNS-Server, die Domäne vom Master zu übertragen. Laut den Protokollen gelingt es ihm jedes Mal, die Domain zu übertragen, aber die Seriennummer wird immer falsch angegeben! Infolgedessen wird die Übertragung bei jeder Gelegenheit wiederholt. Ich bin mir nicht einmal sicher, woher die Seriennummer stammt, da der Primärserver mit der richtigen Seriennummer zurückmeldet.
Hier sind die Protokolle, die wir vom sekundären Server erhalten (die IP 192.168.0.130 ist der primäre Server, 192.168.0.4 ist der sekundäre. Und natürlich sind sie nicht real.):
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: connected using 192.168.0.4#60959
Aug 23 03:01:08 ns2 named[4242]: transfer of 'mydomain.ca/IN/external' from 192.168.0.130#53: Transfer completed: 0 messages, 1 records, 0 bytes, 0.001 secs (0 bytes/sec)
Dies scheint ziemlich normal zu sein, obwohl beide Hosts mit IPv6-Adressen eingerichtet sind und technisch gesehen diese verwenden sollten, aber das ist ein Problem für einen anderen Tag (glaube ich).
Fragen wir also den Primärserver vom Sekundärserver ab und sehen, was darin steht:
$ host -4 -t any mydomain.ca 192.168.0.130
Using domain server:
Name: 192.168.0.130
Address: 192.168.0.130#53
Aliases:
mydomain.ca has IPv6 address fc00:::31
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011082201 900 3600 604800 86400
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca has address 192.168.0.205
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00:::23 ip6:fc00:::12 ip6:fc00:::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
Und dann machen wir dasselbe für den sekundären Nameserver:
$ host -4 -t any mydomain.ca 192.168.0.4
Using domain server:
Name: 192.168.0.4
Address: 192.168.0.4#53
Aliases:
mydomain.ca has SOA record ns1.mydomain.bc.ca. hostmaster.mydomain.ca. 2011011013 600 600 600 600
mydomain.ca descriptive text "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
mydomain.ca has address 192.168.0.205
mydomain.ca mail is handled by 20 pop.mydomain.ca.
mydomain.ca name server ns1.mydomain.bc.ca.
mydomain.ca name server ns2.mydomain.bc.ca.
mydomain.ca has IPv6 address fc00::31
Sie können hier sehen, dass die Seriennummer 2011011013 auf der Sekundärseite, 2011082201 auf der Primärseite lautet. Ich habe das Datum plus eine zweistellige Nummer verwendet, daher verwendet die Sekundärseite irgendwie eine Seriennummer von Januar. Ich habe versucht, unsere Konfiguration sowohl auf dem primären als auch auf dem sekundären Server nach dieser Seriennummer zu durchsuchen, aber sie ist nirgends zu finden.
Apropos Konfiguration: Hier ist die Konfiguration für diese Domain in /etc/bind/named.conf:
zone "mydomain.ca" { type slave; file "secondaries/mydomain.ca"; masters { 192.168.0.130; }; };
und der Zeitstempel auf secondaries / mydomain.ca ist der Zeitpunkt des letzten Updates. Das Löschen dieser Datei führt weiterhin zu einer Seriennummer von 2011011013. Der Inhalt dieser Datei ist sehr lang, aber hier sind die Header auf dem sekundären Server:
$ORIGIN .
$TTL 3600 ; 1 hour
mydomain.ca IN SOA ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
2011011013 ; serial
600 ; refresh (10 minutes)
600 ; retry (10 minutes)
600 ; expire (10 minutes)
600 ; minimum (10 minutes)
)
NS ns1.mydomain.bc.ca.
NS ns2.mydomain.bc.ca.
A 192.168.0.205
MX 20 pop.mydomain.ca.
TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
AAAA fc00::31
$ORIGIN mydomain.ca.
und die Header aus der entsprechenden Datei auf der Primärdatei:
$TTL 1d
@ IN SOA ns1.mydomain.bc.ca. hostmaster.mydomain.ca. (
2011082302 ; serial
15m ; refresh after 15 minutes
1h ; retry after 1 hour
1w ; expire after 1 week
1d ) ; negative caching TTL of 1 day.
IN NS ns1.mydomain.bc.ca.
IN NS ns2.mydomain.bc.ca.
IN MX 20 pop.mydomain.ca.
@ IN A 192.168.0.205
;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; SPF TXT records
;;;;;;;;;;;;;;;;;;;;;;;;;;;
mydomain.ca. TXT "v=spf1 mx ip4:192.168.0.4 ip4:192.168.0.193 ip6:fc00::23 ip6:fc00::12 ip6:fc00::33 a:smtp.mydomain.ca a:webmail.mydomain.ca a:smtp2.mydomain.ca a:ns2.mydomain.ca ~all"
; this next bit is for the Sender Policy Framework, if it ever really matters.
pop TXT "v=spf1 a -all"
pop3 TXT "v=spf1 a -all"
smtp TXT "v=spf1 a -all"
webmail TXT "v=spf1 a -all"
horde TXT "v=spf1 a -all"
quelle
AXFRstatt nur eine IXFRAntworten:
Überprüfen Sie Ihre Berechtigungen im Verzeichnis des sekundären Servers für die Zonen. Kann der genannte Prozess in diesen Ordner schreiben? Versuchen Sie, diese sekundäre Zone zu löschen, und lassen Sie die Übertragung sie neu erstellen
quelle
Beachten Sie, dass Ihr BIND-Protokoll auf der Primärseite anzeigt
Das ist keine Erfolgsbestätigung. Gibt es vorher eine Meldung, die auf einen Fehler hinweist?
quelle