Les objets connectés, vous le savez, sont une source d'ennuis et de risques de sécurité sans fin. Non seulement ils ne sont pas forcément utiles (faut-il vraiment connecter une brosse à dents au réseau ?) mais en outre, comme ils incluent un ordinateur complet, ils peuvent faire des choses auxquelles l'acheteur ne s'attend pas. Pour limiter un peu les risques, le RFC 8520 normalisait MUD (Manufacturer Usage Description), un mécanisme pour que le fournisseur du machin connecté documente sous un format analysable les accès au réseau dont l'objet avait besoin ce qui permet, par exemple, de configurer automatiquement un pare-feu, qui va s'assurer que la brosse à dents ne se connecte pas (https://www.ietf.org/blog/mud/) à Pornhub. Dans un fichier MUD, les services avec lesquels l'objet communique sont typiquement indiqués par un nom de domaine. Mais le DNS a quelques subtilités qui font que l'utilisation de ces noms nécessite quelques précautions, décrites dans ce nouveau RFC.

Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau avant qu'il ne tente de se connecter à un serveur. On peut envoyer ainsi des indications sur les versions des protocoles gérées, des clés cryptographiques ou des noms de serveurs supplémentaires.

Dans les discussions au sujet du réseau Internet, on voit souvent passer des demandes sur l'AS associé à une adresse IP ou bien le contraire. Mais les questions simples du genre « de quel AS dépend une adresse IP ? » sont… trop simples.

On 15 and 16 March 2025, I was at the DNS hackathon 2025 (https://labs.ripe.net/author/becha/join-the-dns-hackathon-2025/) in Stockholm, organised by RIPE NCC, DNS-OARC (https://www.dns-oarc.net/) and Netnod. I worked on a mechanism to synchronize the caches of DNS resolvers.

Dans le contexte de la surveillance massive qui s'exerce contre les utilisateurices de l'Internet, tout identifiant un peu stable peut être utilisé pour pister quelqu'un. On en laisse, des traces ! C'est par exemple le cas avec l'adresse MAC. Ce nouveau RFC décrit les mécanismes existants pour diminuer le risque de pistage par l'adresse MAC. Il ne spécifie pas un protocole, il liste les solutions.

Vous savez que les types de médias comportent un type de premier niveau et un sous-type. Dans "image/gif", "image" est le type de premier niveau et "gif" le sous-type. On crée des sous-types tout le temps mais les types, l'identificateur qui est au premier niveau, c'est bien plus rare. La création du type "haptics (https://www.iana.org/assignments/media-types/media-types.xml#haptics)" (données haptiques), qui a été faite dans le RFC 9695, a été l'occasion de formaliser un peu plus le processus de création de types de médias.

L'enregistrement d'un nouveau type de média de premier niveau est plutôt rare (le dernier avait été "font/" en 2017). Notre RFC introduit le type "haptics/", pour les formats de fichier des interfaces haptiques, celles qu'on touche et qui vous touchent (une manette de jeu vidéo à retour d'effort, par exemple).

Successeur du RFC 6855, voici la normalisation de la gestion d'Unicode par le protocole IMAP (dans sa version 4rev1) d'accès aux boîtes aux lettres.

Ce nouveau champ de l'en-tête HTTP sert à indiquer que la ressource demande va être (ou a été) abandonné et qu'il faut penser à migrer. Il sert surtout pour les API HTTP.

La lutte contre la congestion du réseau est une tâche permanente des algorithmes utilisés dans l'Internet. Si les émetteurs de données envoyaient des octets aussi vite qu'ils le pouvaient, sans jamais réfléchir, l'Internet s'écroulerait vite. Des protocoles comme TCP ou QUIC contiennent donc des algorithmes de contrôle de la congestion. Il y en a plusieurs, certains peuvent être néfastes, et ce RFC, qui remplace le RFC 5033, explique comment de nouveaux algorithmes doivent être évalués avant d'être déployés en vrai. Bref, la prudence est nécessaire.

Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un certificat comprenant ce nom. Ce court RFC spécifie une extension à ACME qui permet de prouver la « possession » d'une adresse IP, ce qui permettra d'obtenir via ACME des certificats utilisant une adresse.

Le langage CDDL, qui permet de créer un schéma formel pour des formats comme CBOR, peut s'étendre via l'ajout d'« opérateurs de contrôle ». Ce RFC en spécifie quelques uns, notamment pour agir sur du texte ou convertir d'une forme dans une autre.

Peut-être, dans le futur, nous aurons un Internet quantique, où les communications utiliseront à fond les surprenantes propriétés de la physique quantique. Ce RFC se penche sur les applications que cela pourrait avoir, et les utilisations possibles.

Un nouvel en-tête HTTP (et un nouveau type de lien) fait son apparition avec ce RFC : "Sunset:" (coucher de soleil) sert à indiquer la date où la ressource Web cessera probablement d'être servie. Le but est, lorsque le webmestre sait à l'avance qu'il retirera une ressource, de prévenir les utilisateurs.

L'Internet est aujourd'hui un service indispensable à toutes les activités humaines. Un accès correct à ce réseau est donc crucial. Mais plusieurs problèmes limitent l'accès à l'Internet ou à plusieurs de ses services. L'IAB avait organisé en janvier 2024 un atelier sur cette question, atelier dont ce RFC est le compte-rendu.

Alain Aspect raconte dans ce livre l'histoire des expériences qu'il a menées dans les années 1970-1980 et qui ont prouvé la violation des inégalités de Bell (en termes journalistiques « prouvé qu'Einstein avait tort »). Attention, il faut s'accrocher, mais c'est très bien décrit.

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. (Notez que le RFC, délibérément, ne spécifie pas un protocole complet mais une des briques, qui devra impérativement être complétée avec d'autres règles.)

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.