Ich habe einen Windows 2008 R2-Domänencontroller, der auch ein DNS-Server ist. Beim Auflösen bestimmter TLDs wird ein SERVFAIL zurückgegeben:
$ dig bogus.
; <<>> DiG 9.8.1 <<>> bogus.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;bogus. IN A
Ich erhalte das gleiche Ergebnis für eine echte TLD wie com.beim Abfragen des DC wie oben gezeigt. Vergleichen Sie mit einem BIND-Server, der wie erwartet funktioniert:
$ dig bogus. @128.59.59.70
; <<>> DiG 9.8.1 <<>> bogus. @128.59.59.70
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30141
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;bogus. IN A
;; AUTHORITY SECTION:
. 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2012012501 1800 900 604800 86400
;; Query time: 18 msec
;; SERVER: 128.59.59.70#53(128.59.59.70)
;; WHEN: Wed Jan 25 14:09:14 2012
;; MSG SIZE rcvd: 98
Wenn ich meinen Windows-DNS-Server mit dig . anyabfrage, erhalte ich ebenfalls eine SERVFAIL, aber die BIND-Server geben die Stammzone wie erwartet zurück.
Dies klingt ähnlich wie das in http://support.microsoft.com/kb/968372 beschriebene Problem, außer dass ich zwei Weiterleitungen (128.59.59.70 von oben sowie 128.59.62.10) verwende und auf Root-Hinweise zurückgreife, um die Voraussetzungen dafür zu erfüllen Das Problem aufzudecken ist nicht dasselbe. Trotzdem habe ich auch den MaxCacheTTLRegistrierungsfix wie beschrieben angewendet und DNS und den gesamten Server neu gestartet, aber das Problem besteht weiterhin. Das Problem tritt auf allen Domänencontrollern in dieser Domäne auf und tritt seit einem halben Jahr auf, obwohl die Server automatische Windows-Updates erhalten.
BEARBEITEN
Hier ist ein Debug-Protokoll. Der Client ist 160.39.114.110, das ist meine Workstation.
1/25/2012 2:16:01 PM 0E08 PACKET 000000001EA6BFD0 UDP Rcv 160.39.114.110 2e94 Q [0001 D NOERROR] A (5)bogus(0)
UDP question info at 000000001EA6BFD0
Socket = 508
Remote addr 160.39.114.110, port 49710
Time Query=1077016, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0017 (23)
Message:
XID 0x2e94
Flags 0x0100
QR 0 (QUESTION)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
AD 0
RCODE 0 (NOERROR)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)bogus(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
1/25/2012 2:16:01 PM 0E08 PACKET 000000001EA6BFD0 UDP Snd 160.39.114.110 2e94 R Q [8281 DR SERVFAIL] A (5)bogus(0)
UDP response info at 000000001EA6BFD0
Socket = 508
Remote addr 160.39.114.110, port 49710
Time Query=1077016, Queued=0, Expire=0
Buf length = 0x0fa0 (4000)
Msg length = 0x0017 (23)
Message:
XID 0x2e94
Flags 0x8182
QR 1 (RESPONSE)
OPCODE 0 (QUERY)
AA 0
TC 0
RD 1
RA 1
Z 0
CD 0
AD 0
RCODE 2 (SERVFAIL)
QCOUNT 1
ACOUNT 0
NSCOUNT 0
ARCOUNT 0
QUESTION SECTION:
Offset = 0x000c, RR count = 0
Name "(5)bogus(0)"
QTYPE A (1)
QCLASS 1
ANSWER SECTION:
empty
AUTHORITY SECTION:
empty
ADDITIONAL SECTION:
empty
Jede Option im Debug-Protokollfeld wurde aktiviert, außer "Nach IP filtern". Wenn ich dagegen beispielsweise accounts.google.com abfrage, kann ich sehen, dass der DNS-Server an seine Weiterleitung ausgeht (z. B. 128.59.59.70). In diesem Fall wurden keine Pakete von meinem DNS-Server gesendet, obwohl sie bogus.sich nicht im Cache befanden (das Debug-Protokoll wurde bereits ausgeführt und dies ist das erste Mal, dass ich diesen Server bogus.oder eine TLD abgefragt habe). Es wurde gerade SERVFAIL zurückgegeben, ohne einen anderen DNS-Server zu konsultieren, wie im oben verlinkten Microsoft KB-Artikel.
quelle
Antworten:
Wir hatten ein ähnliches Problem auf Microsoft DNS-Servern ohne konfigurierte Weiterleitungen. Dieser Hotfix scheint verwandt zu sein: http://support.microsoft.com/kb/2508835 . Ich würde nicht sagen, dass die Verwendung von Spediteuren die Anwendbarkeit negieren würde.
quelle