J'ai voulu signaler leur problème DNS à la Banque Populaire et à la Caisse d'Épargne, mais impossible de leur envoyer un email.

Le serveur emails pour tous les domaines dont font partie les adresses emails techniques trouvées dans les bases de données publiques accessibles avec le protocole whois (et bientôt RDAP ?) est mail-in.bpce-it.fr.

Celui-ci refuse mes emails pour le motif suivant : « 550 #5.7.5 DKIM unauthenticated mail is prohibited. If you believe that this failure is in error, please refer to https://tools.ietf.org/html/rfc6376 or contact postmaster [à] bpce-it.fr for more information via alternate means. »

J'ai bien envoyé mon courriel via le seul serveur emails autorisé pour mon domaine.

Étrangement, un email envoyé par Stéphane depuis un domaine qui n'implémente pas DKIM passe très bien. Cela illustre que DKIM n'est pas obligatoire pour communiquer avec BPCE. Peut-être qu'une signature DKIM devient obligatoire quand la réputation de l'adresse IP ou du réseau du serveur emails émetteur est questionnable ? Mon serveur est hébergé chez OVH, émetteur de spam malgré lui, alors que celui de Stéphane est dans un réseau IP de bonne réputation.

Encore plus étrange : mes emails sont bien signés en suivant la norme DKIM. Peut-être y a-t-il un problème technique de mon côté ?

Je m'envoie un email à une autre adresse que je gère et qui met en œuvre la validation DKIM : à l'arrivée, les entêtes de l'email confirment qu'il comporte bien une signature DKIM et que celle-ci est valide : « Authentication-Results: viki.guiguishow.info; dkim=pass (3072-bit key; secure) header.d=[CENSURE] header.i=@[CENSURE] header.b="PGTxFJuT"; dkim-atps=neutral ».

Il existe des testeurs de serveur emails. J'en ai utilisé trois (plus que ça en vrai, mais certains ne fonctionnent plus) : https://www.mail-tester.com/ , auth-results [à] verifier.port25.com , et ping [à] stamper.itconsult.co.uk . Tous les trois confirment la présence et la validité d'une signature DKIM dans mes emails sortant. Il semble donc que le problème est du côté de BPCE.

De plus, j'ai configuré une politique ADSP souple, « dkim=all » qui signifie "normalement, tout courriel émanant de ce domaine sera signé, mais si ce n'est pas le cas, ne le jete pas à la corbeille, stp". Évidemment, elle a la valeur d'un conseil : le récepteur fait bien ce qu'il veut.

Pour signer les entêtes de mes emails sortants, mon serveur emails utilise une clé RSA 3072 bits. C'est la taille recommandée par l'ANSSI (document B1) pour mettre sérieusement en pratique de la cryptographie au long terme. Mais, c'est vrai que, pour signer des emails dans le cadre de la lutte anti-spam (c'est l'objet de DKIM), une clé de taille inférieure serait suffisante. Néanmoins, début 2018, le RFC 8301 a mis à jour le RFC de DKIM (6376) : « Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. ».

Je conçois bien un problème à ce niveau-là : ma clé est rejetée en raison de sa taille, donc mon email est considéré comme étant non signé, donc, soit la réputation du réseau de mon serveur emails joue contre lui, soit BPCE-IT est intransigeant avec les domaines qui ont une politique ADSP fut-elle souple. Cette hypothèse a été confirmée par BPCE-IT : « […] en raison d’une limitation de notre produit actuel, nous ne pouvons pas vérifier de signature au-dessus de 2048 bits et il ne connait pas la notion de politique ADSP. Ainsi la signature 3072 bits est traitée en erreur […] ».

A priori, ce souci a été signalé à BPCE-IT par Stéphane, merci. :)

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 ?

• Tout comme à la Banque Populaire, le nom www.caisse-epargne.fr est délégué ;
  
  
• Contrairement à la Banque Populaire, deux serveurs DNS qui font autorité situés dans deux réseaux IP différents (mais situés dans une même infrastructure technique et administrative / organisationnelle) assurent le service, ce qui est le minimum syndical en matière de DNS ;
  
  
• Comme à la Banque Populaire, on relève un TTL (durée de vie de l'information associée à un nom DNS dans le cache des serveurs récursifs) court, mais acceptable. Si un tel délai est très utile lors d'une migration afin de rendre la bascule effective sous un court délai, il est déconseillé le reste du temps, car, ne bénéficiant pas des caches, le moindre problème technique entraînera une panne d'une toute autre ampleur. De plus, des hébergeurs de serveur DNS récursif réécrivent, donc ignorent, les TTL courts (c'est le cas de l'opérateur Free, par exemple).

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.