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


(Réécrire l'essentiel de cette question car bon nombre de mes tests initiaux ne sont pas pertinents à la lumière de nouvelles informations.)

J'ai des problèmes avec les serveurs DNS Server 2012R2. Le principal effet secondaire de ces problèmes est que les courriels Exchange ne passent pas. Échangez des 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 d'enregistrer 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é ceci à partir de différents contrôleurs de domaine Server 2012R2 exécutant 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 sais cause ce problème sont smtpgw1.gov.on.ca et mxmta.owm.bell.net

J'ai utilisé dig sur une machine Linux pour le tester (mon contrôleur de domaine est 192.168.5.5):

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 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é ceci 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; par conséquent, certains anciens paramètres de 2003/2008 ont peut-être été conservés. Je reçois les mêmes résultats sur les deux.

Désactiver EDNS avec dmscnd /config /enableednsprobes 0 le corrige. De nombreux résultats de recherche montrent que EDNS est un problème dans Server 2003, mais pas autant que ce que je vois dans Server 2012. Aucun pare-feu n'a de problème avec EDNS. Désactiver EDNS ne devrait cependant constituer qu’une solution temporaire: il empêche l’utilisation de DNSSEC et peut entraîner d’autres problèmes.

J'ai également vu des publications à propos de problèmes avec Server 2008R2 et EDNS, mais ces mêmes publications indiquent que les problèmes sont résolus dans Server 2012, de sorte que cela devrait fonctionner correctement.

J'ai également essayé d'activer le journal de débogage pour DNS. Je peux voir les paquets auxquels je m'attendais, mais cela ne me dit pas vraiment pourquoi il renvoie SERVFAIL. Voici les parties pertinentes du journal de débogage du serveur DNS:

Premier paquet - interrogation du client sur 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) sur (2) ca (0)
Informations sur la question UDP au 000000EFF1BF01A0
  Socket = 508
  Adresse à distance 172.16.0.254, port 50764
  Requête temporelle = 4556080, en file d'attente = 0, expire = 0
  Longueur en bits = 0x0fa0 (4000)
  Msg longueur = 0x002e (46)
  Message:
    XID 0xa61e
    Drapeaux 0x0120
      QR 0 (QUESTION)
      OPCODE 0 (CHERCHER)
      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, nombre de RR = 0
    Nom "(7) smtpgw1 (3) gov (2) sur (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION AUTORITÉ:
      vide
    SECTION ADDITIONNELLE:
    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 Full = 0
        Version = 0
        Drapeaux = 0

Deuxième paquet - demande de mon serveur DNS à 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) sur (2) ca (0)
Informations sur la question UDP au 000000EFF0A22160
  Socket = 9812
  Adresse distante 204.41.8.237, port 53
  Requête temporelle = 0, en file d'attente = 0, expire = 0
  Longueur en bits = 0x0fa0 (4000)
  Msg longueur = 0x0023 (35)
  Message:
    XID 0x3e6c
    Drapeaux 0x0000
      QR 0 (QUESTION)
      OPCODE 0 (CHERCHER)
      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, nombre de RR = 0
    Nom "(7) smtpgw1 (3) gov (2) sur (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION AUTORITÉ:
      vide
    SECTION ADDITIONNELLE:
      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 R Q [0084 A NOERROR] AAAA (7) smtpgw1 (3) gov (2) sur (2) ca (0)
Informations de réponse UDP à 000000EFF2188100
  Socket = 9812
  Adresse distante 204.41.8.237, port 53
  Requête temporelle = 4556080, en file d'attente = 0, expire = 0
  Longueur en bits = 0x0fa0 (4000)
  Msg longueur = 0x0023 (35)
  Message:
    XID 0x3e6c
    Drapeaux 0x8400
      QR 1 (RÉPONSE)
      OPCODE 0 (CHERCHER)
      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, nombre de RR = 0
    Nom "(7) smtpgw1 (3) gov (2) sur (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION AUTORITÉ:
      vide
    SECTION ADDITIONNELLE:
      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 R Q [8281 DR SERVFAIL] AAAA (7) smtpgw1 (3) gov (2) sur (2) ca (0)
Informations de réponse UDP à 000000EFF1BF01A0
  Socket = 508
  Adresse à distance 172.16.0.254, port 50764
  Requête temporelle = 4556080, En file d'attente = 4556080, Expirer = 4556083
  Longueur en bits = 0x0fa0 (4000)
  Msg longueur = 0x002e (46)
  Message:
    XID 0xa61e
    Drapeaux 0x8182
      QR 1 (RÉPONSE)
      OPCODE 0 (CHERCHER)
      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, nombre de RR = 0
    Nom "(7) smtpgw1 (3) gov (2) sur (2) ca (0)"
      QTYPE AAAA (28)
      QCLASS 1
    SECTION RÉPONSE:
      vide
    SECTION AUTORITÉ:
      vide
    SECTION ADDITIONNELLE:
    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.com renvoie NOERROR et aucun résultat. Même chose pour google.com renvoie correctement les adresses IPv6 de Google.
  • J'ai essayé d'installer le correctif de KB3014171, ne fait aucune différence.
  • La mise à jour de KB3004539 est déjà installé.

Éditer le 7 novembre 2015

J'ai configuré une autre machine Server 2012R2 non liée au domaine et installé le rôle de serveur DNS, puis testé avec la commande. nslookup -type=aaaa smtpgw1.gov.on.ca localhost. Il n'a pas les mêmes problèmes.

Les deux ordinateurs virtuels se trouvent sur le même hôte et sur le même réseau, ce qui élimine tout problème de réseau / pare-feu. C’est maintenant au niveau des correctifs ou en tant que membre de domaine / contrôleur de domaine qui fait la différence.

Éditer le 8 novembre 2015

Appliqué toutes les mises à jour, ne fait aucune différence. Je suis allé vérifier deux fois 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 en a - le contrôleur de domaine a été configuré pour les redirecteurs.

Maintenant, je suis sûr d’avoir essayé avec les redirecteurs et sans mes premiers tests, mais je l’ai seulement essayé avec dig depuis une machine linux. J'obtiens des résultats légèrement différents avec et sans la configuration des redirecteurs (essayé avec Google, OpenDNS, 4.2.2.1 et les serveurs DNS de mon fournisseur de services Internet) lorsque j'utilise nslookup sur une machine Windows.

Avec un ensemble de transitaires, je reçois Server failed.

Sans un expéditeur (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 possèdent pas d'enregistrements IPv6 - nslookup sur Windows ne renvoie aucun résultat pour d'autres domaines.

Avec ou sans expéditeurs, dig montre toujours SERVFAIL pour ce nom lors de l'interrogation de mon serveur DNS Windows.

Il existe une petite différence entre le domaine problématique et les autres qui semble pertinente, même lorsque je n'utilise pas mon serveur DNS Windows:

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

dig -t aaaa @8.8.8.8 serverfault.com ne renvoie pas de réponse, mais comporte une section 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 considère-t-il cela comme un échec alors que les autres serveurs DNS ne le font pas?


17
2017-10-15 22:36


origine


Effectuez-vous ces tests à partir du serveur Exchange? Sinon, je suggérerais de le faire pour que vous puissiez le voir du point de vue de Exchange. Vous voudrez peut-être aussi essayer d’exécuter SMTPDiag à partir du serveur Exchange. Je suggérerais de l'exécuter lors d'une capture réseau sur le serveur Exchange afin de pouvoir 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. Je pense donc que cela devrait fonctionner sur toutes les versions d’Exchange. - microsoft.com/en-us/download/details.aspx?id=11393 - joeqwerty
@joeqwerty merci, voir edit pour les résultats - Grant
Certains périphériques réseau ne reconnaissent pas et rejetteront les paquets EDNS. Votre équipe réseau a-t-elle introduit un nouveau périphérique / paramètre récemment? Pour éliminer cette possibilité, essayez de résoudre l'enregistrement AAAA de google.com. Il devrait renvoyer une adresse IPv6. - strongline
@strongline Les paquets EDNS fonctionnent bien. L’enregistrement AAAA pour Google fonctionne, de même que quelques autres sites que je connais, qui fonctionnent avec IPv6. La seule chance que nous avons eue récemment était de nous débarrasser de notre dernier serveur Server 2008R2 DC / DNS et de le remplacer par 2012R2. - Grant
IPv6 est-il désactivé de quelque manière que ce soit dans votre environnement? - Jim B


Réponses:


J'ai regardé dans la trace du réseau un peu plus et fait quelques lectures. La requête pour l'enregistrement AAAA, lorsqu'elle est inexistante, retourne une SOA. Il s'avère que la SOA concerne un domaine différent de celui demandé. Je suppose que c'est la raison pour laquelle Windows rejette la réponse. Demander AAAA pour mx.atomwide.com. Réponse SOA pour lgfl.org.uk. Je verrai si nous pouvons faire des progrès avec cette information. EDIT: Juste pour référence future, désactiver temporairement "Sécuriser le cache contre la pollution" permettra à la requête de réussir. Pas idéal, mais prouve que le problème est lié à un enregistrement DNS louche. La RFC4074 est également une bonne référence - Intro et Section.


2
2018-03-18 11:54



Je vais essayer de tester cela aujourd'hui dans mon environnement, mais je pense que vous pouvez être sur quelque chose! - Grant
De plus, j'ai édité votre lien - les signatures et les liens hors sujet ne sont pas autorisés ici, et je ne veux pas que votre réponse par ailleurs excellente soit supprimée. - Grant


Selon KB832223

Cause

Ce problème est dû à la fonctionnalité EDNS0 (mécanisme d'extension) pour DNS prise en charge dans le serveur 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 qu'il reconnaisse et autorise les paquets UDP d'une taille supérieure à 512 octets. Pour plus d'informations sur la procédure à suivre, contactez le fabricant de votre programme de pare-feu.

Microsoft propose la solution 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:

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

dnscmd /config /enableednsprobes 0 

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


0
2018-02-29 20:53



J'ai vu cet article - les pare-feu que j'ai testés avec les deux passent de gros paquetsdns sans problème, comme en témoigne son fonctionnement parfait sous linux. La désactivation de edns empêche l'utilisation de DNSSEC. Par conséquent, même si cela résout 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 tout Microsoft OS qui fonctionne à travers le pare-feu? - Tim Penner