Après la publication de l'article Le problème DNS de la semaine par Banque Populaire, Stéphane et moi-même avons lu des témoignages sur Twitter relatant qu'un problème similaire serait en cours à la Caisse d'Épargne depuis, a priori, le même laps de temps : ici, là-bas, là, encore là, ici aussi, là-bas, et puis ici et enfin là.
Banque Populaire et Caisse d'Épargne faisant partie du même groupe, BPCE, ce n'est pas surprenant.
Nous avons déjà posé les définitions et exposé le contexte dans l'article sur le problème DNS à la Banque Populaire, donc passons directement à la résolution du nom www.caisse-epargne.fr à la main :
$ dig @d.nic.fr www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 172800 IN NS ns1.gcetech.net.
caisse-epargne.fr. 172800 IN NS ns2.gcetech.net.
[…]
$ dig @91.135.176.225 www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
www.caisse-epargne.fr. 86400 IN NS nslp2.gcetech.net.
www.caisse-epargne.fr. 86400 IN NS nslp1.gcetech.net.
[…]
$ dig @91.135.188.225 www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
www.caisse-epargne.fr. 86400 IN NS nslp2.gcetech.net.
www.caisse-epargne.fr. 86400 IN NS nslp1.gcetech.net.
[…]
$ dig @91.135.177.240 www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr. 120 IN A 91.135.178.85
[…]
$ dig @91.135.189.240 www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr. 120 IN A 91.135.178.85
[…]
Constat ?
Jusque-là, le problème reste entier. Continuons à creuser.
Les serveurs DNS qui font autorité pour la zone www.caisse-epargne.fr, nslp1.gcetech.net. et nslp2.gcetech.net. , répondent NODATA (cette information n'existe pas dans le type demandé, mais des informations d'un autre type existent pour le nom demandé) aux requêtes DNS de types NS et SOA :
$ dig @91.135.177.240 SOA www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42171
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
$ dig @91.135.189.240 SOA www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5107
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
$ dig @91.135.177.240 NS www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18648
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
$ dig @91.135.189.240 NS www.caisse-epargne.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3758
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
Cela est totalement contraire à la norme DNS et cela peut bloquer certaines implémentations de récursifs DNS (voire certaines versions d'une même implémentation), ce qui explique le côté aléatoire et partiel de la panne.
Mais, cette fois-ci, l'impact de ce choix technique est plus subtil :
$ dig @1.1.1.1 A www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15150
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
$ dig @80.67.169.12 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr. 120 IN A 91.135.178.85
[…]
;; Query time: 2302 msec
[…]
$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"
$ dig @80.67.169.40 A www.caisse-epargne.fr
[…]
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"
Le comportement du service de résolution des noms de CloudFlare reste inchangé.
En revanche, si aucun des serveurs DNS récursifs du FAI FDN parvient à résoudre www.banquepopulaire.fr, l'un d'eux, un Unbound en version 1.9 parvient à résoudre le nom www.caisse-epargne.fr. On notera qu'il met environ 2 secondes pour ce faire, ce qui est très long et révélateur d'un problème. Le serveur Unbound en version 1.6 ne parvient pas à résoudre www.caisse-epargne.fr.
Cela explique pourquoi je n'ai pas perçu que la Caisse d'Épargne était également impactée quand j'ai diagnostiqué le problème de la Banque Populaire : mon Unbound local transmet toutes mes requêtes DNS aux deux serveurs DNS récursifs de FDN (afin de profiter de la mutualisation de cache, donc de réduire la charge sur les serveurs DNS qui font autorité de tous les services Internet que j'utilise) et comme l'un répond, j'accède sans problème au site web de la Caisse d'Épargne.
Quelle est donc cette implémentation de serveur de noms DNS qui accepte de charger une zone DNS dépourvue d'enregistrements de types SOA et NS ?
$ dig +short @nslp1.gcetech.net. version.bind chaos txt
"none"
$ dig +short @nslp2.gcetech.net. version.bind chaos txt
"none"
Ça ressemble quand même fortement à un BIND qu'on aurait configuré avec « version "none"; » au lieu de « version none; », mais rien permet de justifier cette affirmation. Comme à la Banque Populaire, il est très probable qu'une (ou plusieurs) middlebox, équilibreur de charge ou non, soit présente entre ces serveurs DNS et Internet et qu'elle soit responsable de cette panne partielle par altération des réponses du serveur ou filtrage de certaines requêtes.
Notons que la Caisse d'Épargne n'a pas fait la même erreur que la Banque Populaire : les serveurs DNS qui font autorité pour www.caisse-epargne.fr, nslp1.gcetech.net. et nslp2.gcetech.net. répondent en UDP et en TCP :
$ dig +tcp @91.135.177.240 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr. 120 IN A 91.135.178.85
[…]
$ dig +tcp @91.135.177.240 NS www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61730
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
$ dig +tcp @91.135.189.240 A www.caisse-epargne.fr
[…]
;; ANSWER SECTION:
www.caisse-epargne.fr. 120 IN A 91.135.178.85
[…]
$ dig +tcp @91.135.189.240 NS www.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61788
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
En revanche, les équipes techniques de la Caisse d'Épargne devraient réviser la syntaxe du champ « RNAME » d'un enregistrement DNS de type SOA. Il permet d'indiquer une adresse email permettant de signaler un problème. Dans le cas de la Caisse d'Épargne :
$ dig +short SOA caisse-epargne.fr
ns1.gcetech.net. postmaster.it-ce.fr. 2020052602 21600 3600 1209600 86400
$ dig @91.135.177.240 SOA www.caisse-epargne.fr
[…]
;; AUTHORITY SECTION:
caisse-epargne.fr. 60 IN SOA P-SR1-IGTM1.big.caisse-epargne.fr. hostmaster.P-SR1-IGTM1.big.caisse-epargne.fr. 3338 10800 3600 604800 60
[…]
// Selon la convention d'usage, l'adresse emails doit donc être hostmaster@P-SR1-IGTM1.big.caisse-epargne.fr
$ dig MX P-SR1-IGTM1.big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29793
[…]
$ dig A P-SR1-IGTM1.big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2114
[…]
// Non. L'adresse doit être hostmaster.P-SR1-IGTM1 à big.caisse-epargne.fr (il aurait fallu l'indiquer en mettant un « \. » entre « hostmaster » et « P-SR1-IGTM1 ».
$ dig MX big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8736
[…]
$ dig A big.caisse-epargne.fr
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51961
[…]
// Non. L'adresse n'est quand même pas hostmaster.P-SR1-IGTM1.big à caisse-epargne.fr ?! (Et si oui, même remarque que ci-dessus)
$ dig +short MX caisse-epargne.fr
5 mail-in.bpce-it.fr.
$ telnet mail-in.bpce-it.fr. 25
Trying 91.135.189.237...
Connected to mail-in.bpce-it.fr.
Escape character is '^]'.
220 mail-in.bpce-it.fr ESMTP
EHLO test.guiguishow.info
250-mail-in.bpce-it.fr
250-8BITMIME
250-SIZE 28311552
250 STARTTLS
MAIL FROM:<[CENSURE]>
250 sender <[CENSURE]> ok
RCPT TO:<hostmaster [à] P-SR1-IGTM1.big.caisse-epargne.fr>
550 #5.1.0 Address rejected.
RCPT TO:<hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr>
250 recipient <hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr> ok
RCPT TO:<hostmaster.P-SR1-IGTM1.big [à] caisse-epargne.fr>
250 recipient <hostmaster.P-SR1-IGTM1.big [à] caisse-epargne.fr> ok
QUIT
221 mail-in.bpce-it.fr
Connection closed by foreign host.
La deuxième adresse, hostmaster.P-SR1-IGTM1 [à] big.caisse-epargne.fr , est invalide puisqu'aucun serveur d'emails est défini pour ce domaine (si l'on tente d'envoyer un email, le MTA émetteur remonte légitimement l'erreur suivante : « Host or domain name not found. Name service error for name=big.caisse-epargne.fr type=AAAA: Host not found »). Vu les élements, le contenu du champ « RNAME » devrait être « hostmaster\.P-SR1-IGTM1\.big.caisse-epargne.fr
». Ça a aucun rapport avec la panne partielle dont traite cet article, mais c'est tout de même un problème de configuration.
Alors, au final, quelle est l'origine du problème ?
Difficile à dire. On le saura jamais vraiment, toute entité (société commerciale, administration, association, personne) étant toujours très réticente à faire des retours sur ses erreurs / fautes / échecs.
Je pense qu'il y a une middlebox (ou plusieurs) entre Internet et les serveurs DNS qui font autorité pour la zone DNS www.caisse-epargne.fr qui, comme tout boîtier prétendument magique ‒ qui externalise de fait la réflexion ‒ souvent imposé au service informatique par la direction afin qu'elle puisse prétendre œuvrer pour la sécurité des clients sans investir ni comprendre / maîtriser la technique sous-jacente, doit forger des réponses DNS invalides (NODATA pour les types SOA et NS).
Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Caisse d'Épargne ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…
Merci à Stéphane Bortzmeyer pour son aide, son soutien ainsi que sa motivation pour faire remonter ces pannes à BPCE, notamment sur Twitter.