Panne du serveur DNS de NIH.gov : PubMed, BLAST et d’autres services inaccessibles [rétabli]

 (nslookup.io)
1 points par GN⁺ 2025-03-03 | 1 commentaires | Partager sur WhatsApp
  • En raison d’une panne du serveur DNS de NIH.gov, PubMed, BLAST et d’autres services étaient inaccessibles, et le titre sur HN indique que l’état est désormais rétabli
  • La page fournie n’est pas un rapport d’incident mais l’écran de résultat d’une requête DNS pour www.nih.gov, avec des onglets de consultation Cloudflare, Google DNS et Authoritative
  • Le serveur DNS de Cloudflare a répondu avec les enregistrements DNS de ce domaine et a fourni les enregistrements mis en cache jusqu’à l’expiration du TTL
  • Après l’expiration du TTL, Cloudflare actualise son cache en interrogeant l’un des authoritative name servers
  • Le contenu ne fournit ni l’heure de l’incident, ni sa cause, ni les valeurs réelles des enregistrements DNS, ni l’état individuel de PubMed et BLAST, ce qui limite l’évaluation précise de l’ampleur de la panne

Informations vérifiables sur la panne

  • Le titre sur HN indique qu’en raison d’une panne du serveur DNS de NIH.gov, PubMed, BLAST et d’autres services étaient inaccessibles, et que la situation est maintenant rétablie
  • Le contenu fourni n’est pas un rapport d’incident mais un écran de consultation DNS concernant www.nih.gov
  • Le contenu seul ne permet pas de vérifier les informations suivantes
    • heure de début et de rétablissement de la panne
    • cause de la panne
    • liste détaillée des services affectés
    • valeurs réelles des enregistrements DNS
    • détails des réponses des serveurs autoritatifs

Composition de l’écran de consultation Nslookup.io

  • La requête porte sur www.nih.gov
  • L’écran propose les sources de requête DNS suivantes sous forme d’onglets
    • Cloudflare
    • Google DNS
    • Authoritative
  • Le serveur DNS de Cloudflare a répondu avec des enregistrements DNS et les fournit jusqu’à l’expiration du TTL
  • Lorsque le TTL expire, Cloudflare actualise son cache en interrogeant l’un des authoritative name servers
  • La page inclut aussi une présentation de la fonction DNS lookup permettant de consulter les enregistrements DNS d’autres domaines ou sous-domaines

À lire aussi

1 commentaires

 
GN⁺ 2025-03-03
Avis sur Hacker News
  • La résolution DNS semble fonctionner à nouveau : https://dnschecker.org/#A/pubmed.ncbi.nlm.nih.gov
  • Il a été confirmé que ces serveurs répondent toujours en TCP : https://mstdn.social/@rysiek/114089755401568345 https://lists.dns-oarc.net/pipermail/dns-operations/2025-Mar...
    Le service est partiellement en vie, mais pas vraiment dans un état utile ; il est donc difficile, depuis l’extérieur, de déterminer exactement ce qui se passe
    • Il s’agit presque certainement d’une erreur de configuration du pare-feu. Un acteur malveillant ne se serait probablement pas contenté de bloquer uniquement l’UDP
    • Pour cette raison, il semble bien plus probable que quelqu’un ait cassé une configuration de serveur ou de pare-feu, plutôt que Musk soit en train de débrancher des câbles réseau au NIH
    • PubMed est l’un des services les plus stables de l’histoire d’Internet. Même si la cause exacte reste obscure, cela donne l’impression que quand la tête pourrit, le reste suit
  • Pour les scientifiques, PubMed est pratiquement l’équivalent de Google. Quand on cherche des articles scientifiques, on utilise généralement PubMed ; il existe des alternatives, mais jusqu’ici il n’était pas vraiment nécessaire de les connaître
    Tout le monde utilisait PubMed, et la plupart des scientifiques européens ne connaissaient probablement pas d’alternatives régionales jusqu’à maintenant. Le NIH fournit aux scientifiques bien plus de fonctionnalités que cela
    • J’utilise très peu PubMed ; pour la recherche en neurosciences, médecine et informatique, j’utilise Google Scholar tous les jours. Cela dit, je reconnais que tous les chercheurs en médecine que je connais n’utilisent que PubMed
  • La base de données de la FAA servant au suivi des enquêtes sur les accidents semble aussi être tombée, et il y a probablement pas mal d’autres systèmes peu connus du grand public dont diverses organisations dépendent
    Si c’était une cyberattaque chinoise, ce serait un scandale pour les dix prochaines années ; mais cette fois, cela ressemble à quelque chose de délibéré
  • Techniquement, NIH.gov dispose de trois serveurs de noms ; chaque hôte est en ligne, mais pour le DNS ils ne répondent qu’en TCP, pas en UDP
    Les trois sont dans le même AS, ce qui laisse penser qu’un opérateur unique en est responsable, et il n’y a pas d’IPv6. Vu de l’extérieur, rien n’indique non plus que les serveurs ou le service aient été délégués à une société externe
    En cherchant davantage, il semble que le NIH dispose d’un service/groupe/organisme appelé Center for Information Technology, qui fait office d’organisation de support IT du NIH et semble exploiter ces serveurs DNS
    • Je vais peut-être le regretter plus tard, mais je l’ai été, il y a longtemps, manager de l’équipe qui exploitait ce pare-feu de périmètre et ces serveurs DNS au sein du NIH/CIT. Plus précisément, c’était alors NIH/CIT/DNST/NEB/NSS
      Je n’y suis plus, donc je n’ai pas d’informations internes ; mais comme, pendant l’incident, les serveurs DNS répondaient en TCP et pas en UDP, je parierais plutôt sur une simple erreur de pare-feu que sur une intention malveillante
      Ce genre de chose arrive. Une maintenance peut avoir des conséquences imprévues, et les humains font des fautes de frappe. Il vaut mieux ne pas surréagir à chaque incident et garder son énergie pour les vraies raisons de s’indigner, par exemple 18F
    • À noter que les serveurs de noms lhcns1.nlm.nih.gov (130.14.55.72) et lhcns2.nlm.nih.gov (130.14.55.128) résolvent toujours le sous-domaine nlm.nih.gov
  • Pour référence, BLAST signifie Basic Local Alignment Search Tool, un outil très utilisé dans la boîte à outils de bio-informatique. On « BLAST » une séquence en envoyant une séquence requête d’intérêt vers d’autres bases de données de séquences afin de trouver des résultats similaires
    • Cela fait un moment que j’ai quitté ce domaine, donc je ne sais pas très bien à quel point BLAST est utilisé aujourd’hui
      À une époque, passer une séquence d’ADN ou de protéine dans BLAST revenait un peu à faire une recherche Google sur cette séquence, parce que cela indiquait d’où elle pouvait venir
      C’était particulièrement utile si le sujet de recherche consistait à comprendre ce que faisait une séquence donnée. Cela ne donnait pas directement la réponse, mais les similarités de séquence suggèrent souvent des fonctions semblables ou liées et fournissent du contexte
      Pour donner une analogie, imaginez que StackOverflow tombe soudainement, sans même savoir s’il reviendra un jour
  • Alternatives européennes :
    https://europepmc.org/
    https://www.ebi.ac.uk/ena/browser/home
    https://www.ensembl.org/
    • C’était agréable de voir la coopération européenne en génomique et biotech. L’écosystème danois est clairement une référence, une sorte d’étoile polaire
      Cela dit, BLAST semble être en ligne [0]
      [0] - https://blast.ncbi.nlm.nih.gov/Blast.cgi
  • Il est possible que les serveurs DNS aient été temporairement indisponibles. Par exemple, le NIH est peut-être en maintenance, mais cela ne rend pas forcément le site web inaccessible
    Le « unreachable » du titre est peut-être une expression figurée. Je n’ai aucun problème à accéder à ces sites web, et je peux fournir les IP à ceux qui en ont besoin
    Exemples :
    www.nih.gov 23.41.4.71 (Akamai)
    www.nih.gov 2.22.31.155 (Akamai)
    www.nih.gov 60.254.143.7 (Akamai)
    www.nih.gov 95.101.74.96 (Akamai)
    www.nih.gov 88.221.24.17 (Akamai)
    www.nih.gov 184.51.148.226 (Akamai)
    www.nih.gov 54.235.145.223 (Amazon)
    pubmed.ncbi.nlm.nih.gov 34.107.134.59 (Google)
    blast.ncbi.nlm.nih.gov 130.14.29.110
    Exemple d’utilisation :
    echo 130.14.29.110 blast.ncbi.nlm.nih.gov|busybox sed -i -e 1r/dev/stdin -e1N /etc/hosts

echo 34.107.134.59 pubmed.ncbi.nlm.nih.gov|busybox sed -i -e 1/r/dev/stdin -e1N /etc/hosts

  • Même dans le nord de l’État de New York, le site principal de PubMed fonctionne bien : https://pubmed.ncbi.nlm.nih.gov/
    Les pages du NIH/NSF tombent périodiquement, que ce soit pour maintenance ou pour une autre raison, et cela arrive généralement le week-end. La réaction de la communauté HN me semble un peu précipitée. Je lis HN depuis environ 2008, et j’ai l’impression que la qualité des commentaires n’est plus ce qu’elle était
  • 130.14.29.110 me redirige vers https://www.ncbi.nlm.nih.gov/, mais ce site est inaccessible
    23.41.4.71 affiche le message suivant
    "Invalid URL
    The requested URL "[no URL]", is invalid.
    Reference #9.47532217.1740935192.27b71986
    https://errors.edgesuite.net/9.47532217.1740935192.27b71986"
  • Je n’arrive toujours pas à accéder à BLAST. Est-ce qu’il suffit de saisir 130.14.29.110 dans un navigateur web ?
  • Pour info, la situation durait déjà depuis au moins 16 heures. Hier soir, j’ai aussi essayé d’y lire quelque chose, mais ça ne fonctionnait pas
    J’espère qu’il existe une sauvegarde quelque part. À ce stade, je pense que je n’aurais absolument aucun scrupule à utiliser des sources non approuvées
  • On dirait que quelqu’un a éteint tous les serveurs DNS du NIH. Actuellement, le site web du NIH, PubMed et BLAST sont bien en ligne, mais la résolution de noms ne fonctionne pas
    Le résolveur DNS 1.0.0.1 de Cloudflare semble encore avoir les enregistrements en cache. Google et la plupart des autres résolveurs que j’ai essayés ne les avaient pas. C’est probablement pour cela que, sur les réseaux sociaux, certains disent pouvoir accéder aux sites et d’autres non
    Contournement via /etc/hosts :
    156.40.212.210 nih.gov
    96.17.96.9 www.nih.gov
    34.107.134.59 pubmed.ncbi.nlm.nih.gov
    130.14.250.10 ftp.wip.ncbi.nlm.nih.gov
    130.14.250.10 ftp.ncbi.nlm.nih.gov
    130.14.29.110 blast.ncbi.nlm.nih.gov
    Modification :
    ns.nih.gov, ns2.nih.gov et ns3.nih.gov ne répondent pas, mais le serveur de noms lhcns1.nlm.nih.gov (130.14.55.72) répond
    À voir aussi : https://tldr.nettime.org/@ww/114089972404202687
    • Ils ne sont pas éteints. On peut le vérifier directement :
      dig +tcp @$(dig +short ns.nih.gov @a.ns.gov) www.nih.gov
    • Si ce n’est pas résolu avant lundi, cette information pourrait devenir importante. J’espère seulement que ce n’est pas intentionnel