2 votes

mikebridge avatar

Échec intermittent des requêtes DNS récursives/itératives

Demandé el 3 de Avril, 2013
Quand la question a-t-elle été
8921 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai un problème d'émission de requêtes vers un DNS et je ne sais pas où chercher la cause sous-jacente.

J'ai un enregistrement "www.alumninews.uottawa.ca" qui est un enregistrement CNAME qui pointe vers un enregistrement A pour "uottawa.mailoutinteractive.com" que j'héberge. Lorsque j'interroge les serveurs DNS de mon FAI, j'obtiens des réponses différentes :

Le premier ne fait pas de récursion

$ dig +recurse www.alumninews.uottawa.ca @64.59.184.13

; <<>> DiG 9.8.1-P1 <<>> +recurse www.alumninews.uottawa.ca @64.59.184.13
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13260
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.alumninews.uottawa.ca. IN  A

;; ANSWER SECTION:
www.alumninews.uottawa.ca. 3600 IN  CNAME   uottawa.mailoutinteractive.com.

;; Query time: 139 msec
;; SERVER: 64.59.184.13#53(64.59.184.13)
;; WHEN: Wed Apr  3 11:33:55 2013
;; MSG SIZE  rcvd: 87

Notez que le CNAME n'est pas résolu (voir ci-dessous).

La seconde résout correctement le CNAME (notez que le TTL est maintenant de 3532, et non de 3600 comme par défaut ci-dessus) :

$ dig +recurse www.alumninews.uottawa.ca @64.59.184.13

; <<>> DiG 9.8.1-P1 <<>> +recurse www.alumninews.uottawa.ca @64.59.184.13
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.alumninews.uottawa.ca. IN  A

;; ANSWER SECTION:
www.alumninews.uottawa.ca. 3532 IN  CNAME   uottawa.mailoutinteractive.com.
uottawa.mailoutinteractive.com. 300 IN  A   209.15.195.166

;; Query time: 30 msec
;; SERVER: 64.59.184.13#53(64.59.184.13)
;; WHEN: Wed Apr  3 11:35:03 2013
;; MSG SIZE  rcvd: 103

De plus, lorsque je capture le trafic réseau avec Wireshark, je constate que l'erreur lors de la recherche de uottawa.mailoutinteractive.com est "Reply code : No such name (3)" lors de l'échec de la récursion :

Domain Name System (response)
[Request In: 3993]
[Time: 0.057954000 seconds]
Transaction ID: 0xf07c
Flags: 0x8183 Standard query response, No such name
    1... .... .... .... = Response: Message is a response
    .000 0... .... .... = Opcode: Standard query (0)
    .... .0.. .... .... = Authoritative: Server is not an authority for domain
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired: Do query recursively
    .... .... 1... .... = Recursion available: Server can do recursive queries
    .... .... .0.. .... = Z: reserved (0)
    .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
    .... .... ...0 .... = Non-authenticated data: Unacceptable
    .... .... .... 0011 = Reply code: No such name (3)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
    www.alumninews.uottawa.ca: type A, class IN
        Name: www.alumninews.uottawa.ca
        Type: A (Host address)
        Class: IN (0x0001)
Answers
    www.alumninews.uottawa.ca: type CNAME, class IN, cname uottawa.mailoutinteractive.com
        Name: www.alumninews.uottawa.ca
        Type: CNAME (Canonical name for an alias)
        Class: IN (0x0001)
        Time to live: 1 hour
        Data length: 32
        Primaryname: uottawa.mailoutinteractive.com

Une recherche réussie ressemble à ceci dans Wireshark (il s'agit d'un domaine différent avec le même problème) :

Domain Name System (response)
[Request In: 70]
[Time: 0.051422000 seconds]
Transaction ID: 0x417d
Flags: 0x8180 Standard query response, No error
    1... .... .... .... = Response: Message is a response
    .000 0... .... .... = Opcode: Standard query (0)
    .... .0.. .... .... = Authoritative: Server is not an authority for domain
    .... ..0. .... .... = Truncated: Message is not truncated
    .... ...1 .... .... = Recursion desired: Do query recursively
    .... .... 1... .... = Recursion available: Server can do recursive queries
    .... .... .0.. .... = Z: reserved (0)
    .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
    .... .... ...0 .... = Non-authenticated data: Unacceptable
    .... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 0
Additional RRs: 0
Queries
    www.bulletinsanciens.uottawa.ca: type A, class IN
        Name: www.bulletinsanciens.uottawa.ca
        Type: A (Host address)
        Class: IN (0x0001)
Answers
    www.bulletinsanciens.uottawa.ca: type CNAME, class IN, cname uottawa.mailoutinteractive.com
        Name: www.bulletinsanciens.uottawa.ca
        Type: CNAME (Canonical name for an alias)
        Class: IN (0x0001)
        Time to live: 41 minutes, 26 seconds
        Data length: 32
        Primaryname: uottawa.mailoutinteractive.com
    uottawa.mailoutinteractive.com: type A, class IN, addr 209.15.195.166
        Name: uottawa.mailoutinteractive.com
        Type: A (Host address)
        Class: IN (0x0001)
        Time to live: 5 minutes
        Data length: 4
        Addr: 209.15.195.166 (209.15.195.166)

Les serveurs DNS de l'Université d'Ottawa sont configurés pour ne pas renvoyer d'informations sur les requêtes récursives. Je crois donc savoir que mon fournisseur d'accès fera une deuxième requête pour résoudre le CNAME. Mais je ne sais pas pourquoi il échoue une fois et réussit une deuxième fois. Il s'agit de semble Il me semble qu'il s'agit d'un problème entre notre FAI (Shaw) et Route53, où sont hébergés mes DNS.

Je remarque également qu'il continue souvent à échouer - je peux continuer à exécuter la commande dig qui échoue pendant un certain temps avant qu'elle ne réussisse à nouveau.

Je suis arrivé jusqu'ici mais je ne sais pas comment déboguer davantage. Une idée de l'origine de l'échec ?

Demandé el 3 de Avril, 2013 par mikebridge

Réponses

Trop de publicités?

1voto

Isaac Dontje Lindell avatar
Isaac Dontje Lindell Points 409

La capture de paquets ne révèle rien de plus que vos requêtes de recherche. Reply code: No such name (3) est un moyen long et fastidieux de dire NXDOMAIN ( RCODE 3 ), cette dernière étant plus significative pour les administrateurs de DNS. Je ne supprimerai pas la capture de paquets de votre message, mais il y aura moins de mur de texte à parcourir pour les autres si vous êtes d'accord avec moi sur ce point.

Une réponse de NXDOMAIN est problématique ; il s'agit d'une indication d'une succès de par les serveurs de noms récursifs de votre FAI. C'est un mauvais comportement de votre point de vue car l'enregistrement est manquant, mais la façon dont il a échoué raconte une autre histoire. Les serveurs de votre FAI disent : "J'ai parlé aux serveurs de noms faisant autorité, j'ai reçu une réponse positive, et ils m'a dit que l'enregistrement n'existait pas". C'est très différent de SERVFAIL ce qui indiquerait un réel problème de communication.

Les différentes réponses entre les requêtes sont très probablement dues à l'équilibrage de la charge : il y a plusieurs serveurs derrière l'adresse IP que vous interrogez. L'un d'entre eux a mis en "cache négatif" l'échec de la recherche et ne tentera pas de la relancer avant que l'autre ne l'ait fait. ncache pour ce domaine expire. Un autre de leurs serveurs a réussi, et l'a mis en "cache positif", ce qui fait qu'il se souvient de cette réponse pendant la durée du TTL. (3532 signifie que 68 secondes se sont écoulées depuis cet événement, 3532+68 = 3600)

Conclusion

En raison de la nature distribuée d'AWS, il sera extrêmement difficile pour l'un d'entre nous de vous donner des conseils supplémentaires. J'ai interrogé les quatre adresses de serveurs de noms qui m'ont été servies et je n'ai trouvé aucun problème.

Si vous rencontrez à nouveau ce problème, vous pouvez essayer d'interroger le fichier A enregistrer directement pour voir si quelque chose ressort :

dig www.alumninews.uottawa.ca @64.59.184.1
( +recurse est défini par défaut et n'est pas nécessaire)

Votre meilleure chance est de demander à votre fournisseur d'accès de faire une enquête plus approfondie la prochaine fois que cela se produit, mais préparez-vous à recevoir une réponse du type "notre serveur fait ce qu'on lui a demandé de faire et nous ne pouvons pas vous aider".

Répondu el 3 de Octobre, 2014 par Isaac Dontje Lindell (409 Points )

0voto

Espen Andersen avatar
Espen Andersen Points 11

Il me semble qu'il s'agit d'un problème entre notre FAI (Shaw) et Route53, où sont hébergés mes DNS.

Je suis d'accord. Puisque 8.8.8.8 et 8.8.4.4 (les serveurs DNS de google) et mes serveurs DNS locaux ne montrent pas de problèmes comme ceux que vous décrivez, il est temps d'escalader avec les administrateurs du serveur de noms de votre FAI.

Répondu el 4 de Avril, 2013 par Espen Andersen (11 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X