Server Server 2012R2 DNS Server renvoyant servfail pour certaines requêtes AAAA
(Réécrire la plupart de cette question car beaucoup de mes tests originaux ne sont pas pertinents à la lumière de nouvelles informations)
J'ai des problèmes avec les serveurs DNS Server 2012R2. Le plus gros effet secondaire de ces problèmes est l'échange de courriels qui ne traversent pas. Exchange requêtes pour les enregistrements AAAA avant d'essayer un enregistrement. Lorsqu'il voit Servfail pour l'enregistrement AAAA, cela n'essaie même pas de dossiers, cela abandonne simplement.
Pour certains domaines, lorsqu'il est interrogé contre mes serveurs DNS Active Directory, je reçois servfail au lieu de noerror sans résultat.
J'ai essayé ceci à partir de plusieurs contrôleurs de domaine Server 2012R2 différents qui exécutent DNS. L'un d'eux est un domaine entièrement séparé, sur un réseau différent derrière un pare-feu différent et une connexion Internet.
Deux adresses que je connais parce que ce problème est smtpgw1.gov.on.ca Et mxmta.owm.bell.net
J'utilise Dig sur une machine Linux pour tester ceci (192.168.5.5 est mon contrôleur de domaine):
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
Mais les requêtes contre un contrôleur de domaine public fonctionnent comme prévu:
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
Comme je l'ai dit, j'ai essayé cela sur deux réseaux et domaines différents. L'un est un tout nouveau domaine, qui a définitivement tous les paramètres par défaut pour DNS. L'autre a été migré vers le serveur 2012, de sorte que certains anciens réglages de 2003/2008 peuvent avoir reportés. J'ai les mêmes résultats sur les deux.
Désactiver EDNS avec dmscnd /config /enableednsprobes 0 La corrige. Je vois de nombreux résultats de recherche sur EDNS étant un problème dans le serveur 2003, mais pas beaucoup qui correspond à ce que je vois dans le serveur 2012. L'autre des deux pare-feu n'a aucun problème avec EDNS. La désactivation des EDN devrait simplement être une solution de contournement temporaire, cela empêche l'utilisation de DNSSEC et pourrait causer d'autres problèmes.
J'ai également vu des postes sur des problèmes avec Server 2008R2 et EDNS, mais ces mêmes messages indiquent que les choses sont corrigées dans le serveur 2012, elle devrait donc fonctionner correctement.
J'ai également essayé d'émettre le journal de débogage pour DNS. Je peux voir les paquets que je m'attendais, mais cela ne me donne pas beaucoup d'informations sur la raison pour laquelle cela retourne Servfail. Voici les portions pertinentes du journal de débogage du serveur DNS:
Premier paquet - Query de client à mon serveur DNS
10/16/2015 9:42:29 AM 0974 Packet 000000EFF1BF01A0 UDP RCV 172.16.0.254 AAAA (7) AAAA (7) SMTPGW1 (3) GOV (2) On (2) ) Info de questions UDP à 00000000EFF1BF01A0 Socket = 508 Longueur buf = 0x0fa0 (4000) Msg longueur = 0x002e (46) Message: Drapeaux 0x0120 QR 0 (question) OPCODE 0 (requête) AA 0 [.____] TC 0 [.____] RD 1 [.____] Z 0 CD 0 [.____] AD 1 RCode 0 (noerror) Qcount 1 [.____] (____] NSTOUVE 0 Arcount 1 [.____ .____] Qtype AAAA (28) Qclass 1 Réponse Section: Vide Section de l'autorité: Vide Section supplémentaire: [.____ Nom "(0)" Type opt (41) Classe 4096 [.____] TTL [.____] DLEN 0 Données Taille tampon = 4096 [.____] RCode ext = 0 RCode Full = 0 Drapeaux = 0
Deuxième paquet - Query de mon serveur DNS à son serveur DNS
INFO POSITION UDP à 000000EFF0A22160 [.____] SOCKET = 9812 Longueur BUF = 0x0FA0 (4000) MSG Longueur = 0x0023 (35) Message: Drapeaux 0x0000 QR 0 (Question) OPCODE 0 (requête) AA 0 [.____] TC 0 RD 0 [.____] Z 0 CD 0 AD 0 [.____] RCode 0 (NoError) qcount 1 [.____] ACOUVE 0 Arcount 0 Section de la question: Offset = 0x000c, RR Compte = 0 Nom "(7) SMTPGW1 (3) GOV (2) sur (2) CA (0)" Qtype AAAA (28) Qclass 1 [.___ _.] Section de réponse: Vide Section de l'autorité: Vide Section supplémentaire: Vide [.____]
Troisième paquet - réponse de leur serveur DNS (noerror)
[. ____ ) Info de réponse UDP à 00000000f2188100 Socket = 9812 Longueur buf = 0x0fa0 (4000) MSG Longueur = 0x0023 (35) Message: Drapeaux 0x8400 QR 1 (réponse) Opcode 0 (requête) AA 1 [.____] TC 0 [.____] RD 0 [.____] Z 0 CD 0 AD 0 RCode 0 (noError) Qcount 1 [.____] (____.] Nscount 0 [.____] 0. .____ .____] Qtype AAAA (28) Qclass 1 Réponse Section: Vide Section de l'autorité: Vide Section supplémentaire: [.____]
quatrième paquet - réponse de mon serveur DNS au client (servfail)
10/16/2015 9:42:29 AM 0974 Packet 000000EFF1BF01A0 UDP SND 172.16.0.254 AAAA (7) AAAA (7) SMTPGW1 (3) GOV (2) sur (2) ) Info de réponse UDP à 00000000Eff1bf01a0 Socket = 508 Longueur buf = 0x0fa0 (4000) MSG Longueur = 0x002e (46) Message: Drapeaux 0x8182 QR 1 (réponse) Opcode 0 (requête) AA 0 [.____] TC 0 [.____] RD 1 [.____] Z 0 CD 0 AD 0 RCode 2 (servfail) Qcount 1 [.____] (____] nst 0 Arcount 1 Section de la question: Offset = 0x000c, RR Compte = 0 Nom "(7) SMTPGW1 (3) GOV (2) sur (2) CA (0)" [ .____] Qtype AAAA (28) Qclass 1 Réponse Section: Vide Section de l'autorité: Vide Section supplémentaire: [.____] Décalage = 0x0023, RR Compte = 0 Nom "(0)" Type opt (41) Classe 4000 [.____] TTL DLEN 0 Données Taille tampon = 4000 RCode EXT = 0 RCode Full = 2 Drapeaux = 0
Autres choses de note:
- L'un des réseaux dispose d'un accès Internet IPv6 natif, l'autre ne le fait pas (mais IPv6 Stack est activé sur les serveurs par défaut). Ne semble pas être un problème de réseau IPv6
- Cela n'affecte pas tous les domaines. Par exemple
Dig @192.168.5.5 -t AAAA serverfault.comRenvoie noerror et aucun résultat. Même chose pourgoogle.comRenvoie correctement les adresses IPv6 de Google. - Essayé d'installer Hotfix de KB3014171 , n'a fait aucune différence.
- La mise à jour de kb3004539 est déjà installée.
Modifier le 7 novembre 2015
J'ai configuré une autre machine de serveur Server 2012R2, et a installé le rôle de serveur DNS, et testé avec la commande nslookup -type=aaaa smtpgw1.gov.on.ca localhost. Il n'a pas les mêmes problèmes.
Les deux VMS sont sur le même hôte et le même réseau, afin d'éliminer les problèmes de réseau/pare-feu. Il est maintenant au niveau du patch ou en tant que membre de domaine/contrôleur de domaine qui fait la différence.
Modifier le 8 novembre 2015
Appliqué toutes les mises à jour, fabriquées sans différence. Passé à vérifier s'il y avait des différences de configuration entre mon nouveau serveur de test et les paramètres DNS de mon contrôleur de domaine, et il y a - le contrôleur de domaine avait une configuration des transiteurs.
Maintenant, je suis sûr que j'ai essayé avec des transitaires et sans dans mes tests initiaux, mais je n'ai essayé que d'utiliser Dig à partir d'une machine Linux. Je reçois des résultats légèrement différents avec et sans configuration des transitaires (essayé avec Google, Opendns, 4.2.2.1 et mes serveurs DNS ISP) lorsque j'utilise nslookup sur une machine Windows.
Avec un ensemble de transmissions, je reçois Server failed.
Sans un transitaire (il utilise donc des serveurs DNS racine), je reçois No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.
Mais ce n'est toujours pas la même chose que ce que je reçois pour d'autres domaines qui ne disposent pas d'enregistrements IPv6 - Nslookup sur Windows ne renvoie qu'aucun résultat pour d'autres domaines.
Avec ou sans transmissions, Dig indique toujours SERVFAIL pour ce nom lors de la mise en place de mon serveur Windows DNS.
Là IS une petite différence entre le domaine problématique et autres qui semble pertinente, même lorsque je n'implique pas mon serveur Windows DNS:
Dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca N'a pas de réponses et n'a pas de section de l'autorité.
Dig -t aaaa @8.8.8.8 serverfault.com Ne renvoie aucune réponse, mais a une section d'autorité. Donc, font la plupart des autres domaines que j'essaye, peu importe la résolution que j'utilise.
Alors, pourquoi cette section de l'autorité manque-t-elle et pourquoi Windows DNS Server le traite-t-il comme une défaillance lorsque d'autres serveurs DNS ne le font pas?
J'ai regardé dans le réseau à égoutter plus de plus et j'ai fait une lecture. La REQEST pour l'enregistrement AAAA, lorsqu'il n'est pas existant, retourne une SOA. Etepte le SOA est pour un domaine différent que celui qui soit demandé. Je soupçonne que c'est pourquoi Windows rejetant la réponse. Demandez AAAA pour MX.ATOMWIDE.COM. Response SOA pour lgfl.org.uk. je verrai si nous pouvons faire des progrès avec ces informations. Edit: Juste pour référence future, désactivez temporairement "le cache sécurisé contre la pollution" permettra à la requête de réussir. Pas idéal, mais prouve que le problème est avec un enregistrement DNS DNS DNS. RFC4074 est également une bonne référence - intro et section.
Selon KB83222
Causer
Ce problème se produit en raison des mécanismes d'extension pour les fonctionnalités DNS (EDNS0) prises en charge dans Windows Server DNS.
EDNS0 permet une taille de paquets de protocole de datagramme (UDP). Cependant, certains programmes de pare-feu peuvent ne pas autoriser les paquets UDP supérieurs à 512 octets. Par conséquent, ces paquets DNS peuvent être bloqués par le pare-feu.
Microsoft a la résolution suivante:
Résolution
Pour résoudre ce problème, mettez à jour le programme de pare-feu pour reconnaître et permettre aux paquets UDP supérieurs à 512 octets. Pour plus d'informations sur la façon de faire cela, contactez le fabricant de votre programme de pare-feu.
Microsoft a la suggestion suivante pour contourner le problème:
Workaround
Pour contourner ce problème, désactivez la fonction EDNS0 sur les serveurs DNS basés sur Windows. Pour ce faire, prenez l'action suivante:
À une invite de commande, tapez la commande suivante, puis appuyez sur Entrée:
dnscmd /config /enableednsprobes 0Remarque Type A 0 (zéro) et pas la lettre "O" après "Enferednsprobes" dans cette commande.