(Ich habe den größten Teil dieser Frage neu geschrieben, da viele meiner ursprünglichen Tests angesichts der neuen Informationen irrelevant sind.)
Ich habe Probleme mit DNS-Servern von Server 2012R2. Die größte Nebenwirkung dieser Probleme ist, dass Exchange-E-Mails nicht durchkommen. Exchange fragt nach AAAA-Einträgen, bevor es A-Einträge versucht. Wenn es SERVFAIL für den AAAA-Eintrag sieht, versucht es nicht einmal A-Einträge, sondern gibt einfach auf.
Bei einigen Domänen erhalte ich bei Abfragen an meine Active Directory-DNS-Server die Meldung „SERVFAIL“ statt „NOERROR“ ohne Ergebnisse.
Ich habe dies von mehreren verschiedenen Server 2012R2-Domänencontrollern aus versucht, auf denen DNS ausgeführt wird. Einer davon ist eine völlig separate Domäne in einem anderen Netzwerk hinter einer anderen Firewall und Internetverbindung.
Zwei Adressen, von denen ich weiß, dass sie dieses Problem verursachen, sind smtpgw1.gov.on.caundmxmta.owm.bell.net
Ich habe digdies auf einer Linux-Maschine getestet (192.168.5.5 ist mein Domänencontroller):
grant@linuxbox:~$ dig @192.168.5.5 smtpgw1.gov.on.ca -t AAAA
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @192.168.5.5 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56328
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;smtpgw1.gov.on.ca. IN AAAA
;; Query time: 90 msec
;; SERVER: 192.168.5.5#53(192.168.5.5)
;; WHEN: Wed Oct 21 14:09:10 EDT 2015
;; MSG SIZE rcvd: 46
Aber Abfragen an einen öffentlichen Domänencontroller funktionieren wie erwartet:
grant@home-ssh:~$ dig @4.2.2.1 smtpgw1.gov.on.ca -t AAAA
; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> @4.2.2.1 smtpgw1.gov.on.ca -t AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 269
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 8192
;; QUESTION SECTION:
;smtpgw1.gov.on.ca. IN AAAA
;; Query time: 136 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Wed Oct 21 14:11:19 EDT 2015
;; MSG SIZE rcvd: 46
Wie gesagt, ich habe dies in zwei verschiedenen Netzwerken und Domänen versucht. Eine ist eine brandneue Domäne, die definitiv alle Standardeinstellungen für DNS hat. Die andere wurde auf Server 2012 migriert, sodass einige alte Einstellungen von 2003/2008 möglicherweise übernommen wurden. Ich erhalte in beiden die gleichen Ergebnisse.
Das Deaktivieren von EDNS dmscnd /config /enableednsprobes 0behebt das Problem. Ich sehe viele Suchergebnisse, in denen es um EDNS als Problem in Server 2003 geht, aber nicht viele, die mit dem übereinstimmen, was ich in Server 2012 sehe. Keine der Firewalls hat ein Problem mit EDNS. Das Deaktivieren von EDNS sollte jedoch nur eine vorübergehende Problemumgehung sein – es verhindert die Verwendung von DNSSEC und kann andere Probleme verursachen.
Ich habe auch einige Posts zu Problemen mit Server 2008R2 und EDNS gesehen, aber in denselben Posts heißt es, dass die Dinge in Server 2012 behoben sind und es daher ordnungsgemäß funktionieren sollte.
Ich habe auch versucht, das Debug-Protokoll für DNS zu aktivieren. Ich kann die erwarteten Pakete sehen, aber es gibt mir keine Aufschluss darüber, warum SERVFAIL zurückgegeben wird. Hier sind die relevanten Teile des Debug-Protokolls des DNS-Servers:
Erstes Paket - Anfrage vom Client an meinen DNS-Server
16.10.2015 9:42:29 Uhr 0974 Paket 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
UDP-Frageinfo bei 000000EFF1BF01A0
Sockel = 508
Remote-Adresse 172.16.0.254, Port 50764
Zeitabfrage=4556080, Warteschlange=0, Ablauf=0
Pufferlänge = 0x0fa0 (4000)
Nachrichtenlänge = 0x002e (46)
Nachricht:
XID 0xa61e
Flaggen 0x0120
QR 0 (FRAGE)
OPCODE 0 (ABFRAGE)
AA 0
TC 0
RD 1
RA 0
Z 0
CD 0
1. Anzeige
RCODE 0 (KEIN FEHLER)
QANZAHL 1
KONTO 0
NSCOUNT 0
Zählimpuls 1
FRAGENTEIL:
Offset = 0x000c, RR-Anzahl = 0
Name "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTYP AAAA (28)
QKLASSE 1
ANTWORTTEIL:
leer
AUTORITÄTSBEREICH:
leer
ZUSÄTZLICHER ABSCHNITT:
Offset = 0x0023, RR-Anzahl = 0
Bezeichnung "(0)"
TYP OPT (41)
KLASSE 4096
TTL 0
DLEN 0
DATEN
Puffergröße = 4096
Rcode Ext = 0
Rcode Voll = 0
Version = 0
Flaggen = 0
Zweites Paket - Anfrage von meinem DNS-Server an deren DNS-Server
16.10.2015 9:42:29 Uhr 0974 Paket 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
UDP-Frageinfo bei 000000EFF0A22160
Sockel = 9812
Remote-Adresse 204.41.8.237, Port 53
Zeitabfrage=0, Warteschlange=0, Ablauf=0
Pufferlänge = 0x0fa0 (4000)
Nachrichtenlänge = 0x0023 (35)
Nachricht:
XID 0x3e6c
Flaggen 0x0000
QR 0 (FRAGE)
OPCODE 0 (ABFRAGE)
AA 0
TC 0
RD 0
RA 0
Z 0
CD 0
Anzeige 0
RCODE 0 (KEIN FEHLER)
QANZAHL 1
KONTO 0
NSCOUNT 0
ARCOUNT 0
FRAGENTEIL:
Offset = 0x000c, RR-Anzahl = 0
Name "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTYP AAAA (28)
QKLASSE 1
ANTWORTTEIL:
leer
AUTORITÄTSBEREICH:
leer
ZUSÄTZLICHER ABSCHNITT:
leer
Drittes Paket – Antwort von ihrem DNS-Server (NOERROR)
16.10.2015 9:42:29 Uhr 0974 Paket 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
UDP-Antwortinformationen bei 000000EFF2188100
Sockel = 9812
Remote-Adresse 204.41.8.237, Port 53
Zeitabfrage=4556080, Warteschlange=0, Ablauf=0
Pufferlänge = 0x0fa0 (4000)
Nachrichtenlänge = 0x0023 (35)
Nachricht:
XID 0x3e6c
Flaggen 0x8400
QR 1 (ANTWORT)
OPCODE 0 (ABFRAGE)
AA 1
TC 0
RD 0
RA 0
Z 0
CD 0
Anzeige 0
RCODE 0 (KEIN FEHLER)
QANZAHL 1
KONTO 0
NSCOUNT 0
ARCOUNT 0
FRAGENTEIL:
Offset = 0x000c, RR-Anzahl = 0
Name "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTYP AAAA (28)
QKLASSE 1
ANTWORTTEIL:
leer
AUTORITÄTSBEREICH:
leer
ZUSÄTZLICHER ABSCHNITT:
leer
Viertes Paket – Antwort von meinem DNS-Server an den Client (SERVFAIL)
16.10.2015 9:42:29 Uhr 0974 Paket 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7)smtpgw1(3)gov(2)on(2)ca(0)
UDP-Antwortinformationen bei 000000EFF1BF01A0
Sockel = 508
Remote-Adresse 172.16.0.254, Port 50764
Zeitabfrage=4556080, Warteschlange=4556080, Ablauf=4556083
Pufferlänge = 0x0fa0 (4000)
Nachrichtenlänge = 0x002e (46)
Nachricht:
XID 0xa61e
Flaggen 0x8182
QR 1 (ANTWORT)
OPCODE 0 (ABFRAGE)
AA 0
TC 0
RD 1
RA 1
Z 0
CD 0
Anzeige 0
RCODE 2 (SERVFAIL)
QANZAHL 1
KONTO 0
NSCOUNT 0
Zählimpuls 1
FRAGENTEIL:
Offset = 0x000c, RR-Anzahl = 0
Name "(7)smtpgw1(3)gov(2)on(2)ca(0)"
QTYP AAAA (28)
QKLASSE 1
ANTWORTTEIL:
leer
AUTORITÄTSBEREICH:
leer
ZUSÄTZLICHER ABSCHNITT:
Offset = 0x0023, RR-Anzahl = 0
Bezeichnung "(0)"
TYP OPT (41)
KLASSE 4000
TTL 0
DLEN 0
DATEN
Puffergröße = 4000
Rcode Ext = 0
Rcode voll = 2
Version = 0
Flaggen = 0
Weitere wichtige Dinge:
- Eines der Netzwerke verfügt über nativen IPv6-Internetzugang, das andere nicht (aber der IPv6-Stack ist auf den Servern mit den Standardeinstellungen aktiviert). Scheint kein IPv6-Netzwerkproblem zu sein
- Es betrifft nicht alle Domänen. Gibt beispielsweise
dig @192.168.5.5 -t AAAA serverfault.comNOERROR und keine Ergebnisse zurück. Dasselbe gilt fürgoogle.comdie korrekte Rückgabe der IPv6-Adressen von Google. - Versuchte die Installation des Hotfixes vonKB3014171, machte keinen Unterschied.
- Das Update vonKB3004539Ist bereits installiert.
Bearbeiten 7. November 2015
Ich habe eine weitere, nicht in eine Domäne eingebundene Server 2012R2-Maschine eingerichtet, die DNS-Serverrolle installiert und mit dem Befehl getestet nslookup -type=aaaa smtpgw1.gov.on.ca localhost. Es treten NICHT dieselben Probleme auf.
Beide VMs befinden sich auf demselben Host und im selben Netzwerk, sodass alle Netzwerk-/Firewallprobleme ausgeschlossen sind. Jetzt kommt es entweder auf den Patch-Level an oder darauf, ob Sie ein Domänenmitglied/Domänencontroller sind, der den Unterschied ausmacht.
Bearbeiten 8. November 2015
Habe alle Updates angewendet, hat keinen Unterschied gemacht. Habe noch einmal überprüft, ob es Konfigurationsunterschiede zwischen meinem neuen Testserver und den DNS-Einstellungen meines Domänencontrollers gibt, und die gibt es – der Domänencontroller hatte Weiterleitungen eingerichtet.
Ich bin mir sicher, dass ich es bei meinen ersten Tests mit und ohne Forwarder versucht habe, aber ich habe es nur digvon einem Linux-Rechner aus versucht. Ich erhalte leicht unterschiedliche Ergebnisse mit und ohne eingerichtete Forwarder (versucht mit Google, OpenDNS, 4.2.2.1 und den DNS-Servern meines ISPs), wenn ich nslookup auf einem Windows-Rechner verwende.
Mit einem Forwarder-Set erhalte ich Server failed.
Ohne Weiterleitung (so dass Root-DNS-Server verwendet werden) erhalte ich No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.
Aber das ist immer noch nicht dasselbe, was ich für andere Domänen bekomme, die keine IPv6-Einträge haben – nslookup unter Windows gibt für andere Domänen einfach keine Ergebnisse zurück.
Mit oder ohne Weiterleitungen wird dieser Name bei der Abfrage meines Windows-DNS-Servers digimmer noch angezeigt .SERVFAIL
Es gibt einen kleinen Unterschied zwischen der Problemdomäne und anderen, der relevant erscheint, auch wenn ich meinen Windows-DNS-Server nicht einbeziehe:
dig -t aaaa @8.8.8.8 smtpgw1.gov.on.cahat keine Antworten und keinen Autoritätsbereich.
dig -t aaaa @8.8.8.8 serverfault.comgibt keine Antworten zurück, hat aber einen Autoritätsbereich. Das gilt auch für die meisten anderen Domänen, die ich ausprobiere, unabhängig davon, welchen Resolver ich verwende.
Warum also fehlt dieser Berechtigungsabschnitt und warum behandelt der Windows-DNS-Server ihn als Fehler, während dies bei anderen DNS-Servern nicht der Fall ist?
Antwort1
Ich habe mir den Netzwerkverlauf noch einmal genauer angesehen und ein bisschen gelesen. Die Anforderung des AAAA-Eintrags gibt, wenn er nicht vorhanden ist, eine SOA zurück. Es stellt sich heraus, dass die SOA für eine andere Domäne ist als die angeforderte. Ich vermute, dass Windows deshalb die Antwort ablehnt. Anforderung AAAA für mx.atomwide.com. Antwort-SOA für lgfl.org.uk. Ich werde sehen, ob wir mit diesen Informationen Fortschritte machen können. BEARBEITEN: Nur zur Information: Wenn Sie „Sicherer Cache gegen Verschmutzung“ vorübergehend deaktivieren, ist die Abfrage erfolgreich. Nicht ideal, beweist aber, dass das Problem bei einem zweifelhaften DNS-Eintrag liegt. RFC4074 ist auch eine gute Referenz – Einleitung und Abschnitt.
Antwort2
EntsprechendKB832223
Ursache
Dieses Problem tritt aufgrund der in Windows Server DNS unterstützten Funktion „Erweiterungsmechanismen für DNS“ (EDNS0) auf.
EDNS0 lässt größere UDP-Paketgrößen (User Datagram Protocol) zu. Einige Firewall-Programme lassen jedoch möglicherweise keine UDP-Pakete zu, die größer als 512 Byte sind. Daher werden diese DNS-Pakete möglicherweise von der Firewall blockiert.
Microsoft bietet die folgende Lösung:
Auflösung
Um dieses Problem zu beheben, aktualisieren Sie das Firewallprogramm, sodass es UDP-Pakete erkennt und zulässt, die größer als 512 Byte sind. Weitere Informationen hierzu erhalten Sie beim Hersteller Ihres Firewallprogramms.
Microsoft hat folgenden Vorschlag, um das Problem zu umgehen:
Problemumgehung
Um dieses Problem zu umgehen, deaktivieren Sie die EDNS0-Funktion auf Windows-basierten DNS-Servern. Gehen Sie hierzu folgendermaßen vor:
Geben Sie in einer Eingabeaufforderung den folgenden Befehl ein und drücken Sie dann die Eingabetaste:
dnscmd /config /enableednsprobes 0Hinweis: Geben Sie in diesem Befehl nach „enableednsprobes“ eine 0 (Null) und nicht den Buchstaben „O“ ein.