Serveur DNS 2012R2 renvoyant SERVFAIL pour certaines requêtes AAAA

17

(Réécrire la plupart de cette question car beaucoup de mes tests originaux ne sont pas pertinents à la lumière de nouvelles informations)

Je rencontre des problèmes avec les serveurs DNS Server 2012R2. Le plus grand effet secondaire de ces problèmes est que les e-mails Exchange ne passent pas. Échangez les requêtes pour les enregistrements AAAA avant d'essayer les enregistrements A. Lorsqu'il voit SERVFAIL pour l'enregistrement AAAA, il n'essaie même pas les enregistrements A, il abandonne simplement.

Pour certains domaines, lorsque j'interroge mes serveurs DNS Active Directory, j'obtiens SERVFAIL au lieu de NOERROR sans résultat.

J'ai essayé cela à 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 et une connexion Internet différents.

Deux adresses que je connais sont à l'origine de ce problème smtpgw1.gov.on.caetmxmta.owm.bell.net

J'utilise digsur une machine Linux pour tester cela (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 sur un contrôleur du 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 Server 2012, donc certains anciens paramètres de 2003/2008 peuvent avoir été transférés. J'obtiens les mêmes résultats sur les deux.

La désactivation d'EDNS avec le dmscnd /config /enableednsprobes 0corrige. Je vois de nombreux résultats de recherche sur EDNS étant un problème dans Server 2003, mais pas beaucoup qui correspond à ce que je vois dans Server 2012. Aucun pare-feu n'a de problème avec EDNS. La désactivation d'EDNS ne devrait être qu'une solution de contournement temporaire - elle empêche l'utilisation de DNSSEC et peut entraîner d'autres problèmes.

J'ai également vu quelques messages sur des problèmes avec Server 2008R2 et EDNS, mais ces mêmes messages disent que les choses sont corrigées dans Server 2012, donc cela devrait fonctionner correctement.

J'ai également essayé d'activer le journal de débogage pour DNS. Je peux voir les paquets que j'attendais, mais cela ne me donne pas beaucoup d'informations sur la raison pour laquelle il retourne SERVFAIL. Voici les parties pertinentes du journal de débogage du serveur DNS:

Premier paquet - requête du client vers mon serveur DNS

16/10/2015 09:42:29 0974 PACKET 000000EFF1BF01A0 UDP Rcv 172.16.0.254 a61e Q [2001 D NOERROR] AAAA (7) smtpgw1 (3) gov (2) on (2) ca (0)
Informations sur la question UDP à 000000EFF1BF01A0
  Prise = 508
  Adresse distante 172.16.0.254, port 50764
  Time Query = 4556080, Queued = 0, Expire = 0
  Longueur Buf = 0x0fa0 (4000)
  Longueur msg = 0x002e (46)
  Message:
    XID 0xa61e
    Drapeaux 0x0120
      QR 0 (QUESTION)
      OPCODE 0 (QUERY)
      AA 0
      TC 0
      RD 1
      RA 0
      Z 0
      CD 0
      AD 1
      RCODE 0 (NOERROR)
    QCOUNT 1
    COMPTE 0
    NSCOUNT 0
    ARCOUNT 1
    SECTION QUESTION:
    Décalage = 0x000c, compte RR = 0
    Nom "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION DE L'AUTORITÉ:
      vide
    SECTION SUPPLÉMENTAIRE:
    Décalage = 0x0023, compte RR = 0
    Nom "(0)"
      TYPE OPT (41)
      CLASSE 4096
      TTL 0
      DLEN 0
      LES DONNÉES   
        Taille du tampon = 4096
        Rcode Ext = 0
        Rcode complet = 0
        Version = 0
        Drapeaux = 0

Deuxième paquet - requête de mon serveur DNS vers leur serveur DNS

16/10/2015 09:42:29 0974 PACKET 000000EFF0A22160 UDP Snd 204.41.8.237 3e6c Q [0000 NOERROR] AAAA (7) smtpgw1 (3) gov (2) on (2) ca (0)
Informations sur la question UDP au 000000EFF0A22160
  Prise = 9812
  Adresse distante 204.41.8.237, port 53
  Time Query = 0, Queued = 0, Expire = 0
  Longueur Buf = 0x0fa0 (4000)
  Longueur msg = 0x0023 (35)
  Message:
    XID 0x3e6c
    Drapeaux 0x0000
      QR 0 (QUESTION)
      OPCODE 0 (QUERY)
      AA 0
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      RCODE 0 (NOERROR)
    QCOUNT 1
    COMPTE 0
    NSCOUNT 0
    ARCOUNT 0
    SECTION QUESTION:
    Décalage = 0x000c, compte RR = 0
    Nom "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION DE L'AUTORITÉ:
      vide
    SECTION SUPPLÉMENTAIRE:
      vide

Troisième paquet - réponse de leur serveur DNS (NOERROR)

16/10/2015 09:42:29 0974 PACKET 000000EFF2188100 UDP Rcv 204.41.8.237 3e6c RQ [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) on (2) ca (0)
Informations de réponse UDP au 000000EFF2188100
  Prise = 9812
  Adresse distante 204.41.8.237, port 53
  Time Query = 4556080, Queued = 0, Expire = 0
  Longueur Buf = 0x0fa0 (4000)
  Longueur msg = 0x0023 (35)
  Message:
    XID 0x3e6c
    Drapeaux 0x8400
      QR 1 (RÉPONSE)
      OPCODE 0 (QUERY)
      AA 1
      TC 0
      RD 0
      RA 0
      Z 0
      CD 0
      AD 0
      RCODE 0 (NOERROR)
    QCOUNT 1
    COMPTE 0
    NSCOUNT 0
    ARCOUNT 0
    SECTION QUESTION:
    Décalage = 0x000c, compte RR = 0
    Nom "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION DE L'AUTORITÉ:
      vide
    SECTION SUPPLÉMENTAIRE:
      vide

Quatrième paquet - réponse de mon serveur DNS au client (SERVFAIL)

16/10/2015 09:42:29 0974 PACKET 000000EFF1BF01A0 UDP Snd 172.16.0.254 a61e RQ [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) on (2) ca (0)
Informations de réponse UDP à 000000EFF1BF01A0
  Prise = 508
  Adresse distante 172.16.0.254, port 50764
  Time Query = 4556080, Queued = 4556080, Expire = 4556083
  Longueur Buf = 0x0fa0 (4000)
  Longueur msg = 0x002e (46)
  Message:
    XID 0xa61e
    Drapeaux 0x8182
      QR 1 (RÉPONSE)
      OPCODE 0 (QUERY)
      AA 0
      TC 0
      RD 1
      RA 1
      Z 0
      CD 0
      AD 0
      RCODE 2 (SERVFAIL)
    QCOUNT 1
    COMPTE 0
    NSCOUNT 0
    ARCOUNT 1
    SECTION QUESTION:
    Décalage = 0x000c, compte RR = 0
    Nom "(7) smtpgw1 (3) gov (2) on (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION DE L'AUTORITÉ:
      vide
    SECTION SUPPLÉMENTAIRE:
    Décalage = 0x0023, compte RR = 0
    Nom "(0)"
      TYPE OPT (41)
      CLASSE 4000
      TTL 0
      DLEN 0
      LES DONNÉES   
        Taille du tampon = 4000
        Rcode Ext = 0
        Rcode complet = 2
        Version = 0
        Drapeaux = 0

Autres choses à noter:

  • L'un des réseaux dispose d'un accès Internet IPv6 natif, l'autre non (mais la pile IPv6 est activée sur les serveurs avec les paramètres 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 pour google.comles adresses IPv6 de google retournées correctement.
  • J'ai essayé d'installer le correctif de KB3014171 , cela 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 Server 2012R2 n'appartenant pas à un domaine et j'ai 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 machines virtuelles sont sur le même hôte et le même réseau, ce qui élimine tout problème de réseau / pare-feu. C'est maintenant au niveau du correctif ou d'être un membre de domaine / contrôleur de domaine qui fait la différence.

Modifier le 8 novembre 2015

Appliqué toutes les mises à jour, n'a fait aucune différence. Je suis allé jusqu'à 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 configuré des redirecteurs.

Maintenant, je suis sûr que j'ai essayé avec des redirecteurs et sans dans mes tests initiaux, mais je ne l'ai essayé qu'en utilisant digune machine Linux. J'obtiens des résultats légèrement différents avec et sans configuration de redirecteurs (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 transitaires, je reçois Server failed.

Sans transitaire (il utilise donc des serveurs DNS racine), j'obtiens No IPv6 address (AAAA) records available for smtpgw1.gov.on.ca.

Mais ce n'est toujours pas la même chose que ce que j'obtiens pour d'autres domaines qui n'ont pas d'enregistrements IPv6 - nslookup sur Windows ne renvoie simplement aucun résultat pour les autres domaines.

Avec ou sans redirecteurs, digs'affiche toujours SERVFAILpour ce nom lors de la requête sur mon serveur DNS Windows.

Il y a une petite différence entre le domaine problématique et d'autres qui semblent pertinents, même lorsque je n'implique pas mon serveur DNS Windows:

dig -t aaaa @8.8.8.8 smtpgw1.gov.on.ca n'a pas de réponse et n'a pas de section d'autorité.

dig -t aaaa @8.8.8.8 serverfault.comne renvoie aucune réponse, mais a une section d'autorité. Il en va de même pour la plupart des autres domaines que j'essaie, quel que soit le résolveur que j'utilise.

Alors, pourquoi cette section d'autorité est-elle manquante et pourquoi le serveur DNS Windows la traite-t-il comme un échec alors que les autres serveurs DNS ne le font pas?

domain-name-system active-directory mx-record Subvention
la source
Effectuez-vous ces tests à partir du serveur Exchange? Sinon, je suggère de le faire pour que vous puissiez le voir du point de vue d'Exchange. Vous pouvez également essayer d'exécuter SMTPDiag à partir du serveur Exchange. Je suggère de l'exécuter tout en effectuant une capture réseau sur le serveur Exchange afin que vous puissiez afficher les détails de l'activité réseau / DNS. SMTPDiag est un ancien outil, mais c'est un outil de ligne de commande qui ne nécessite aucune installation, donc je pense qu'il devrait fonctionner sur toutes les versions d'Exchange. - microsoft.com/en-us/download/details.aspx?id=11393
joeqwerty
Certains périphériques réseau ne reconnaissent pas et rejetteront les paquets EDNS. Votre équipe réseau a-t-elle récemment introduit un nouvel appareil / paramètre? Pour éliminer cette possibilité, essayez de résoudre l'enregistrement AAAA de google.com, il doit renvoyer une adresse IPv6.
strongline
Les paquets @strongline EDNS se passent bien. Enregistrement AAAA pour Google Works, tout comme quelques autres sites que je connais ont IPv6 en cours d'exécution. La seule chance faite récemment était de se débarrasser de notre dernier serveur DC / DNS Server 2008R2 et de le remplacer par 2012R2.
Grant
IPv6 est-il désactivé de quelque manière que ce soit dans votre environnement?
Jim B
@JimB ni vraiment activé ni désactivé ... La pile IPv6 s'exécute sur les serveurs, car elle est activée par défaut, quelle que soit la configuration par défaut. La passerelle et la connexion Internet n'ont aucun IPv6.
Accordez

Réponses:

3

J'ai regardé un peu plus dans le réseau et j'ai fait quelques lectures. La demande d'enregistrement AAAA, lorsqu'elle n'existe pas, renvoie un SOA. Il s'avère que le SOA est pour un domaine différent de celui demandé. Je soupçonne que c'est pourquoi Windows rejette la réponse. Demandez AAAA pour mx.atomwide.com. Réponse SOA pour lgfl.org.uk. Je vais voir si nous pouvons faire des progrès avec ces informations. EDIT: juste pour référence future, la désactivation temporaire de "Secure cache against pollution" permettra à la requête de réussir. Pas idéal, mais prouve que le problème est lié à un enregistrement DNS douteux. RFC4074 est également une bonne référence - introduction et section.

Shruti Chawla
la source
Je vais essayer de tester cela aujourd'hui dans mon environnement, mais je pense que vous êtes peut-être sur quelque chose!
Grant
J'ai également édité votre lien - les signatures et les liens hors sujet ne sont pas autorisés ici, et je ne veux pas que votre excellente réponse soit supprimée.
Grant
0

Selon KB832223

Cause

Ce problème se produit en raison de la fonctionnalité des mécanismes d'extension pour DNS (EDNS0) qui est prise en charge dans DNS Windows Server.

EDNS0 autorise des tailles de paquets UDP (User Datagram Protocol) plus importantes. 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 autoriser les paquets UDP supérieurs à 512 octets. Pour plus d'informations sur la façon de procéder, contactez le fabricant de votre programme de pare-feu.

Microsoft a la suggestion suivante pour contourner le problème:

solution de contournement

Pour contourner ce problème, désactivez la fonctionnalité EDNS0 sur les serveurs DNS Windows. Pour ce faire, procédez comme suit:

À une invite de commandes, tapez la commande suivante, puis appuyez sur Entrée:

dnscmd /config /enableednsprobes 0

Remarque Tapez un 0 (zéro) et non la lettre "O" après "enableednsprobes" dans cette commande.

Tim Penner
la source
J'ai vu cet article - les pare-feu que j'ai testés avec les deux passent de gros paquets DNS sans problème, comme en témoigne le fonctionnement parfait sur Linux. La désactivation des edns empêche l'utilisation de DNSSEC, donc bien qu'elle corrige le problème, ce n'est pas une bonne solution.
Grant
désolé, je ne savais pas que les conseils de Microsoft s'appliqueraient également à Linux. Par curiosité, avez-vous un système d'exploitation Microsoft fonctionnant via le pare-feu?
Tim Penner