Depuis au moins jeudi 28 mai 2020 à 22 h 45 (UTC+2), impossible d'accéder à certains sites web du groupe Banque Populaire Caisse d'Épargne :
Qu'est-ce qui ne fonctionne pas, précisément ? La résolution des noms DNS. Mon navigateur web Mozilla Firefox affiche « Recherche de […] » puis « Hum, nous ne parvenons pas à trouver ce site. ».
Comme d'habitude, Twitter fournit des témoignages dont le plus savoureux relate :
Bonjour @BanquePopulaire impossible de se connecter avec l’application sur iPhone depuis hier soir et donc de déverrouiller ma carte bancaire... C’est un problème général?
À quel moment tu t'es dit que c'est génial de débloquer une carte bancaire avec un logiciel pour ordinateur de poche ?! Tout peut foirer ! Ton ordinateur de poche peut tomber en panne, ton opérateur de téléphonie mobile aussi, un opérateur Internet de transit idem, Banque Populaire également, etc. Ce choix d'une telle dépendance à une technologie est hallucinant.
J'ai mon accès à Internet fixe chez le Fournisseur d'Accès à Internet associatif FDN et j'utilise les serveurs DNS récursifs de ce dernier. Le problème est le même depuis un serveur OVH (en utilisant les serveurs DNS récursifs d'OVH). Le service de résolution des noms de CloudFlare parvient jamais à résoudre le nom. Celui de Google y parvient plutôt souvent, mais il y a encore des ratés. Depuis un accès à Internet Orange avec un dnsmasq
local, ça fonctionne difficilement ou pas du tout.
La transmission réseau entre FDN (ou OVH ou Orange) et le réseau Banque Populaire est OK : un mtr -T -P 443 91.135.183.174
montre ni incident réseau ni perte de paquets.
Le niveau applicatif est OK : un openssl s_client -connect 91.135.183.174:443 -crlf
permet de dialoguer en HTTPS avec l'un des serveurs de la Banque Populaire. Une mesure depuis le réseau RIPE Atlas confirme cela, voire la mesure numéro 25558553.
Enfin, ajouter une association IP pour les noms www.ibps.bpaca.banquepopulaire.fr et www.banquepopulaire.fr dans mon fichier /etc/hosts
rend ces sites web parfaitement fonctionnels. Attention : utiliser ce contournement uniquement pour des tests ! Si Banque Populaire change les adresses IP de ses services, la surcharge locale rendra inaccessibles les services.
On confirme donc un problème de résolution de certains des noms DNS de la Banque Populaire.
Néanmoins, mes mesures avec le réseau RIPE Atlas montre un faible taux d'échec de la résolution DNS : mesure numéro 25556510, mesure numéro 25556573 et mesure numéro 25556574.
Effectuons la résolution DNS à la main :
$ dig @d.nic.fr www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
banquepopulaire.fr. 172800 IN NS dns2.bpce.fr.
banquepopulaire.fr. 172800 IN NS dns1.bpce.fr.
;; ADDITIONAL SECTION:
dns1.bpce.fr. 172800 IN A 91.135.189.110
dns2.bpce.fr. 172800 IN A 91.135.177.110
[…]
$ dig @91.135.189.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600 IN NS
nsisp1.i-bp.banquepopulaire.fr.
;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr. 300 IN A 91.135.182.250
[…]
$ dig @91.135.177.110 www.ibps.bpaca.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.ibps.bpaca.banquepopulaire.fr. 3600 IN NS
nsisp1.i-bp.banquepopulaire.fr.
;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr. 300 IN A 91.135.182.250
[…]
$ dig @91.135.182.250 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ANSWER SECTION:
www.ibps.bpaca.banquepopulaire.fr. 30 IN A 91.135.183.174
[…]
$ dig @91.135.189.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr. 3600 IN NS nsisp1.i-bp.banquepopulaire.fr.
;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr. 300 IN A 91.135.182.250
[…]
$ dig @91.135.177.110 www.banquepopulaire.fr
[…]
;; AUTHORITY SECTION:
www.banquepopulaire.fr. 3600 IN NS nsisp1.i-bp.banquepopulaire.fr.
;; ADDITIONAL SECTION:
nsisp1.i-bp.banquepopulaire.fr. 300 IN A 91.135.182.250
[…]
$ dig @91.135.182.250 www.banquepopulaire.fr
[…]
;; ANSWER SECTION:
www.banquepopulaire.fr. 30 IN A 91.135.183.180
www.banquepopulaire.fr. 30 IN A 91.135.183.180
[…]
$ dig @k.gtld-servers.net. groupebpce.com
[…]
;; AUTHORITY SECTION:
groupebpce.com. 172800 IN NS dns1.bpce.fr.
groupebpce.com. 172800 IN NS dns2.bpce.fr.
[…]
$ dig @91.135.189.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com. 3600 IN A 151.101.194.133
groupebpce.com. 3600 IN A 151.101.2.133
groupebpce.com. 3600 IN A 151.101.66.133
groupebpce.com. 3600 IN A 151.101.130.133
[…]
$ dig @91.135.177.110 groupebpce.com
[…]
;; ANSWER SECTION:
groupebpce.com. 3600 IN A 151.101.130.133
groupebpce.com. 3600 IN A 151.101.66.133
groupebpce.com. 3600 IN A 151.101.2.133
groupebpce.com. 3600 IN A 151.101.194.133
[…]
On constate trois choses :
Jusque-là, le problème reste entier. Continuons à creuser.
Le serveur qui fait autorité pour les zones www.ibps.*.banquepopulaire.fr et www.banquepopulaire.fr , nsisp1.i-bp.banquepopulaire.fr , répond négativement aux requêtes de types NS et SOA :
$ dig @91.135.182.250 SOA www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17798
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
$ dig @91.135.182.250 NS www.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 36129
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
$ dig @91.135.182.250 SOA www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 31905
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
$ dig @91.135.182.250 NS www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17813
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
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 de la panne.
Les serveurs DNS dns1.bpce.fr et dns2.bpce.fr répondent aux requêtes de types NS et SOA pour la zone groupebpce.com, ce qui explique que le site web corporate fonctionne là où les autres sites web ne fonctionnent pas.
Le serveur DNS nsisp1.i-bp.banquepopulaire.fr ne répond pas aux requêtes DNS émises au-dessus du protocole TCP :
$ dig +tcp @91.135.182.250 A www.banquepopulaire.fr
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +tcp @91.135.182.250 A www.banquepopulaire.fr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
;; Connection to 91.135.182.250#53(91.135.182.250) for www.banquepopulaire.fr failed: timed out.
C'est, là encore, totalement contraire à la norme DNS : tout serveur DNS doit être accessible sur udp/53 et tcp/53.
Cette absence de réponse aux requêtes de types SOA/NS posera encore plus de problèmes aux récursifs DNS qui implémentent la qname minimisation, un mécanisme qu'il faut activer car il participe à la préservation de la vie privée des utilisateurs d'un serveur DNS récursif. En effet, une divergence d'interprétation de la norme existe concernant la recherche des délégations. On rappelle au passage qu'une délégation DNS ne se voit pas à l'œil nu. Exemples : bpaca.banquepopulaire.fr n'est pas délégué par banquepopulaire.fr, ibps.bpaca.banquepopulaire.fr n'est pas non plus délégué par bpaca.banquepopulaire.fr. Bref : un point entre deux labels d'un nom de domaine ne marque pas forcément une délégation. Afin d'identifier les délégations, certaines implémentations, comme Unbound, effectuent des requêtes de type A (que le serveur DNS nsisp1.i-bp.banquepopulaire.fr accepte, pour rappel), d'autres des requêtes de type NS (qui sont refusées par nsisp1.i-bp.banquepopulaire.fr).
Concernant l'amplification du problème par certaines implémentations de qname minimisation dans les serveurs DNS récursifs , le mystère continue, car :
$ dig +short @80.67.169.40 version.bind chaos txt
"unbound 1.6.0"
$ dig +short @80.67.169.12 version.bind chaos txt
"unbound 1.9.0"
$ dig +short @::1 version.bind chaos txt
"unbound 1.9.0"
$ dig +short @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
;; connection timed out; no servers could be reached
$ dig @80.67.169.12 www.ibps.bpaca.banquepopulaire.fr
[…]
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33639
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
[…]
$ dig +short @::1 www.ibps.bpaca.banquepopulaire.fr
91.135.183.174
En clair : une même version d'Unbound œuvrant sur le même réseau IP, deux comportements différents. Que j'active ou non la qname-minimisation sur mon Unbound local (sur mon accès à Internet fixe FDN, donc), ça fonctionne. Peu importe le type de qname-minimisation, souple ou stricte.
Même chose avec un BIND9.16 sur mon accès à Internet FDN : quelle que soit la configuration retenue pour la qname-minimisation (« strict » ou « relaxed »), ça fonctionne. J'ai réussi à obtenir un « SERVFAIL » en mode « relaxed », mais je n'arrive pas à le reproduire sur demande (même en redémarrant BIND, même en le stoppant+rallumant).
Dans le sens inverse, on peut exposer que le résolver de CloudFlare implémente la qname-minimisation (source) et que, justement, il ne parvient pas à résoudre les noms de la Banque Populaire sus-mentionnés.
Bref, on peut affirmer tout et son contraire.
Mais, pourquoi les sondes du réseau RIPE Atlas ne remontent-elles pas un taux d'échec de la résolution DNS plus élevé ? Concentration des serveurs DNS récursifs utilisés. Au sein d'un même réseau, celui d'Orange par exemple, tous les clients (au sens commercial du terme) vont utiliser le même serveur DNS récursif, celui d'Orange (ou celui de Google Public DNS ou celui de CloudFlare). Si le serveur DNS récursif parvient à résoudre le nom une fois, toutes les sondes Atlas situées dans ce réseau en bénéficieront le temps du TTL (durée de rétention de l'information dans le cache du serveur récursif, 30 secondes dans le cas présent). Rappelons que les serveurs DNS récursifs de certains réseaux, comme Free, sont connus pour ré-écrire les TTL jugés courts (les ignorer, donc), ce qui permet de limiter l'ampleur de l'effet "ça marche, ça marche plus, ça marche, etc.".
Les TTL courts amplifient l'aspect "ça marche, ça marche plus".
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 entre Internet et le serveur DNS qui fait autorité nsisp1.i-bp.banquepopulaire.fr qui, comme tout boîtier externalisé prétendument magique 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 bloquer certaines requêtes DNS de manière excessive (sur-blocage). Qu'est-ce qui me fait penser cela ? L'implémentation de serveur qui fait autorité est un BIND 9.11.5-P4 (dig @91.135.182.250 CH TXT version.bind
;) ). Ce logiciel refuse de charger une zone DNS dénuée de NS/SOA (« zone [CENSURE]/IN: has 0 SOA records […] zone [CENSURE]/IN: has no NS records […] zone [CENSURE]/IN: not loaded due to errors. »), donc, si l'on a des réponses, sauf pour les types NS et SOA, c'est probablement un intermédiaire entre nous et le serveur qui les vire.
Néanmoins, ça n'explique pas l'intégralité du problème. Pourquoi deux serveurs récursifs DNS avec la même version d'Unbound ne parviennent pas au même résultat ? Pourquoi la plupart des serveurs DNS récursifs de la planète parviennent à résoudre les noms de la Banque Populaire ? Les différentes implémentations de qname-minimisation amplifient-elles le problème ? Aucune idée…
La Banque Populaire est coutumière d'une configuration DNS défectueuse.
En 2015, le nom banquepopulaire.fr était délégué à deux serveurs de noms Orange Business Services (ex Oléane) qui n'étaient pas configurés pour ce nom (on nomme ça une lame delegation). Les deux autres serveurs DNS qui font autorité étaient internes au groupe BPCE et cessaient de répondre aux requêtes (UDP et TCP) au moins une fois par semaine, et notamment le dimanche matin entre 11 h et 12 h. Amusant, non ?
Comme ces derniers jours, il y avait des tweets (notamment celui-ci), mais ça n'a pas suffit. Stéphane Bortzmeyer et moi-même avons envoyé des emails à toutes les adresses BPCE pertinentes trouvées. Il a fallu deux mois avant d'avoir un acquittement (email acquitté le 24/08) et plusieurs mois pour que le problème soit corrigé…
Merci à Stéphane Bortzmeyer de m'avoir expliqué l'origine probable de cette panne partielle. L'outil dnsviz m'avait bien pointé l'absence de réponse aux requêtes de type SOA/NS de la part du serveur nsisp1.i-bp.banquepopulaire.fr , mais je ne l'ai pas interprété correctement.