Aujourd'hui, avec les mécanismes d'allocations d'adresses IP existants (cf. RFC 7020), il est relativement fréquent d'avoir à changer son adresse IP. Quelles sont les précautions particulières liées au DNS lors de ce changement ?

Le 18 février, le CEA a annoncé avoir battu un record de durée de confinement pour du plasma. Aussitôt, des dizaines de personnes ont écrit des messages techno-béats et anti-écologistes, sans prendre la mesure de ce qui avait été réalisé et de ce qui reste à faire. Petite discussion sur cette réactivité des technosolutionnistes, ces gens qui espèrent résoudre tous les problèmes de l'humanité par une invention technique spectaculaire.

Le langage JSONPath sert à désigner une partie d'un document JSON. Il est donc utile pour, par exemple, extraire des valeurs qui nous intéressent.

Un résolveur DNS ne connait au début, rien du contenu du DNS. Rien ? Pas tout à fait, il connait une liste des serveurs de noms faisant autorité pour la racine, car c'est par eux qu'il va commencer le processus de résolution de noms. Cette liste est typiquement en dur dans le code du serveur, ou bien dans un de ses fichiers de configuration. Mais peu d'administrateurs système la maintiennent à jour. Il est donc prudent, au démarrage du résolveur, de chercher une liste vraiment à jour, et c'est le priming (amorçage, comme lorsqu'on amorce une pompe pour qu'elle fonctionne seule ensuite), opération que décrit ce RFC, qui remplace l'ancienne version, le RFC 8109 (les changements sont nombreux mais sont surtout des points de détail).

Rose Valland n'est évidemment plus une inconnue. Néanmoins, son nom et son activité m'avaient échappé et c'est grâce à ce petit livre que j'ai appris son rôle, pendant et après la guerre, pour documenter les pillages d'œuvres d'art, et essayer d'en récupérer le plus grand nombre.

Plusieurs organisations françaises viennent de signer un appel (https://hiatus.ooo/) critique vis-à-vis de l'IA, dans le contexte du sommet IA du gouvernement (https://www.elysee.fr/sommet-pour-l-action-sur-l-ia). Alors que je suis en général d'accord avec ces organisations, cet appel me semble frapper à côté de la cible, car il attribue à l'IA un rôle excessif.

Le FOSDEM est sans doute le plus grand rassemblement de développeurs (et quelques développeuses) de logiciel libre en Europe. L'édition 2025, qui marquait le vingt-cinquième anniversaire de la création du FOSDEM, vient de se tenir à Bruxelles, les 1 et 2 février.

Tout le monde connait aujourd'hui l'utilisation de constellations de satellites en orbite basse pour les télécommunications et, par exemple, pour l'accès à l'Internet. Contrairement à l'ancienne technique de communication via des satellites en orbite géostationnaire, la communication directe entre satellites y joue un rôle important. Les satellites se déplacent les uns par rapport aux autres, changeant en permanence la topologie de ce réseau. Alors, comment se fait le routage ? Ce RFC décrit une méthode possible, reposant largement sur le protocole IS-IS.

Il vient d'y avoir 3 000 articles sur ce blog.

Les requêtes et réponses DNS peuvent voyager sur divers transports, mais le plus fréquent est UDP. Une réponse de grande taille sur UDP peut dépasser la MTU et donc devoir être fragmentée. La fragmentation crée divers problèmes et ce RFC décrit les problèmes, et comment éviter la fragmentation.

L'IETF utilise, pour le cœur de son travail de normalisation, l'Internet : listes de diffusion, forge de documents, outils divers de travail en groupe. Mais il y a quand même des réunions physiques, trois par an, rien ne remplaçant à 100 % le contact direct. Les discussions sur les lieux de ces réunions sont un des sujets favoris à l'IETF et ce RFC résume les règles actuelles de sélection d'un lieu. Pour savoir pourquoi il n'y a jamais eu de réunion en Inde, une seule en Chine et une seule en Amérique du Sud, lisez-le.

Le mécanisme d'authentification des informations DNS nommé DNSSEC repose sur la même structure arborescente que le DNS : une zone publie un lien sécurisé vers les clés de ses sous-zones. Un résolveur DNS validant n'a donc besoin, dans la plupart des cas, que d'une seule clé publique, celle de la racine. Elle lui servira à vérifier les clés des TLD, qui serviront à valider les clés des domaines de deuxième niveau et ainsi de suite. Reste donc à configurer la clé de la racine dans le résolveur : c'est évidemment crucial, puisque toute la sécurité du système en dépend. Si un résolveur est configuré avec une clé fausse pour la racine, toute la validation DNSSEC est menacée. Comment est-ce que l'ICANN, qui gère la clé principale de la racine, publie cette clé cruciale ? C'est documenté dans ce RFC qui remplace le RFC 7958, avec plusieurs changements, comme l'abandon des signatures PGP.

Ce RFC s'inscrit dans un projet IETF datant de quelques années : formaliser davantage les services que rend la couche Transport aux applications. Le but est de permettre de développer des applications en indiquant ce qu'on veut de la couche Transport, en rentrant le moins possible dans les détails. Ce RFC décrit l'architecture générale, le RFC 9622 spécifiant quant à lui une API plus concrète.

Voici un des RFC du projet TAPS (https://datatracker.ietf.org/wg/taps/), qui vise à proposer une vision cohérente des protocoles de transport aux applications. Ce RFC décrit (mais de manière assez abstraite) l'API de TAPS.

Vous le savez, les RFC ne sont plus en texte brut depuis des années, leur format officiel est du XML. Le système était décrit dans le RFC 7990, que ce nouveau RFC remplace. Il y a beaucoup de changements sur la forme et aussi sur le fond, notamment la possibilité de modifier un fichier déjà publié (sans changer sa sémantique, bien sûr).

Ce RFC spécifie comment on peut signer cryptographiquement et vérifier des messages HTTP, afin de s'assurer de leur authenticité. Des signatures HTTP conceptuellement proches, mais syntaxiquement différentes sont notamment utilisées par le fédivers.

Il existe tout un ensemble de normes pour assurer la sécurité de documents XML, par exemple les protéger contre la lecture non autorisée, ou bien permettre leur authentification. Ces normes dépendent d'algorithmes cryptographiques identifiés par un URI. Ce RFC met à jour la liste précédente de ces URI (qui était dans le RFC 6931) avec les nouveaux algorithmes et corrige quelques erreurs du précédent RFC.

If you use the fediverse, you know that the main bot-hosting instance, "botsin.space", closed recently. I document here one or two things about the new hosting of two bots I maintain, one answering BGP requests and one for DNS information.

I created a bot to answer DNS queries over the fediverse (decentralized social network, best known implementation being Mastodon). What for? Well, mostly for the fun, a bit to learn about Mastodon bots, and a bit because, in these times of censorship, filtering, lying DNS resolvers and so on, offering to the users a way to make DNS requests to the outside can be useful. This article is to document this project.

I created a bot to answer BGP queries over the fediverse (decentralized social network, best known implementation being Mastodon). What for? Well, mostly for the fun, but also because I need from time to time to find out the origin AS for an IP address or prefix, and I don't have a direct access to a DFZ router. This article is to document this project.