J'ai un contrôleur de domaine Windows 2008 R2 qui est également un serveur DNS. Lors de la résolution de certains TLD, il renvoie un SERVFAIL:
$ 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
J'obtiens le même résultat pour un vrai TLD comme com.lors de l'interrogation du DC comme indiqué ci-dessus. Comparez avec un serveur BIND qui fonctionne comme prévu:
$ 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
De même, lorsque j'interroge mon serveur DNS Windows avec dig . any, j'obtiens un SERVFAIL mais les serveurs BIND renvoient la zone racine comme prévu.
Cela ressemble au problème décrit dans http://support.microsoft.com/kb/968372, sauf que j'utilise deux redirecteurs (128.59.59.70 ci-dessus ainsi que 128.59.62.10) et que je retombe sur les indices racine pour que les conditions préalables à exposer le problème ne sont pas les mêmes. Néanmoins, j'ai également appliqué le MaxCacheTTLcorrectif de registre comme décrit et redémarré DNS et l'ensemble du serveur, mais le problème persiste. Le problème se produit sur tous les contrôleurs de domaine de ce domaine et se produit depuis six mois, même si les serveurs reçoivent des mises à jour automatiques de Windows.
ÉDITER
Voici un journal de débogage. Le client est 160.39.114.110, qui est mon poste de travail.
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
Chaque option dans la boîte de journal de débogage a été cochée sauf "filtrer par IP". En revanche, lorsque je recherche, disons, accounts.google.com, je peux voir le serveur DNS aller vers son redirecteur (128.59.59.70, par exemple). Dans ce cas, je n'ai vu aucun paquet sortir de mon serveur DNS même s'il bogus.n'était pas dans le cache (le journal de débogage était déjà en cours d'exécution et c'est la première fois que je demandais ce serveur pour bogus.ou tout TLD). Il vient de renvoyer SERVFAIL sans consulter aucun autre serveur DNS, comme dans l'article Microsoft KB lié ci-dessus.
la source
Réponses:
Nous avons rencontré un problème similaire sur les serveurs DNS Microsoft sans aucun redirecteur configuré. On dirait que ce correctif est lié: http://support.microsoft.com/kb/2508835 . Je ne dirais pas que l'utilisation de transitaires annulerait l'applicabilité.
la source