www.bortzmeyer.org
Open in
urlscan Pro
2602:fbb1:1:245b::42
Public Scan
Submitted URL: http://bortzmeyer.org/
Effective URL: https://www.bortzmeyer.org/
Submission: On May 02 via api from US — Scanned from FR
Effective URL: https://www.bortzmeyer.org/
Submission: On May 02 via api from US — Scanned from FR
Form analysis 1 forms found in the DOM
/search
<form action="/search">
<p><label for="pattern">Recherche dans ce blog : </label><input type="text" name="pattern" id="pattern">
</p>
</form>Text Content
MON BLOG
--------------------------------------------------------------------------------
AUTRES TRUCS
Accueil
Seulement les RFC
Seulement les fiches de lecture
Mon livre « Cyberstructure »
Ève
Recherche dans ce blog :
Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de
tous des petits textes que j'écris. On y parle surtout d'informatique mais
d'autres sujets apparaissent parfois.
--------------------------------------------------------------------------------
EXPOSÉ « NORMALISATION TECHNIQUE, QUI DÉCIDE ? » AUX JOURNÉES FEDEREZ
Première rédaction de cet article le 29 avril 2024
--------------------------------------------------------------------------------
FedeRez est la fédération nationale des associations d'étudiants qui gèrent des
réseaux informatiques. Elle tient des journées annuelles et, à celles de 2024
dans un endroit éloigné de tout transport en commun, j'ai fait un exposé sur le
thème « Normalisation technique, qui décide ? ».
Voici les transparents de mon exposé :
* Format adapté à l'écran,
* Format adapté à l'impression,
* Source (LaTeX/Beamer),
L'enregistrement vidéo n'est pas encore disponible.
L'article seul
--------------------------------------------------------------------------------
RFC 9557: DATE AND TIME ON THE INTERNET: TIMESTAMPS WITH ADDITIONAL INFORMATION
Date de publication du RFC : Avril 2024
Auteur(s) du RFC : U. Sharma (Igalia, S.L.), C. Bormann (Universität Bremen TZI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF sedate
Première rédaction de cet article le 29 avril 2024
--------------------------------------------------------------------------------
Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339,
changeant à la marge une définition et, surtout, permettant d'y attacher des
informations supplémentaires.
Le RFC 3339 décrit un des formats d'estampilles temporelles possibles sur
l'Internet (car, malheureusement, toutes les normes Internet ne l'utilisent
pas). Un exemple, sur Unix :
% date --rfc-3339=seconds
2024-04-29 06:22:33+00:00
Le format du RFC 3339 est du type « YYYY-MM-DD HH:MM:SS » avec, à la fin, ajout
d'une information sur le décalage avec le temps de référence (on verra que notre
nouveau RFC 9557 change un peu cette dernière information). Un format gros
boutien, donc, qui permet notamment de trier les dates-et-heures uniquement en
suivant l'ordre lexicographique des caractères.
Mais certaines applications voudraient en savoir plus, et ajouter à ce format
des détails. D'ailleurs, c'est déjà fait dans des solutions non normalisées,
comme le format de Java, très populaire, qui permet des estampilles comme
2011-12-03T10:15:30+01:00[Europe/Paris] (fuseau horaire, ajouté après la date au
format du RFC 3339 ; lisez le RFC 6557 pour en savoir davantage sur les fuseaux
horaires).
Ce nouveau RFC prévoit donc une extension optionnelle (les dates-et-heures qui
suivaient le format de l'ancien RFC restent parfaitement valdies), compatible
avec celle de Java, et généraliste (on pourra indiquer autre chose que le fuseau
horaire). Ce format étendu est baptisé IXDTF pour Internet Extended Date/Time
Format. En revanche, le nouveau format ne gère pas des cas compliqués (la
gestion du temps en informatique est toujours compliquée) come les dates futures
lorque la définition du fuseau horaire changera, par exemple en supprimant
l'heure d'été, ou des échelles de temps différentes, comme TAI (le format IXDTF
ne marche que pour l'échelle d'UTC).
Donc, concrètement, notre RFC commence par changer un peu la définition du
décalage à la fin des estampilles. Dans le RFC 3339, il y avait trois cas
subtilement différents pour une estampille indiquant l'absence de décalage :
* Une lettre Z indiquait qu'on utilisait UTC comme référence,
* Un +00:00 indiquait qu'on utilisait UTC comme référence (identique au cas
précédent),
* Un -00:00 indiquait qu'on n'avait aucune idée sur la référence (typiquement
parce qu'on voudrait connaitre l'heure locale mais qu'on ne la connait pas).
(Au passage, si vous ne connaissiez pas ces trois cas et leurs différences, ne
vous inquiétez pas, vous n'étiez pas seul·e.) Notre RFC change cela (section 2)
en décidant que Z est désormais synonyme de -00:00 plutôt que de +00:00, un
changement qui aura sans doute peu d'importance en pratique.
L'autre nouveauté de ce RFC 9557 est plus marquante, c'est le format étendu
IXDTF (section 3). Il consiste à ajouter à la fin de l'estampille une série
(facultative) de couples {clé, valeur}, entre crochets. Si la clé est absente,
c'est que la valeur est un fuseau horaire, suivant la syntaxe de la base TZ.
Voici un exemple :
2022-07-08T12:14:37+02:00[Europe/Paris][u-ca=hebrew]
Cet exemple indique que le fuseau horaire était celui de Paris (cf. le format de
ces noms de fuseaux) et que le calendrier préféré (clé u-ca), pour afficher
cette date, serait le calendrier hébreu (ce qui indiquera 9 Tammouz 5782, sauf
erreur).
Un point d'exclamation avant la clé indiquerait que la clé doit être comprise
par le lecteur, sinon, il faut qu'il ignore l'estampille temporelle (la plupart
du temps, l'application peut ignorer les clés et leurs valeurs). Un trait bas
indique une clé expérimentale, non officiellement enregistrée.
Car notre RFC crée aussi un registre des clés. Pour l'instant, il ne compte
qu'une seule clé, u-ca, pour indiquer le calendrier préféré. Pour enregistrer
une nouvelle clé, il faut une spécification écrite (cf. RFC 8126), mais il y a
aussi des enregistrements temporaires, plus légers.
Et on termine par un petit mot sur la sécurité (section 7). Le RFC rappelle que
plus on donne d'informations, plus on risque d'en donner trop. Ainsi,
l'indication du calendrier préféré peut indiquer une origine ethnique ou
religieuse, qui peut être considérée comme privée, surtout s'il y a des risques
d'attaques racistes.
--------------------------------------------------------------------------------
Téléchargez le RFC 9557
L'article seul
--------------------------------------------------------------------------------
RFC 9567: DNS ERROR REPORTING
Date de publication du RFC : Avril 2024
Auteur(s) du RFC : R. Arends (ICANN), M. Larson (ICANN)
Chemin des normes
Première rédaction de cet article le 27 avril 2024
--------------------------------------------------------------------------------
Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de
résoudre les noms dans cette zone, il n'avait pas de moyen simple et automatique
de prévenir les gérants des serveurs faisant autorité pour cette zone. Leur
envoyer un message en utilisant l'information dans l'enregistrement SOA ou les
adresses classiques du RFC 2142 ? Mais, justement, si la zone ne marche pas, le
courrier ne partira pas forcément. Ce nouveau RFC propose un nouveau système.
Les serveurs faisant autorité annoncent un domaine (qui marche, espérons-le),
qui acceptera des requêtes DNS spéciales signalant le problème.
Cela dépend évidemment du problème pratique qui se pose. Si la zone n'a aucun
serveur faisant autorité qui marche, il n'y a évidemment rien à faire. Mais
s'ils marchent, tout en servant des données problématiques (par exemple des
signatures DNSSEC expirées), alors, le résolveur pourra agir. Les serveurs
faisant autorité mettent dans leurs réponses une option EDNS qui indique le
domaine qui recevra les rapports (cela doit être un autre domaine, qui n'a pas
de problème), le résolveur fera alors une requête DNS se terminant par le nom du
domaine de signalement, et encodant le problème. L'agent, le domaine de
signalement, pourra alors récolter ces requêtes et savoir qu'il y a un problème.
Cela ne traite pas tous les cas (il faudra toujours utiliser RDAP ou whois pour
récolter des informations sur les contacts du domaine erroné, puis leur écrire
depuis un autre réseau) mais c'est simple, léger et automatisable. Les gérants
de domaine sérieux, qui prennent au sérieux les signalements de problèmes
techniques (soit 0,00001 % des domaines) pourront alors agir. (Note si vous
gérez un résolveur et que vous constatez un problème avec un domaine et que les
contacts ne répondent pas : un message méchant sur Twitter est souvent plus
efficace.)
Donc, les détails techniques : le domaine qui veut recevoir les éventuels
signalements va devoir configurer ses serveurs faisant autorité pour renvoyer
une option EDNS, de numéro 18 (section 5 du RFC), indiquant l'agent,
c'est-à-dire le domaine qui va recevoir les signalements (il faut évidemment
veiller à ce qu'il n'ait pas de point de défaillance commun avec le domaine
surveillé). Notez que cette option est systématiquement envoyée, le client (le
résolveur) n'a pas à dire quoi que ce soit (la question avait fait l'objet d'un
sérieux débat à l'IETF).
En cas de problème, notamment DNSSEC, le résolveur qui a noté le problème va
alors construire un nom de domaine formé, successivement (section 6.1.1) par :
* Le composant _er,
* Le type de données qui posait problème (adresse IP, enregistrement de
service, etc),
* Le nom de domaine qui était initialement demandé par le résolveur,
* L'erreur étendue (EDE, RFC 8914),
* Le composant _er (oui, encore),
* Le nom de domaine de l'agent.
Par exemple, si le domaine dyn.bortzmeyer.fr annonce comme agent
report.dyn.sources.org, et qu'un résolveur découvre des signatures DNSSEC
expirées (EDE 7) en cherchant à résoudre hello.dyn.bortzmeyer.fr / TXT (TXT a la
valeur 16), la requête de signalement du résolveur sera
_er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org (ouf). Le type
demandé est TXT. Lorsque cette requête arrivera au serveur faisant autorité pour
report.dyn.sources.org, il pourra enregistrer qu'il y a eu un problème, et
mettre cette information à la disposition de son administrateur système.
Ce serveur faisant autorité est censé répondre au signalement avec une réponse
de type TXT comme ici :
% dig _er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org TXT
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12032
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
_er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org. 30 IN TXT "Thanks for the report of error 7 on hello.dyn.bortzmeyer.fr"
…
L'agent peut ensuite être interrogé, par des méthodes propres à la mise en œuvre
utilisée :
% echo report | socat - UNIX-CONNECT:/home/drink/drink.sock
REPORT state:
hello.dyn.bortzmeyer.fr, 7
ip.dyn.bortzmeyer.fr, 7
Ici, on voit que deux domaines ont été signalés comme ayant des signatures
expirées (rassurez-vous, c'était juste des tests). Le nombre de signalements
n'est pas indiqué, ni la source des signalements (travail futur).
Quelques petits points de sécurité à garder en tête (section 9 du RFC) :
* Le fait de signaler va, par définition, donner au serveur faisant autorité
des informations sur le résolveur (par exemple, un résolveur menteur qui
signalerait les blocages informerait sur sa politique, ce que les censeurs ne
font en général pas).
* Il en donnera aussi aux serveurs des zones parentes du domaine agent, et il
est donc très recommandé de minimiser le nom (RFC 9156).
* Il n'y a pas spécialement d'authentification donc tous ces rapports doivent
être traités avec prudence. Un méchant peut facilement fabriquer de faux
rapports, de toute façon. Ils doivent donc toujours être vérifiés.
Cette technique a été mise en œuvre dans Drink lors d'un hackathon IETF. Drink
peut à la fois signaler un domaine agent, et être serveur pour un domaine agent.
Un exemple de signalisation EDNS de cette option, vu la version de développement
de Wireshark (merci à Alexis La Goutte) :
--------------------------------------------------------------------------------
Téléchargez le RFC 9567
L'article seul
--------------------------------------------------------------------------------
RFC 9547: REPORT FROM THE IAB WORKSHOP ON ENVIRONMENTAL IMPACT OF INTERNET
APPLICATIONS AND SYSTEMS, 2022
Date de publication du RFC : Février 2024
Auteur(s) du RFC : J. Arkko, C. S. Perkins, S. Krishnan
Pour information
Première rédaction de cet article le 24 avril 2024
--------------------------------------------------------------------------------
La question de l'empreinte environnementale du numérique suscite beaucoup de
débats. L'IAB avait organisé en décembre 2022 un atelier sur le cas de
l'empreinte environnementale de l'Internet dont ce RFC est le compte-rendu
(tardif, oui, je sais, mais mon propre article de résumé du RFC est aussi en
retard).
Le sujet est très complexe, relativement nouveau, et surtout noyé sous beaucoup
d'approximations, voire de franches bêtises (l'ADEME s'en est fait une
spécialité, avec des chiffres tirés du chapeau et à la méthodologie inconnue).
Il y a donc du travail sur la planche. L'IAB commence par estimer que l'Internet
a certes une empreinte environnementale mais peut aussi servir à diminuer
l'empreinte environnementale globale, ce qui n'est franchement pas étayé (le RFC
cite l'exemple de réunions physiques remplacées par des réunions en ligne, sans
citer de calcul détaillé qui permettrait de voir s'il y a vraiment un gain, et
en oubliant que de toute façon une réunion en ligne ne rend pas les mêmes
services). Mais l'IAB note aussi que l'Internet a des effets indirects, et pas
forcément positifs : il cite l'exemple de l'augmentation de la consommation de
biens matériels que produit le commerce en ligne.
Clairement, l'Internet n'est pas virtuel, contrairement à ce que prétend le
marketing qui abuse de termes comme cloud pour faire croire que le numérique est
immatériel. A contrario, l'Internet dépend de machines, de l'électricité (et des
humains qui font fonctionner ces machines). Que peut-on faire pour diminuer
l'empreinte environnementale de l'Internet ? (Sans pour autant suivre les
conseils débiles de l'ADEME, comme de supprimer ses messages.)
Comme tous les ateliers de l'IAB, celui-ci a fonctionné en demandant aux
participants des position papers expliquant leur point de vue. Ne participent à
l'atelier que des gens ayant écrit un de ces articles, ce qui garantit que tout
le monde a dû travailler le sujet. Ces articles sont disponibles en ligne, plus
exactement à cet endroit. (Tous les documents liés à cet atelier sont également
disponibles.) Parmi les papiers acceptés :
* « Extending IPv6 to support Carbon Aware Networking », où comment rendre les
équipements réseau plus conscients des conséquences environnementales,
* « Frugal Computing », sur la sobriété numérique,
* « Internet Infrastructure and Climate Justice », qui se focalise davantage
sur l'aspect politique (il y a d'autres prises de position de l'auteure, et
une collection de liens utiles),
* Et de nombreux autres, souvent très intéressants.
La section 2 du RFC détaille les sujets qui étaient dans le programme de
l'atelier :
* Les impacts environnementaux directs de l'Internet (consommation électrique
des machines, des routeurs aux serveurs en passant par les machines
terminales, refroidissement, fabrication des machines, et leur traitement
final, souvent oublié dans les études),
* Les impacts indirects de l'Internet, provenant des effets qu'il a sur la
société,
* Les métriques (souvent très maltraitées dans les artcles parlant de
l'empreinte environnementale du numérique, par exemple en confondant énergie
et puissance), un sujet crucial puisqu'on ne peut pas améliorer ce qu'on ne
peut pas mesurer,
* Les questions non techniques, comme les enjeux financiers ou comme la
régulation,
* Les questions techniques où l'IETF pourrait travailler pour améliorer les
choses (par exemple, mais non cité par le RFC, annoncer dans les réponses
HTTP le coût environnemental de la requête),
* Mais aussi les questions liées aux usages et aux utilisateurices, qui sont
souvent sollicités, mais en général de manière culpabilisatrice (« regardez
les vidéos en basse définition et pas de porno »).
Ah et, si vous vous le demandez, l'atelier a été entièrement en ligne (section
2.1 du RFC).
La première des quatre sessions de l'atelier essayait d'aborder le problème de
manière générale. Le problème du réchauffement climatique est évidemment bien
plus vaste que l'Internet seul et n'a pas de solution simple et unique. Et les
solutions ne sont pas toutes techniques, donc il y a des limites à ce que l'IETF
peut faire (ce qui ne veut pas dire qu'il ne faut rien faire !). Même la
publicité est mentionnée dans cette section du RFC, avec un très prudent
« davantage d'études sont nécessaires » (opinion personnelle : son attitude au
sujet de la publicité est un bon moyen de savoir si votre interlocuteur veut
sérieusement lutter contre le réchauffement climatique, ou bien s'il veut juste
faire des discours).
Ensuite, deuxième session sur les mesures et la récolte des faits. Par exemple,
où sont les gros postes de consommation électrique dans le numérique ? Les
serveurs ? Les routeurs ? Les terminaux ? C'est d'autant plus important que le
RFC note la quantité de fausses informations qui circulent (citant par exemple
un article qui confondait MB/s et Mb/s, soit un facteur 8 de différence). De
même, contrairement à ce qui est encore souvent dit, la session a mis en
évidence le fait que la consommation électrique n'est pas du tout
proportionnelle au trafic. Des phrases comme « envoyer un courrier dégage autant
de dioxyde de carbone qu'un vol Paris-Quelquepart » n'ont donc aucun sens. (Un
des papiers acceptés, « Towards a power-proportional Internet » expliquait
pourquoi il fallait changer cela et comment le faire.) Par contre, les usages
impactent la consommation car ils peuvent nécessiter des mises à jour du réseau.
La troisième session regardait du côté des pistes d'amélioration, plus
précisement de celles sur lesquelles l'IETF pouvait agir. Le premier point est
celui des mesures (insuffisantes et parfois contradictoires). Le deuxième point
concernait l'influence de phénomènes comme la gigue (RFC 4689) ou l'élongation
du trajet (RFC 7980) sur la consommation énergétique (si on réduit ces
phénomènes grâce à de meilleurs protocoles, est-ce qu'on diminue la
consommation ?). Parmi les autres optimisations possibles, le choix de meilleurs
formats, plus optimisés (CBOR - RFC 8949 - est cité). Notez qu'un des articles
acceptés pour l'atelier faisait le point sur toutes les activités de l'IETF
liées à l'énergie, draft-eckert-ietf-and-energy-overview.
Et la quatrième et dernière session portait sur les étapes suivantes du
travail ; en résumé, il y a du travail et, même si l'IETF ne peut pas tout, elle
doit en prendre sa part. Il faut toujours garder en tête que le but n'est pas de
réduire l'empreinte environnementale de l'Internet mais de réduire celle de
l'ensemble de la société. Éteindre l'Internet diminuerait certainement son
empreinte environnementale mais pourrait avoir des effets négatifs sur d'autres
secteurs, comme les transports. Pour améliorer l'Internet sans le supprimer,
plusieurs axes ont été mis en avant :
* Mesurer, toujours mesurer, on manque d'informations,
* Pouvoir diminuer la consommation quand il n'y a pas de travail en cours,
voire hiberner, serait utile (comme dans beaucoup de cas, le problème est
complexe : un routeur ne peut pas hiberner car il ne sait pas quand arrivera
le prochain paquet, et il ne peut pas se réveiller instantanément),
* Adopter de meilleurs formats de données. Comme le disait un des articles
présentés, « CBOR est plus vert ».
Et les actions concrètes (section 2.4.3) ?
* Faut-il imposer dans chaque RFC une section Environmental considerations
comme il y a déjà une Security considerations obligatoire ? (La question
s'était déjà posée pour une éventuelle Human rights considerations.) Pour
l'instant, ce n'est pas prévu notamment parce que, dans l'état actuel des
choses, la plupart des auteurs de RFC n'ont pas de connaissances suffisamment
approfondies ur le sujet pour écrire une section utile.
* Plusieurs groupes à l'IETF sont déjà au travail sur ce sujet
environnemental : NMRG travaille sur les métriques (et a, par exemple, un
Internet-Draft « Challenges and Opportunities in Management for Green
Networking »), même chose à OPSAWG et le nouveau groupe TVR (Time-Variant
Routing), comme il travaille sur le routage intermittent, a également un
rôle, par exemple lorsqu'on coupe des liens pour économiser de l'énergie. Là,
on est pile dans le rôle de l'IETF.
* Curieusement, le RFC parle aussi d'éviter les NFT, qui ne sont pourtant plus
guère à la mode (et n'ont jamais suscité beaucoup d'intérêt à l'IETF, de
toute façon). En outre, la plupart d'entre eux tournent sur Ethereum, qui
n'utilise plus la preuve de travail et n'est donc pas crucial du point de vue
environnemental.
Si vous voulez participer au nouveau programme de l'IAB E-IMPACT, tout est là.
Puisqu'on parlait de la section sur la sécurité qui est obligatoire dans les
RFC, notre RFC en a une, qui rappelle que :
* Tout mécanisme par lequel on donne des pénalités (financières ou bien en
terme de diminution des ressources allouées) en fonction de métriques
d'empreinte environnementale doit se préparer à ce qu'il y ait des tricheurs
(cf. P. McDaniel, « Sustainability is a Security Problem », à la conférence
SIGSAC en 2022), qui faussent les mesures pour échapper à ces pénalités.
* De même, tout mécanisme qui va agir sur le réseau, par exemple pour diminuer
l'empreinte environnementale, peut être détourné pour une attaque par déni de
service, et doit donc prévoir le problème.
--------------------------------------------------------------------------------
Téléchargez le RFC 9547
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : DÉPUTÉE PIRATE - COMMENT J'AI INFILTRÉ LA MACHINE EUROPÉENNE
Auteur(s) du livre : Leïla Chaibi
Éditeur : Les liens qui libèrent
979-10-209-2405-6
Publié en 2024
Première rédaction de cet article le 22 avril 2024
--------------------------------------------------------------------------------
Ce petit livre résume l'expérience de l'auteure au Parlement européen, notamment
à travers ses tentatives pour faire reconnaitre le statut de salarié aux
employés d'Uber (ou d'entreprises équivalentes).
Le titre et le sous-titre sont trompeurs : l'auteure n'est pas députée Pirate
mais LFI, et elle n'a rien infiltré, elle a été élue au Parlement européen. Ce
sous-titre ridicule fait penser à cette journaliste de droite qui avait fait un
livre disant qu'elle était infiltrée chez les wokes, alors qu'elle était juste
allé à quelques réunions. Mais, bon, on sait que ce n'est pas l'auteure qui fait
la couverture du livre.
Donc, Leïla Chaibi raconte son expérience au Parlement européen. Elle ne
surprendra pas les amateurs de l'excellente série télé Parlement, on y retrouve
l'incroyable complexité du machin, le poids des lobbys, les arrangements divers,
même entre partis opposés. Sauf qu'au lieu de légiférer sur le finning, comme
dans la série télé, elle essaie de faire en sorte que les employés des
entreprises comme Deliveroo, officiellement sous-traitants, soient reconnus pour
ce qu'ils sont, des salariés.
Et ce n'est pas facile. Dans l'ambiance feutrée du Parlement, où les bruits et
la réalité du monde extérieur ne pénètrent pas, intéresser les collègues à des
choses concrètes n'est pas facile. Et une fois un texte voté par le Parlement,
il n'est pas adopté pour autant, puisque le Parlement européen ne sert à rien.
Il n'a pas l'initiative législative et ses textes ne valent que si le Conseil et
la Commission le veulent bien (le fameux trilogue). Les politiciens et les
journalistes qui regrettent que les électeurs ne s'intéressent pas aux élections
du Parlement européen devraient se demander pourquoi (ma réponse : parce que ce
Parlement n'est qu'une coquille vide, dénuée de pouvoir, il en a encore moins
que le Parlement français, ce qui n'est pas peu dire).
En outre, pour cette question particulière du salariat des employés d'Uber ou de
Deliveroo, l'auteure a eu à faire face à un lobbying intense du gouvernement
français, très soumis à Uber, et qui a tout essayé pour saboter le projet.
Le livre est bien écrit, très vivant (malgré l'aridité du sujet), très
pédagogique. Je ne voterais quand même pas LFI aux prochaines élections
européennes, vu leurs positions sur l'Ukraine ou l'islamisme, mais si vous
voulez comprendre le Parlement européen avant d'aller voter le 9 juin, c'est une
bonne source.
L'article seul
--------------------------------------------------------------------------------
GETTING TAI TIME ON A DEBIAN MACHINE
First publication of this article on 16 April 2024
Last update on of 17 April 2024
--------------------------------------------------------------------------------
It should work by default but, apparently, on some operating systems like
Debian, it does not: to get the TAI time, you need a small configuration change.
I document it here for myself or for people which will use a search engine and
find this page.
TAI is useful because, unlike UTC, it never adds an extra second, neither it
misses one (UTC does, because of leap seconds). This makes it convenient, for
instance for Internet servers. But how to get TAI time on a Debian machine?
The official answer is that when you use clock_gettime in a C program or
time.clock_gettime in a Python one, you need to pass the option CLOCK_TAI. One
can easily check that, on a Debian stable machine (version 12.5), it does not
work: you get the same value with CLOCK_TAI or CLOCK_REALTIME (the typical
clock, set on UTC). Unfortunately, no error code will tell you that something
was wrong.
It seems that the kernel (which manages the clock and answers to clock_gettime)
knows only UTC and, to convert to TAI, it needs to know the offset (currently 37
seconds). Debian has a file to do so, a leap seconds table, in
/usr/share/zoneinfo/leap-seconds.list. This file contains all the information
necessary to get TAI from UTC. But someone has to read it and to inform the
kernel. This is typically done by ntpd. But it is not done by default, this is
why the above test failed.
So, the system administrator needs to configure ntpd to load this file. This is
done in /etc/ntpsec/ntp.conf (or /etc/ntp.conf depending on the version of ntpd
you use) by adding this line:
leapfile /usr/share/zoneinfo/leap-seconds.list
and restarting ntpd and waiting some time for the kernel to synchronize, it is
not instantaneous.
If you see in the log file (for instance with journalctl -n 10000 -t ntpd | grep
-i leap) something like:
Apr 16 08:25:39 mymachine ntpd[29050]: CLOCK: leapsecond file ('/var/lib/ntp/leap-seconds.list'): open failed: Permission denied
(note the file name, which is not the default one), it means you need to check
the permissions of the file and that systemd or AppArmor are not adding some
restrictions (the default AppArmor profile of ntpd on Debian includes
/usr/share/zoneinfo/leap-seconds.list but may be you changed something).
You can check that the kernel now knows the truth, for instance with a simple
Python session:
% python
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.clock_gettime(time.CLOCK_TAI)
1713284374.8322737
>>> time.clock_gettime(time.CLOCK_REALTIME)
1713284337.8329697
You can see that there is indeed 37 seconds of difference (plus a small value
because of the delay between the two commands).
That's all. You can now use TAI in your programs. The file
/usr/share/zoneinfo/leap-seconds.list is automatically managed by Debian (it is
part of the package tzdata, and the reference version is
https://data.iana.org/time-zones/tzdb/leap-seconds.list, itself a copy of
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, itself made by the
Paris observatory) so you don't need the programs like ntpleapfetch which are
necessary on other operating systems.
For instance, on a Slackware system, the file leap-seconds.list is not provided
by default (there is a file named /usr/share/zoneinfo/leapseconds, with a
different format, and that ntpd cannot use), so you will need to configure cron
to download the proper file.
Thanks to Nicolas Sapa and Matthieu Herrb for the useful help.
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : DES ÉLÈVES À LA CONQUÊTE DU PASSÉ
Auteur(s) du livre : Magali Jacquemin
Éditeur : Libertalia
978-2-9528292
Publié en 2023
Première rédaction de cet article le 15 avril 2024
--------------------------------------------------------------------------------
Ce livre raconte les dix ans d'expérience de l'auteure, professeure des écoles,
à enseigner l'histoire à des élèves du primaire, en essayant de ne pas se
limiter à un récit venu d'en haut.
C'est tout à fait passionnant. L'auteure, partisane des méthodes Freinet (mais
avec nuance et sans en faire un dogme), essaie de ne pas se contenter de parler
d'histoire aux enfants mais de les faire pratiquer un peu, en partant de
sources. Évidemment, vu leur âge, ielles ne feront pas de recherche vraiment
originale (et ne travailleront pas forcément sur des sources primaires) mais le
but est qu'ielles comprennent que l'histoire, ce ne sont pas juste des dates
qu'on assène d'en haut.
Et que l'histoire ne concerne pas que des rois et des généraux. Par exemple,
lorsque l'auteure enseigne dans le quartier de La Villette, elle fait travailler
ses élèves sur les anciennes usines du quartier, usine à gaz ou sucrerie, avec
recherche d'informations sur les conditions de travail des différentes
époques.Elle les emmène même voir des archives et comprendre ainsi avec quel
matériau les historiens travaillent.
La difficulté est bien sûr de laisser les élèves assez libres (principes de
Freinet) tout en les cadrant pour qu'ils aient les connaissances de base. Elle
note que les élèves manquent souvent de contexte et, par exemple, lors d'un
travail sur les lettres entre les soldats et leurs femmes et fiancées pendant la
Première Guerre mondiale, un élève a demandé pourquoi ils ne s'appelaient pas
par téléphone. Il faut donc fixer les époques et leurs caractéristiques dans
l'esprit des élèves.
Une autre question émouvante portait sur la guerre d'Algérie, un certain nombre
de ses élèves étant issu·es de l'immigration algérienne. Faut-il parler de la
torture, sachant que le grand-père d'une des élèves l'a fait ? Comment concilier
l'importance de la vérité avec le souci de ne pas traumatiser les élèves ?
L'auteure ne se contente en effet pas de gentilles généralités « les élèves sont
créatifs, il faut les laisser faire », elle détaille les difficultés, les
nombreuses questions soulevées par cet objectif de liberté, et les solutions
trouvées.
Bref, je recommande ce livre à celles et ceux qui s'intéressent à l'histoire et
à l'éducation.
L'article seul
--------------------------------------------------------------------------------
PRINTING ON A XEROX ALTALINK FROM DEBIAN
First publication of this article on 11 April 2024
--------------------------------------------------------------------------------
This is a very short article documenting how I managed to configure a Xerox
AltaLink C8130 printer on a Debian machine. No rocket science, it is just that
it could have been easier so I document it for the benefits of the people
finding this artcle via a search engine, and also for my own benefit if I have
to do it again.
I use CUPS for printing on my Debian machine and, without anything special, it
worked with the Xerox AltaLink C8130. But without any option (double-sided,
stapling, etc). To have the full set of options, I deleted the printer through
CUPS' Web interface (the one which is by default at http://localhost:631/) and
added it from scratch (Administration → Add a printer). I then choosed "LPD/LPR
printer" (I assume it should work as well with IPP but I did not try), then used
socket://192.0.2.43/ as connection parameter (the IP address being of course the
printer's address; the easiest way to get it is by printing a test page from the
front panel of the printer).
Then, I added the PPD file. This is the important step and it is not easy to
find the PPD file on Xerox Web site (a "site:support.xerox.com ppd altalink" in
your favorite search engine helps, searching for "drivers" or "download" is
useless). The file is labeled "Generic PPD" and its name is
AltaLink_C8130-C8170_5.709.0.0_PPD.zip.
You can then upload it to CUPS through its Web interface and it's done.
L'article seul
--------------------------------------------------------------------------------
RFC 9460: SERVICE BINDING AND PARAMETER SPECIFICATION VIA THE DNS (SVCB AND
HTTPS RESOURCE RECORDS)
Date de publication du RFC : Novembre 2023
Auteur(s) du RFC : B. Schwartz (Meta Platforms), M. Bishop, E. Nygren (Akamai
Technologies)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 8 avril 2024
--------------------------------------------------------------------------------
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.
Un client d'un service réseau a en effet plein de questions à se poser avant de
tenter une connexion. Quelle adresse IP utiliser ? Quel port ? Chiffrement ou
pas ? Les anciens mécanismes traitent la question de l'adresse IP (on la trouve
par une requête DNS) et celle du port, si on se limite aux ports bien connus
(comme 43 pour whois). Mais cela ne dit pas, par exemple, si le serveur HTTP
distant accepte ou non HTTP/3 (RFC 9114). Par contre, cet enregistrement HTTPS
de Cloudflare va bien nous dire que ce serveur accepte HTTP/2 et 3 :
% dig cloudflare.com HTTPS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28399
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
cloudflare.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5
…
;; WHEN: Mon Apr 08 09:27:01 CEST 2024
;; MSG SIZE rcvd: 226
Bon, en quoi consiste cet enregistrement SVCB ? Il a deux modes de
fonctionnement, alias et service. Le premier mode sert à faire d'un nom une
version canonique d'un autre, un peu comme le CNAME mais en étant utilisable à
l'apex d'une zone. Le second mode sert à indiquer les paramètres techniques de
la connexion. Un enregistrement SVCB (ou HTTPS) a trois champs dans ses
données :
* SvcPriority : quand il vaut zéro, il indique le mode alias. Autrement (par
exemple dans le cas ci-dessus), il indique la priorité de ces paramètres.
* TargetName : en mode alias, il indique le nom canonique, ou autrement un nom
alternatif (pour un service accessible via plusieurs noms). Dans l'exemple
Cloudflare ci-desssus, il valait la racine (un point) ce qui indique
l'absence de nom alternatif (section 2.5).
* SvcParams : une liste de couples {clé,valeur} pour les paramètres de
connexion (uniquement en mode service). Dans le cas avec Cloudflare, c'était
alpn="h3,h2" ipv4hint=104.16.132.229,104.16.133.229
ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5. (Si vous vous intéressez
aux débats à l'IETF, la question de la syntaxe de ces paramètres avait
suscité une longue discussion.)
Les enregistrements SVCB ont le type 64 (enregistré à l'IANA) et les HTTPS, qui
ont la même syntaxe et le même contenu, mais sont spécifiques à HTTP, ont le 65
(SVCB est générique). Les enregistrements HTTPS (et de futurs enregistrements
pour d'autres protocoles) sont dits « compatibles avec SVCB » car ils ont la
même syntaxe et la même sémantique.
Notre RFC définit (section 7) une liste de paramètres possibles mais d'autres
peuvent être ajoutés dans un registre IANA, via la procédure « Examen par un
expert » (RFC 8126). Pour l'instant, il y a, entre autres :
* alpn : indique l'ALPN (RFC 7301).
* ech : il servira à indiquer la clé à utiliser pour chiffrer le SNI.
* port : comme son nom l'indique.
* ipv4hint et ipv6hint : les adresses IP du service.
L'enregistrement peut (cela dépend des protocoles qui l'utilisent, HTTP ne le
fait pas) être placé sur un sous-domaine indiquant le service, par exemple
_8765._baz.api.example.com (section 10.4.5).
Idéalement, un serveur faisant autorité devrait renvoyer les SVCB et les HTTPS,
s'ils sont présents, dans la section additionnelle de la réponse, lorsque le
type demandé était une adresse IP. Mais ceux de Cloudflare ne semblent pas le
faire actuellement. (PowerDNS le fait.)
Si vous vous intéressez aux questions opérationnelles, et que vous voulez mettre
des enregistrements SVCB/HTTPS dans votre zone, la section 10 du RFC est faite
pour vous. J'ai des enregistrements HTTPS pour ce blog :
# Un alias à l'apex (la priorité 0 indique le mode alias)
% dig +short +nodnssec bortzmeyer.org HTTPS
0 www.bortzmeyer.org.
# J'ai HTTP/2 (mais pas encore HTTP/3)
% dig +short +nodnssec www.bortzmeyer.org HTTPS
1 . alpn="h2"
Pour cela, j'ai mis dans le fichier de zone :
; Enregistrements SVCB (HTTPS).
; HTTP/2 (mais pas encore - au 2024-04-08 - de HTTP/3)
www IN HTTPS 1 . alpn="h2"
; alias
@ IN HTTPS 0 www.bortzmeyer.org.
Les clients HTTP récents, qui gèrent SVCB/HTTPS vont alors se connecter
directement en HTTP/2 à https://www.bortzmeyer.org/ même si l'utilisateur
demandait originellement http://bortzmeyer.org/ (le type d'enregistrement HTTPS,
comme son nom l'indique, sert aussi à annoncer qu'on accepte HTTPS, ce qui
permettra d'abandonner HSTS). Les clients HTTP plus anciens, évidemment, ne
connaissent pas le système SVCB/HTTPS et il faut donc garder une configuration
pour eux (par exemple des adresses IP à l'apex). Il y a aussi les autres
méthodes, comme le Alt-Svc: du RFC 7838. La section 9.3 du RFC décrit le
comportement attendu lorsque les différentes méthodes coexistent.
Faites attention toutefois, lorsque vous mettez ce type d'enregistrements dans
votre zone, je ne connais pas encore d'outils de test permettant de vérifier la
syntaxe des enregistrements, encore moins leur correspondance avec la réalité
(par exemple, SSLLabs ne semble pas le faire). C'est un problème général de la
signalisation sur l'Internet, quand on signale (notamment via le DNS) les
capacités d'un serveur : le logiciel client doit de toute façon être prêt à
tout, car il ne peut jamais être sûr que le signal est conforme aux faits.
En parlant d'anciens logiciels (clients et serveurs), vous pouvez trouver une
liste de mises en œuvre de SVCB/HTTPS. Attention, elle est incomplète et pas à
jour. Notez qu'il y a parfois des contraintes particulières, ainsi, il semble
que Firefox ne demande des enregistrements HTTPS que s'il utilise DoH. iOS
envoie des requêtes HTTPS depuis iOS 14, publié en septembre 2020, ce qui avait
étonné, à l'époque.
En parlant de Firefox, s'il est assez récent, et s'il est configuré pour faire
du DoH, vous pouvez tester le SVCB/HTTPS en allant dans
about:networking#dnslookuptool. En entrant un nom de domaine, le champ « RR
HTTP » doit renvoyer l'enregistrement HTTPS.
Avec un tcpdump récent, voici le trafic DNS utilisant le nouvel enregistrement
DNS, qu'on peut observer sur un serveur faisant autorité pour bortzmeyer.org :
09:49:23.354974 IP6 2a04….31362 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 13024% [1au] HTTPS? www.bortzmeyer.org. (47)
09:52:06.094314 IP6 2a00….56551 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 40948% [1au] HTTPS? wWw.bOrTZmEyER.ORg. (62)
10:06:21.501437 IP6 2400….11624 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 59956 [1au] HTTPS? doh.bortzmeyer.fr. (46)
10:06:21.999608 IP6 2400….36887 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 17231 [1au] HTTPS? radia.bortzmeyer.org. (49)
10:25:53.947096 IP6 2001….54476 > 2001:4b98:dc0:41:216:3eff:fe27:3d3f.53: 26123% [1au] HTTPS? www.bortzmeyer.org. (47)
Si votre tcpdump est plus ancien, vous verrez Type65 au lieu de HTTPS.
Sinon, si vous aimez les bricolages (et celui-ci sera de moins en moins utile
avec le temps, au fur et à mesure que les serveurs géreront ce type), pour
fabriquer les enregistrements, vous pouvez utiliser cet outil, qui va fabriquer
la forme binaire, directement chargeable par les serveurs faisant autorité :
% perl type65_https.pl 'example.net HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.42" ipv6hint="2001:db8::42"'
example.net. TYPE65 ( \# 41 00010000010006026833026832000400
04c000022a0006001020010db8000000 000000000000000042 )
(Il faut un Net::DNS récent sinon « unknown type "HTTPS" at
/usr/share/perl5/Net/DNS/RR.pm line 671. in new Net::DNS::RR( www.bortzmeyer.org
HTTPS 1 . alpn="h2" ) at type65_https.pl line 30. ».)
Quelques articles pas mal :
* Simple HTTPS Records par Kal Feher.
* Use of HTTPS Resource Records avec le résultat de mesures sur le déploiement
effectif.
* Autres mesures dans le monde, l'article Deciphering the Digital Veil:
Exploring the Ecosystem of DNS HTTPS Resource Records.
--------------------------------------------------------------------------------
Téléchargez le RFC 9460
L'article seul
--------------------------------------------------------------------------------
UN RÉSOLVEUR DNS PUBLIC EN INDE
Première rédaction de cet article le 7 avril 2024
--------------------------------------------------------------------------------
J'avais raté l'information : il y a désormais un résolveur DNS public en Inde,
dns.nic.in.
Il ne semble pas y avoir eu beaucoup de communication publique sur ce service
mais il fonctionne. Un résolveur DNS public est un résolveur qui est ouvert à
toustes et accepte donc des requêtes DNS de n'importe quelle adresse IP. (Un
résolveur ouvert fait pareil mais c'est une erreur de configuration ; un
résolveur public résulte d'une action volontaire.) Les plus connus sont ceux de
grosses entreprises étatsuniennes comme Google (avec son 8.8.8.8) ou Cloudflare
(avec son 1.1.1.1). Si on ne veut pas, et avec raison, contribuer à nourrir ces
entreprises d'encore plus de données personnelles, sans compter les risques de
centralisation de la résolution DNS, on a le choix : on peut avoir son propre
résolveur, ou bien utiliser d'autres résolveurs publics comme celui de Yandex
(si on veut envoyer ses données personnelles au FSB plutôt qu'à la NSA), celui
d'une entreprise allemande ou d'une association française. (Il y en a même un
que je gère.)
Cette offre importante et variée s'est enrichie (mais je ne sais pas trop quand)
d'un résolveur indien. Il est accessible en UDP et TCP avec plusieurs adresses
IP. Prenons l'une des plus jolies, 2409::.
% dig @2409:: mastodon.gougere.fr AAAA
; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @2409:: mastodon.gougere.fr AAAA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: d5d69e457527742201000000661296ca11b1e6683393ded2 (good)
;; QUESTION SECTION:
;mastodon.gougere.fr. IN AAAA
;; ANSWER SECTION:
mastodon.gougere.fr. 900 IN AAAA 2001:bc8:1202:ce00::1
mastodon.gougere.fr. 900 IN RRSIG AAAA 13 3 900 (
20240522050147 20240323042710 18689 gougere.fr.
YUzJqyzLVFbndBhaFPtxcQZPoFgVynD9BpxukCuYKJzP
PtSzNK/lY3xFvHi44Txda+/KrZiRIr7LvuU46s0RhQ== )
;; Query time: 304 msec
;; SERVER: 2409::#53(2409::) (UDP)
;; WHEN: Sun Apr 07 14:51:22 CEST 2024
;; MSG SIZE rcvd: 210
OK, tout fonctionne, et on peut voir (flag AD, pour Authentic Data) que ce
résolveur valide avec DNSSEC. Le temps de réponse n'est pas extraordinaire
depuis ma machine en France mais il est probable que les gérants de ce serveur
ont privilégié leur présence en Inde.
Testons cette hypothèe avec les sondes RIPE Atlas :
% blaeu-resolve --nameserver 2409:: --displayvalidation --displayrtt --requested 100 \
--country IN --old_measurement 69708749 --type AAAA geoponum.com
…
[ (Authentic Data flag) 2001:41d0:301::28] : 33 occurrences Average RTT 27 ms
[TIMEOUT] : 11 occurrences
Test #69708785 done at 2024-04-07T13:01:15Z
% blaeu-resolve --nameserver 2409:: --displayvalidation --displayrtt --requested 100 \
--country JP --old_measurement 69708763 --type AAAA geoponum.com
…
[ (Authentic Data flag) 2001:41d0:301::28] : 98 occurrences Average RTT 134 ms
[2001:41d0:301::28] : 1 occurrences Average RTT 897 ms
[TIMEOUT] : 1 occurrences
Test #69708813 done at 2024-04-07T13:03:37Z
(On réutilise les sondes d'une mesure précédente, pour augmenter la probabilité
que tout soit dans la mémoire du résolveur.) On voit que la latence moyenne est
plus basse en Inde qu'au Japon, ce qui est logique. Ce résolveur n'est donc
peut-être pas la solution idéale si vous vivez en dehors de l'Inde.
Je l'ai dit, l'offre en matière de résolveurs publics est très diverse et donc
les arguments des contempteurs de DoH comme quoi DoH pousserait à la
centralisation sont bien à côté de la plaque. Notez aussi que, bien qu'il existe
de nombreux résolveurs publics de qualité opérationnels, celui annoncé en
fanfare par la Commission Européenne il y a déjà plusieurs années, DNS4EU, ne
fonctionne toujours pas (Thierry Breton est plus doué pour les annonces que pour
l'opérationnel, ce qui était déjà le cas lorsqu'il dirigeait Atos).
Ah, mais j'ai dit que le résolveur était accessible en UDP et en TCP. Et avec
des protocoles chiffrés comme DoT (RFC 7858) ou DoH (RFC 8484) ?
% kdig +tls @2409:: geoponum.com
;; WARNING: can't connect to 2409::@853(TCP)
;; ERROR: failed to query server 2409::@853(TCP)
Ah, zut, pas encore de chiffrement. Mais, en fait, c'est plus compliqué que
cela. Il semble que certaines instances du nuage anycast (cf. plus loin) aient
du chiffrement, mais pas les autres. Donc, selon l'adresse IP de service qu'on
utilise et l'endroit où on est, on verra du chiffrement ou pas :
% kdig +nsid +https=/dns-query @1.10.10.10 geoponum.com
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; HTTP session (HTTP/2-POST)-(1.10.10.10/dns-query)-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; NSID: 696E2D626F6D2D7331 "in-bom-s1"
;; QUESTION SECTION:
;; geoponum.com. IN A
;; ANSWER SECTION:
geoponum.com. 3600 IN A 51.91.236.193
;; Received 70 B
;; Time 2024-04-07 16:49:26 CEST
;; From 1.10.10.10@443(TCP) in 613.4 ms
Ici, l'instance de Bombay a bien répondu en DoH (son certificat, sans surprise,
est un Let's Encrypt).
En demandant le NSID (RFC 5001, on voit que le résolveur est manifestement
anycasté :
% blaeu-resolve --nameserver 2409:: --nsid --requested 200 --type AAAA geoponum.com
Nameserver 2409::
[TIMEOUT] : 12 occurrences
[2001:41d0:301::28 NSID: in-amd-s1;] : 134 occurrences
[2001:41d0:301::28 NSID: in-blr-s1;] : 32 occurrences
[2001:41d0:301::28 NSID: in-maa-s1;] : 6 occurrences
[2001:41d0:301::28 NSID: in-maa-s2;] : 3 occurrences
[2001:41d0:301::28 NSID: in-bom-s1;] : 1 occurrences
[2001:41d0:301::28 NSID: in-gau-s1;] : 6 occurrences
[2001:41d0:301::28 NSID: None;] : 3 occurrences
[2001:41d0:301::28 NSID: in-bom-s2;] : 3 occurrences
Test #69708899 done at 2024-04-07T13:10:50Z
On voit au moins sept instances différentes. Le schéma de nommage semble être le
classique code IATA des aéroports (AMD = Ahmedabad, BLR = Bangalore, etc).
Si on essaie d'obtenir le nom du serveur à partir de son adresse IP, on voit que
la zone 0.0.0.9.0.4.2.ip6.arpa est bien cassée (regardez l'EDE - RFC 8914) :
% dig -x 2409::
…
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9388
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 7 (Signature Expired): (6GJV)
;; QUESTION SECTION:
;0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.0.4.2.ip6.arpa. IN PTR
;; Query time: 4296 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Sun Apr 07 10:40:34 CEST 2024
;; MSG SIZE rcvd: 111
Outre les signatures DNSSEC expirées, cette zone a plein d'autres problèmes DNS.
Et les adresses IP sortantes, à partir desquelles le résolveur indien pose des
questions aux serveurs faisant autorité ? Testons avec le service
ip.dyn.bortzmeyer.fr, qui renvoie l'adresse IP de son client (du résolveur,
donc) :
% blaeu-resolve --nameserver 2409:: --nsid --requested 200 --type TXT ip.dyn.bortzmeyer.fr
Nameserver 2409::
["160.202.194.2" NSID: in-amd-s1;] : 140 occurrences
[TIMEOUT] : 10 occurrences
["160.202.198.2" NSID: in-blr-s1;] : 5 occurrences
["2409:e:e7::3" NSID: in-maa-s2;] : 4 occurrences
["240a:eff6::2" NSID: in-blr-s1;] : 23 occurrences
["160.202.200.2" NSID: in-gau-s1;] : 1 occurrences
["180.250.245.54" NSID: None;] : 1 occurrences
["2409:e:e7::2" NSID: in-maa-s1;] : 2 occurrences
["45.249.124.2" NSID: in-maa-s1;] : 1 occurrences
["240a:eff8::2" NSID: in-gau-s1;] : 7 occurrences
["2409:e:e4::2" NSID: in-bom-s1;] : 2 occurrences
["2409:e:e4::3" NSID: in-bom-s2;] : 2 occurrences
["99.212.0.7" NSID: None;] : 1 occurrences
["121.46.96.2" NSID: in-bom-s1;] : 1 occurrences
Test #69709105 done at 2024-04-07T13:26:34Z
On voit une grande variété de préfixes, tous enregistrés en Inde, à divers
organismes publics.
L'article seul
--------------------------------------------------------------------------------
RFC 9340: ARCHITECTURAL PRINCIPLES FOR A QUANTUM INTERNET
Date de publication du RFC : Mars 2023
Auteur(s) du RFC : W. Kozlowski, S. Wehner (QuTech), R. Van Meter (Keio
University), B. Rijsman, A. S. Cacciapuoti, M. Caleffi (University of Naples
Federico II), S. Nagayama (Mercari)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF qirg
Première rédaction de cet article le 3 avril 2024
--------------------------------------------------------------------------------
Voici un RFC assez futuriste qui explore à quoi pourrait ressembler un futur
« Internet » quantique. Je divulgâche tout de suite : ce ne sera pas de si tôt.
Quelques avertissements s'imposent d'abord. Avant tout, rappelez-vous que la
quantique produit des résultats qui sont parfaitement cohérents théoriquement et
très bien vérifiés expérimentalement mais qui sont hautement non-intuitifs.
Avant d'aborder le monde merveilleux de la quantique, n'oubliez pas d'oublier
tout ce que vous croyez savoir sur le monde physique. Et ne comptez pas trop sur
moi comme guide, on sort nettement ici de mon domaine de compétence. Ensuite,
« quantique » est un terme à très forte charge marketing (moins que « IA » mais
davantage que « métavers » ou même « blockchain », qui semblent bien passés de
mode). Il faut donc être prudent chaque fois qu'un commercial ou un
éditorialiste va dire que « c'est quantique » ou que « la quantique va
bouleverser tel ou tel domaine ». Enfin, il y a loin de la coupe aux lèvres : de
même qu'on n'a pas encore d'ordinateur quantique utile, on n'a pas encore de
réseau quantique. Le RFC est à juste titre prudent, pointant les différents
obstacles qui restent sur le chemin de l'Internet quantique.
Bon, ces précautions étant posées, qu'est-ce qu'un réseau quantique et pourquoi
y consacrer un RFC ? La section 1 du RFC le résume : un réseau quantique est un
réseau qui ferait communiquer des dispositifs quantiques pour faire des choses
inimaginables avec un réseau classique. Il s'appuierait sur des propriétés
spécifiques au monde quantique, notamment l'intrication, propriétés qui n'ont
pas d'équivalent dans le monde classique. Attention, et le RFC insiste bien
là-dessus, personne n'envisage de remplacer l'Internet classique par un Internet
quantique (de la même façon que les futurs ordinateurs quantiques, étant loin
d'être généralistes, ne remplaceront pas les ordinateurs classiques). Au
contraire, le scénario envisagé est celui d'un réseau hybride, partiellement
quantique. (Une lecture recommandée par le RFC est « The quantum internet ».)
Un exemple typique qui ne serait pas possible avec un réseau classique est celui
de la distribution quantique de clés (parfois appelée du terme erroné de
« cryptographie quantique »), dont l'utilité pratique est douteuse mais qui est
assez spectaculaire et, contrairement à d'autres applications, est assez avancée
techniquement. D'autres applications sont envisageables à plus long terme. C'est
le cas par exemple du blind quantum computation, qui n'a pas encore d'article
Wikipédia mais est expliqué dans cet article.
En laboratoire, beaucoup de résultats ont été obtenus. Les chercheurs et
chercheuses ont déjà mis au point bien des dispositifs physiques étonnants. Mais
à l'échelle du réseau, il n'y a pas encore eu beaucoup de travaux. Le RFC
compare cette situation à celle d'un réseau classique où on aurait des fibres
optiques et des lasers pour les illuminer mais aucun protocole de transport,
aucun mécanisme de routage, encore moins de moyens de gérer le réseau.
Développer une application pour un réseau quantique revient à toucher
directement au matériel, comme, pour un réseau classique, s'il fallait que
chaque application parle aux interfaces physiques, sans avoir d'interface de
plus haut niveau comme les prises.
La section 2 du RFC est un rappel sur la quantique. Comme dit plus haut, c'est
un domaine riche et complexe, où l'intuition ordinaire ne sert pas à
grand'chose. Donc, lire ce rappel est une bonne idée mais n'espérez pas tout
comprendre si vous n'êtes pas spécialiste de la question. Cette section est
conçue pour des gens qui ne connaissent rien à la physique quantique, elle
recommande, pour aller plus loin, le livre de Sutor Dancing with Qubits ou bien
celui de Nielsen et Chuang, Quantum Computation and Quantum Information.
Le rappel commence avec la notion d'état quantique. Vous avez sans doute déjà
entendu dire qu'un bit classique peut prendre deux valeurs, 0 ou 1, alors que
son équivalent quantique, le qubit, a un état qui est une superposition de
valeurs possibles, avec des probabilités. Lorsqu'on le mesure, on trouve un 0 ou
un 1. (Oui, comme le célèbre chat qui est à la fois vivant et mort.) Attention,
ces non-certitudes ne sont pas la conséquence d'un manque d'information mais
sont une propriété fondamentale du monde quantique (Alain Aspect a eu un prix
Nobel pour avoir prouvé cela). Notez que les versions HTML ou PDF du RFC sont
recommandées ici, car il y a quelques équations. Comme un qubit est dans un état
qui superpose les deux valeurs possibles, les opérations quantiques agissent sur
tout l'état, par exemple l'équivalent quantique d'une porte NOT va inverser les
probabilités du 0 et du 1 mais pas transformer un 0 en 1.
Le terme « qubit » (et cette distinction revient souvent dans le RFC) peut
désigner aussi bien le concept abstrait que le truc physique qui va le mettre en
œuvre (il existe plusieurs techniques pour fabriquer un engin qui gérera des
qubits).
On peut ensuite assembler des qubits et, très vite, le nombre de possibilités
croît. Mais l'intérêt de mettre des qubits ensemble est qu'on peut les intriquer
et ce concept est au cœur de beaucoup de solutions quantiques, notamment du
réseau quantique. Une fois intriqués, les deux qubits verront leur sort lié. Une
mesure sur l'un affectera l'autre. (Rappel : la quantique n'est pas intuitive et
l'intrication n'a pas d'équivalent dans le monde non-quantique, celui sur lequel
a été bâtie notre intuition.) La mesure, comme toujours en quantique, est
« destructive » au sens où elle ramène à un système classique (le qubit vaut 0
ou 1 quand on le mesure, pas un mélange des deux, et le chat est vivant ou mort
quand on ouvre la boite).
Cette intrication est au cœur des réseaux quantiques (section 3 du RFC). Tous
les projets de réseaux quantiques utilisent cette propriété (qui, rappelons-le,
n'a pas d'équivalent non-quantique). L'intrication permet de corréler deux nœuds
du réseau. Par exemple, pour se mettre d'accord sur une valeur, deux machines
n'ont pas besoin de faire tourner des algorithmes de consensus, elles peuvent
utiliser deux qubits intriqués, chacune en gardant un. Quand une machine lira la
valeur de son qubit, elle sera certaine de la valeur lue par l'autre. Et
l'intrication ne peut pas être partagée : un tiers ne peut pas s'intriquer avec
une intrication existante, ce qui peut avoir des applications en sécurité.
Un réseau quantique est donc défini par notre RFC comme un ensemble de nœuds qui
peuvent échanger des qubits intriqués.
Bon, tout ça, c'est très joli, mais comment on le réalise, ce réseau quantique ?
La section 4 se penche sur les défis :
* Comme toute mesure détruit le caractère quantique du qubit et le transforme
en un bit ordinaire, des opérations banales dans le monde classique, comme la
copie d'un bit, deviennent non triviales.
* Et copier un qubit sans le mesurer ? On ne peut pas (c'est le théorème
d'impossibilité du clonage).
* Tout cela rend très difficile la correction d'erreurs. Un réseau réel,
reposant sur des objets physiques, va forcément voir des erreurs (un rayon
cosmique passe et paf, un 0 est transformé en 1) et de nombreuses techniques
existent pour gérer ce problème dans le monde classique. Mais elles ne
peuvent en général pas s'appliquer dans le monde quantique, qui va donc avoir
un problème de fidélité : la fidélité est la conformité à ce qu'on souhaitait
(elle va de 0 à 1), et les applications doivent en tenir compte.
Distribuer sur le réseau des qubits quelconques n'est pas forcément facile, donc
le RFC suggère de plutôt distribuer des paires de Bell. On peut alors plus
facilement (tout est relatif) faire de la téléportation, c'est-à-dire
« transporter » un qubit d'un point à un autre. Ce n'est pas une violation du
théorème d'impossibilité du clonage puisque le qubit n'est pas copié (il
disparait de son point de départ). Notez que le terme de « téléportation » est
surtout marketing : vous ne pourrez pas déplacer votre chat ou vous-même de
cette façon.
Dernier problème, amplifier le signal (sans le copier !) pour tenir compte de sa
dégradation avec la distance. Il existe une astuce, l'échange d'intrication, que
je ne vais pas essayer d'expliquer, mais qui permet des réseaux quantiques sur
des distances importantes.
Revenons à la correction d'erreurs. Les réseaux quantiques ne sont pas
complètement démunis, et ont des solutions possibles, comme les codes
quantiques.
OK, on a vu que le monde quantique était très spécial. Donc, le réseau quantique
va être bizarre aussi, aux yeux de quelqu'un qui a l'habitude des réseaux
classiques (section 5 du RFC). Par exemple, il fera face à ces problèmes :
* C'est bien joli, les paires de Bell, mais ce n'est pas l'équivalent d'un
paquet portant une charge utile. Il n'y a pas l'équivalent de l'en-tête du
paquet, et le réseau quantique va donc devoir utiliser un réseau classique
pour l'information de contrôle. On ne fera pas un réseau purement quantique.
* Toute action sur des qubits intriqués doit être coordonnée entre les nœuds
puisque l'action sur un qubit va déterminer le résultat d'une action sur les
autres (il faut donc que chaque nœud sache contacter les autres).
Répétons-le, chaque nœud du réseau quantique devra également être relié à un
réseau classique. Le réseau sera donc complexe et son administration pas
évidente.
Une fois qu'on a accepté cela, le réseau classique pourra s'occuper d'opérations
comme la construction des tables de routage, pour laquelle les algorithmes et
méthodes classiques semblent suffire. On n'aura donc peut-être qu'un seul plan
de contrôle (le classique) mais deux plans de données, le classique et le
quantique.
Que faut-il construire comme machines pour le plan de données quantique ?
D'abord, des répéteurs quantiques qui vont pouvoir créer les intrications, les
échanger et contrôler la fidélité. Ensuite :
* Des routeurs quantiques, qui, en plus des fonctions ci-dessus, participeront
au routage.
* Les nœuds ordinaires, des répéteurs qui ne participent pas au routage.
* Les nœuds terminaux, qui pourront émettre et recevoir des qubits mais pas
faire d'échange d'intrication. C'est là que tourneront les applications.
Facile, me direz-vous ? Non, construire ces machines va nécessiter de s'attaquer
à quelques problèmes physiques :
* Stocker un qubit est un défi ! Le monde classique n'aime pas les objets
quantiques et essaie régulièrement de les rappeler à ses lois. Les bruits
divers de l'environnement font rapidement perdre aux qubits leurs propriétés
quantiques. (C'est d'ailleurs pour cela que vous ne rencontrez pas de chats
de Schrödinger dans la vraie vie.) Cela se nomme la décohérence et c'est l'un
des principaux obstacles sur la route des réseaux quantiques (ou des
calculateurs quantiques). Les durées de vie qu'on atteint étaient, lors de la
rédaction du RFC, de l'ordre de la seconde (ou de la minute si on n'est pas
connecté au réseau, source de perturbations).
* La capacité des liens quantiques est un autre problème. Générer des qubits
intriqués prend du temps. Quand on en fabrique dix par seconde, on est
contents. Bien sûr, la technique progresse sans cesse (pas mal des références
du RFC sont un peu datées, car il a mis du temps à sortir) mais pas assez.
* On l'a dit, on peut réaliser des qubits intriqués par différentes méthodes
physiques, avec des performances différentes selon la métrique utilisée. Mais
ces méthodes ne communiquent pas entre elles, ce qui veut dire que tous les
nœuds du réseau doivent utiliser la même.
Si vous n'êtes pas découragé·e (mais il ne faut pas l'être : même si les
difficultés sont colossales, le chemin est rigolo), il faut maintenant, en
supposant qu'on aura les composants de base d'un réseau, les assembler. (À moins
que le choix décrit dans le RFC des paires de Bell et de l'échange d'intrication
ne soit remis en cause par les futurs progrès…) La section 6 se penche sur la
question. Elle démarre par un bel excès d'optimisme, en expliquant que,
contrairement à ce qui s'est passé avec l'Internet classique, on a de
l'expérience sur la construction de réseau, et qu'on pourra donc ne pas faire
d'erreur comme la taille trop réduite des adresses IPv4.
Des services essentiels pour un réseau réel seront difficiles à assurer sur un
réseau quantique. Par exemple, l'impossibilité du clonage interdira d'utiliser
un logiciel équivalent à tcpdump (remarquez, pour la sécurité, c'est un plus).
Le RFC liste les principes de base d'un réseau quantique :
* Le service de base sera l'intrication.
* La fidélité est aussi un service (contrairement au réseau classique où on
peut espérer une fidélité parfaite).
* Le temps va être un facteur crucial, compte tenu de la décohérence. Pas
question de faire patienter des qubits trop longtemps dans une file
d'attente, par exemple.
* Il faudra être flexible, notamment parce que le matériel va continuer à
évoluer.
Et le RFC se termine par une exploration d'une architecture de réseau quantique
possible, inspirée de MPLS. Dans ce réseau (pour l'instant) imaginaire, tout
fonctionne en mode connecté (comme MPLS) : on doit d'abord créer un circuit
virtuel (car créer les paires de Bell et les utiliser va nécessiter de la
coordination, donc il vaut mieux établir d'abord une connexion). Ce QVC (Quantum
Virtual Circuit) a des caractéristiques comme une qualité de service choisie,
qui se décline en, par exemple, une capacité mesurée en nombre de paires de Bell
par seconde et bien sûr une fidélité (toutes les applications des réseaux
quantiques n'ont pas les mêmes exigences en terme de fidélité). La signalisation
peut être décentralisée (comme avec RSVP) ou centralisée (comme avec OpenFlow).
Comme vous le verrez en lisant cette conclusion du RFC, les détails sont encore
approximatifs.
Ce RFC a mis longtemps à être écrit, vous pouvez trouver une description
ancienne du projet sur le blog de l'IETF. Notez que l'écriture de ce RFC a été
en partie financée par la Quantum Internet Alliance européenne.
N'hésitez pas à vous plonger dans la bibliographie très détaillée de ce RFC,
vous y trouverez beaucoup de lectures passionnantes. Il y a même déjà des livres
entiers sur les réseaux quantiques comme celui de Van Meter.
--------------------------------------------------------------------------------
Téléchargez le RFC 9340
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : L'ANIMAL MÉDIATIQUE (LE TEMPS DES MÉDIAS)
Auteur(s) du livre : Ouvrage collectif
Éditeur : Nouveau monde
978-2-38094-393-1
Publié en 2023
Première rédaction de cet article le 3 avril 2024
--------------------------------------------------------------------------------
Ce numéro de la revue d'histoire « Le temps des médias » est consacré à la place
des animaux dans les médias et il y a beaucoup à dire !
Tous les articles sont passionnants mais, parmi ceux qui m'ont particulièrement
instruit :
* L'histoire de l'« ours Martin » (qui n'était pas un ours unique, mais un nom
générique) au Jardin des plantes, par Olivier Vayron. Si les médias de
l'époque adoraient les récits (presque tous imaginaires) d'agressions
commises par Martin sur les visiteurs, la réalité est plus glauque : ce sont
les humains qui agressaient l'ours du zoo, souvent de manière lâche et
ignoble.
* L'analyse de la place de l'animal sauvage dans les récits d'aventure bon
marché du XIXe siècle, par Sophie Bros. Peu de souci de véracité ou même de
vraisemblance dans ces récits conçus pour de la production et de la
distribution de masse. Dans le train de l'époque, tiré par une locomotive à
vapeur, on avait le temps de se délecter d'histoires toutes pareilles, où le
courageux explorateur européen venait à bout de toute une ménagerie de bêtes
féroces et exotiques.
* Plus actuel, un article de Félix Patiès détaille la polémique au sein de la
Fédération Anarchiste sur une émission « antispéciste » de Radio Libertaire.
Difficile équilibre entre un désir d'ouverture à d'autres courants (d'autant
plus importante que l'ARCOM exige une production minimum de contenus
originaux) et nécessité, pour une organisation politique, de ne pas accepter
n'importe quoi sur son antenne, notamment lorsque cela s'oppose directement à
sa ligne politique.
* Toujours dans une actualité plus récente, une étude détaillée de Michel Dupuy
sur la construction de l'image de l'oiseau mazouté, comme symbole des
destructions que la société industrielle inflige à l'environnement. Ce
malheureux oiseau a également été utilisé pour de la propagande de guerre
pendant la guerre du Golfe.
* Les fanas de géopolitique trouveront aussi de quoi les intéresser, avec
l'article de Zhao Alexandre Huang, Mylène Hardy et Rui Wang sur l'utilisation
des pandas par la propagande chinoise. Derrière la mignoncitude, Beijing tire
les ficelles.
* Et bien sûr un article sur le rôle des chats sur l'Internet et un sur celui
des chiens dans les films de Disney (article que j'ai trouvé extrêmement
pro-Disney…)
On peut se procurer ce numéro sous forme papier chez l'éditeur et sous forme
numérique (paradoxalement bien plus chère) sur cairn.info. PS : oui, le site Web
officiel de la revue n'est pas à jour et est plein de mojibake.
L'article seul
--------------------------------------------------------------------------------
RFC 9432: DNS CATALOG ZONES
Date de publication du RFC : Juillet 2023
Auteur(s) du RFC : P. van Dijk (PowerDNS), L. Peltan (CZ.NI), O. Sury (Internet
Systems Consortium), W. Toorop (NLnet Labs), C.R. Monshouwer, P. Thomassen
(deSEC, SSE - Secure Systems Engineering), A. Sargsyan (Internet Systems
Consortium)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 29 mars 2024
--------------------------------------------------------------------------------
L'idée de base de ces « zones catalogue » est d'automatiser la configuration
d'une nouvelle zone DNS sur les serveurs secondaires, en publiant dans le DNS
les caractéristiques des zones qu'ils devront servir. Cela concerne donc surtout
les gros hébergeurs qui ont beaucoup de zones.
Petit rappel : une zone, dans le DNS, est une partie contigüe de l'arbre des
noms de domaine, gérée comme un tout (mêmes serveurs faisant autorité). Ainsi,
si vous venez de louer le nom machin.example, un hébergeur DNS va configurer ses
serveurs pour faire autorité pour ce nom. Par exemple, avec le logiciel NSD, sur
le primaire (serveur maitre) :
zone:
name: "machin.example"
zonefile: "primary/machin.example"
# Les serveurs secondaires :
notify: 2001:db8:1::53
provide-xfr: 2001:db8:1::53
…
Et, sur un serveur secondaire (serveur esclave), qui transférera la zone depuis
le primaire (RFC 5936) :
zone:
name: "machin.example"
# Le primaire :
allow-notify: 2001:db8:cafe::1 NOKEY
request-xfr: AXFR 2001:db8:cafe::1 NOKEY
Si on gère beaucoup de zones, avec des ajouts et des retraits tout le temps,
l'avitaillement manuel est long et risqué (et si on oublie un serveur ?). Éditer
ces fichiers sur tous les serveurs secondaires devient vite pénible. Et si les
logiciels sur les secondaires sont différents les uns des autres (ce qui est
recommandé, pour la robustesse), il faut se souvenir des différentes syntaxes.
Pourquoi faire manuellement ce qu'on peut automatiser ? C'est le principe des
zones catalogue.
Le principe est simple : une zone catalogue est une zone comme une autre,
produite par les mêmes mécanismes (par exemple emacs) et qui sera servie par un
serveur primaire à tous les secondaires, qui changeront alors automatiquement
leur configuration en fonction du contenu de la zone catalogue. Chaque zone à
configurer est un enregistrement de type PTR, dont la partie gauche est une
étiquette interne et la partie droite indique le nom de la zone. Ici, on
configure la zone rutaba.ga, l'étiquette (qui doit être unique) label1 est à
usage interne (section 4.1 du RFC) :
label1.zones.catalog.example. IN PTR rutaba.ga.
Le reste est listé sous forme de propriétés (section 4.2). Une propriété
évidente est l'adresse IP du primaire. Pour l'instant, elle doit être indiquée
via le composant ext qui désigne les propriétés pas encore normalisées :
primaries.ext.catalog.example. IN AAAA 2001:db8:bad:dcaf::42
La liste des propriétés figure dans un registre IANA.
À l'heure actuelle, de nombreux logiciels gèrent ces zones catalogues. Le site
Web du projet (pas mis à jour depuis très longtemps) en liste plusieurs.
Voici un exemple complet de zone catalogue :
; -*- zone -*-
catalog.example. IN SOA ns4.bortzmeyer.org. stephane.bortzmeyer.org. 2023120902 900 600 86400 1
catalog.example. IN NS invalid. ; Le NS est inutile mais
; obligatoire et "invalid" est la valeur
; recommandée (section 4).
version.catalog.example. IN TXT "2" ; Obligatoire, section 4.2.1
label1.zones.catalog.example. IN PTR rutaba.ga.
primaries.ext.catalog.example. IN AAAA 2001:db8:bad:dcaf::42
La configuration de BIND pour l'utiliser :
# La zone catalogue se charge comme n'importe quelle zone. Ceci dit,
# vu le caractère critique de la zone catalogue, la section 7 du RFC
# insiste sur l'importance de sécuriser ce transfert, par exemple avec
# TSIG (RFC 8945) :
zone "catalog.example" {
type slave;
file "catalog.example";
masters {
2001:db8:666::;
};
};
# Et, ici, on la désigne comme spéciale :
options {
...
catalog-zones {
zone "catalog.example"
in-memory no;
};
};
Naturellement, comme toujours lorsque on automatise, on risque le syndrome de
l'apprenti sorcier. Attention donc en générant la zone catalogue. Comme le note
le RFC (section 6) : « Great power comes with great responsibility. Catalog
zones simplify zone provisioning by orchestrating zones on secondary name
servers from a single data source: the catalog. Hence, the catalog producer has
great power and changes must be treated carefully. For example, if the catalog
is generated by some script and this script generates an empty catalog, millions
of member zones may get deleted from their secondaries within seconds, and all
the affected domains may be offline in a blink of an eye. »
--------------------------------------------------------------------------------
Téléchargez le RFC 9432
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : LA BALEINE, UNE HISTOIRE CULTURELLE
Auteur(s) du livre : Michel Pastoureau
Éditeur : Seuil
978-2-02-151688-3
Publié en 2023
Première rédaction de cet article le 29 mars 2024
--------------------------------------------------------------------------------
Michel Pastoureau continue son exploration de l'histoire culturelle des animaux
avec la baleine.
D'abord, une précision, c'est un livre d'histoire des mentalités, pas un livre
de zoologie. Le terme « baleine », dans le passé, pouvait désigner beaucoup
d'animaux qu'on n'appelerait pas « baleine » aujourd'hui. L'idée est de faire le
tour, de l'Antiquité à nos jours, sur la vision que les humains ont de la
baleine. C'est un animal qui, par sa taille, par le milieu jugé hostile où il
vit et par le fait qu'il était très mal connu jusqu'au XIXe siècle, est un
parfait support de fantasmes. En gros, jusqu'au XXe siècle, la baleine est
monstrueuse, inquiétante, incarnation du Mal, puis elle change tout à coup ou,
plutôt, la vision qu'on en a change et on se met à la considérer comme gentille,
menacée, et digne d'être protégée (elle est, avec le panda, un des animaux
iconiques des campagnes de protection de la nature).
Ce retournement est récent. Le christianisme voyait plutôt la baleine
négativement (cf. l'aventure de Jonas, même si la Bible ne dit pas clairement si
c'était une baleine, ou un très gros poisson). Les marins aimaient décrire les
dangers terribles, et imaginaires, qu'elle faisait courir aux bateaux. Et bien
sûr, Moby-Dick n'est pas un modèle de gentillesse, même si son chasseur ne vaut
pas mieux. On l'a dit, ce livre est une histoire culturelle d'humains, donc
toutes les projections n'ont pas grand'chose à voir avec les baleines réelles.
Ah, et le livre est magnifiquement illustré, les dessins médiévaux sont très
bien reproduits, en grand et avec de belles couleurs (vous trouverez celui-ci p.
59). Inutile de rappeler que le réalisme n'était pas le principal souci des
auteurs de ces dessins…
(Tiens, j'ai terminé ce livre juste avant de commencer la série télé danoise
Trom, où la chasse à la baleine aux iles Féroé et les polémiques que cela
suscite sont la toile de fond de l'intrigue policière.)
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : ENIAC IN ACTION
Auteur(s) du livre : Thomas Haig, Mark Priestley, Crispin Rope
Éditeur : MIT Press
978-0-262-53517-5
Publié en 2016
Première rédaction de cet article le 25 mars 2024
--------------------------------------------------------------------------------
Un passionnant livre détaillant l'histoire de l'ENIAC, l'un des premiers
ordinateurs. Contrairement à beaucoup d'autres textes sur l'ENIAC, celui-ci est
très détaillé techniquement et ne vous épargne pas les informations précises sur
le fonctionnement de cette bête, notamment de ses débuts où la programmation se
faisait en soudant et désoudant.
L'ENIAC a été largement traité dans de nombreux ouvrages et articles. De
nombreux mythes et légendes ont été développés, malgré le fait qu'on dispose
d'une quantité énorme d'informations de première main, accessible aux historiens
(beaucoup plus que pour le Colossus, secret militaire et dont beaucoup de
documents ont été détruits). Mais depuis ses débuts, l'ENIAC a été un objet
médiatique, très publicisé (pendant la guerre, il n'était que confidentiel, pas
secret, encore moins très secret, et il a été déclassifié tout de suite après la
guerre). Résultat, tout le monde avait quelque chose à dire sur l'ENIAC.
Par exemple, alors que les premières histoires sur l'ENIAC ne mentionnaient que
des hommes, on a vu plus récemment des histoires affirmer en sens inverse que
tout avait été fait par des femmes, les six de l'ENIAC. Le récit désormais
classique est qu'elles faisaient la programmation de l'ENIAC, les « inventeurs »
classiques, Eckert et Mauchly ne s'occupant « que » du matériel. Écoutant pour
la Nième fois cette affirmation lors d'un exposé au FOSDEM, je me suis demandé
« mais ça voulait dire quoi, au juste, programmer sur l'ENIAC » et j'ai lu ce
livre.
Plusieurs facteurs rendent compliqué de répondre à cette question : d'abord,
comme le notent bien les auteurs du livre, l'ENIAC, qui a eu une durée de vie
très longue (de 1945 à 1955, bien plus qu'un smartphone d'aujourd'hui), a
beaucoup évolué, cet ordinateur unique, qui ne faisait pas partie d'une
fabrication en série, était modifié en permanence. Ainsi, la question de savoir
si l'ENIAC était une machine à programme enregistré (plutôt qu'une « simple »
calculatrice où le programme était à l'extérieur) a plusieurs réponses possibles
(« plutôt non » au début de sa carrière, « plutôt oui » à la fin). Et la façon
de « programmer » l'ENIAC a donc beaucoup changé.
Ensuite, bien que l'ENIAC ait laissé une énorme pile de documentation (comme les
journaux d'exploitation, qui étaient bien sûr entièrement papier) pour les
historiens, tout n'a pas été décrit. Des interactions informelles entre les
membres de l'équipe n'ont pas forcément laissé de trace. Plusieurs couples
mari-femme travaillaient sur l'ENIAC (comme Adele et Herman Goldstine) et il
n'est pas facile de séparer leurs contributions (à chaque époque, on a mis en
valeur les contributions de l'une ou de l'autre, selon la sensibilité de
l'époque).
Enfin, comme tout était nouveau dans cette machine, même les acteurs et les
actrices du projet n'avaient pas toujours une vision claire. Même une
distinction comme celle entre matériel et logiciel était loin d'être évidente à
cette époque. Et la notion même de « programme » était floue. Les « six de
l'ENIAC » avaient été embauchées comme « opératrices », plutôt à déboguer des
programmes existants (la machine avait mauvais caractère et les bogues étaient
souvent d'origine matérielle, un composant qui brûlait, et le déboguage
nécessitait donc de fouiller dans les entrailles de la bête) avant que leur
travail n'évolue vers quelque chose qui ressemblait beaucoup plus à la
programmation actuelle (sans que leurs fiches de poste ne suivent cette
évolution).
Et cette programmation, sur une machine qui était loin d'être bâtie sur un
modèle en couches bien propre, nécessitait des compétences variées. Ainsi, à un
moment, l'ENIAC a reçu des nouvelles mémoires, dites « lignes à retard », où une
onde sonore était envoyée dans un tube de mercure. La lenteur des ondes sonores,
comparée à la vitesse de l'électronique, faisait que cela permettait de
mémoriser (mais pas pour toujours) une information. Comme la ligne à retard
stockait plusieurs informations, et était strictement FIFO, l'optimisation du
programme nécessitait de bien soigner l'ordre dans lequel on mettait les
variables : il fallait qu'elles arrivent à la fin du tube pile au moment où le
programme allait en avoir besoin. Le programmeur ou la programmeuse avait donc
besoin d'une bonne connaissance du matériel et de la physique ! En lisant ce
livre, on comprend mieux les exploits quotidiens que faisaient les « six de
l'ENIAC » et leurs collègues.
Il y avait plein d'autres différences entre la programmation de l'époque et
celle d'aujourd'hui. Par exemple, l'ENIAC manipulait des nombres décimaux (son
successeur, l'EDVAC passera au binaire). Les débats étaient très vivants au sein
de l'équipe sur la meilleure façon de dompter ces nouvelles machines. Ainsi, une
discussion récurrente était de savoir s'il valait mieux une machine complexe
sachant faire beaucoup de choses ou bien une machine simple, ne faisant que des
choses triviales, mais optimisée et plus générale. La deuxième possibilité
nécessitait évidemment que la complexité soit prise en charge par les
programmes. Bref, un débat qui évoque beaucoup celui CISC contre RISC. Au milieu
de tous ces débats, il peut être difficile de distinguer la contribution de
chacun ou de chacune. Ainsi, on présente souvent von Neumann comme l'inventeur
de l'ordinateur moderne à programme enregistré (et où le code est donc traité
comme une donnée), dans son fameux first draft. mais d'autres témoins
relativisent son rôle en estimant que le first draft ne faisait que documenter
par écrit les idées qui circulaient dans l'équipe. Les auteurs du livre se
gardent de trancher (la vérité peut aussi être quelque part entre les deux). Les
éventuels désaccords de personnes compliquent aussi les choses, par exemple
Adele Goldstine et les six de l'ENIAC n'ont pas vraiment les mêmes souvenirs sur
la création de cette équipe et son rôle. (Contrairement à ce qui est parfois
raconté, les six de l'ENIAC n'étaient pas des victimes passives du sexisme, et
ont largement fait connaitre leurs souvenirs et leurs opinions, contrairement à
ceux et celles de Bletchley Park, tenu·es à un secret militaire rigoureux, même
longtemps après la guerre.)
Point amusant, l'ENIAC est entré en service à une époque où les concepts de la
cybernétique étaient à la mode et cela a influencé le vocabulaire de
l'informatique. Si le terme de « cerveau électronique », par lequel était
souvent désigné l'ENIAC, n'est pas resté, c'est avec l'ENIAC qu'on a commencé à
utiliser une autre métaphore humaine, « mémoire » pour parle des dispositifs de
stockage de l'information et, là, ce terme a perduré.
Outre les passions humaines, l'histoire de l'ENIAC a aussi été brouillée par des
conflits motivés par l'argent. Eckert et Mauchly avaient tenté d'obtenir un
brevet sur les concepts de base de l'ENIAC et le long conflit juridique sur ce
brevet (finalement refusé) a été marqué par de nombreux témoignages officiels
devant les tribunaux, témoignages qui ont pu figer certains souvenirs en
fonction d'intérêts financiers.
En tout cas, le débat sur le rôle des six de l'ENIAC a occulté le rôle d'une
autre catégorie, bien oubliée (on ne connait même pas leurs noms), les Rosie qui
ont bâti le monstre, un engin qui occupait une immense pièce et avait nécessité
beaucoup de travail manuel, peu reconnu.
Les auteurs notent d'ailleurs que bien des débats en histoire ne peuvent pas
avoir de réponse simple. Ainsi, la recherche effrénée du « premier » (l'ENIAC
était-il le premier ordinateur ?) n'a pas forcément, notent-ils, de sens. Déjà,
cela dépend de la définition qu'on donne d'« ordinateur », ensuite, certains
concepts émergent petit à petit, sans qu'il y ait un « moment Eurêka » où tout
se révèle d'un coup. (Pour prendre l'exemple d'une autre polémique classique
dans l'histoire de l'informatique, se demander qui a inventé le datagramme n'a
pas plus de sens. Le concept est apparu progressivement, sans qu'on puisse
citer, par exemple, l'article ou la conférence qui l'aurait exposé en premier.)
Le livre se termine d'ailleurs par une « histoire de l'histoire » de l'ENIAC,
qui montre les nombreuses évolutions qu'il y a eu, et qu'il continuera à y
avoir, sur cette machine. Comme souvent l'histoire suit le présent (les
motivations de son époque) plutôt que le passé.
Merci à Valérie Schafer pour le conseil de lire ce livre, tout à fait ce qu'il
faut pour comprendre ce que voulait dire « programmer l'ENIAC ».
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : EATEN BY THE INTERNET
Auteur(s) du livre : Ouvrage collectif, piloté par Corinne Cath
Éditeur : Meatspace Press
978-1-913824-04-4
Publié en 2023
Première rédaction de cet article le 22 mars 2024
--------------------------------------------------------------------------------
Ce court livre en anglais rassemble plusieurs textes sur les questions
politiques liées à l'Internet comme la défense de la vie privée, le chiffrement,
la normalisation, etc.
Le livre est disponible gratuitement en ligne mais vous pouvez préférer
l'édition papier, qui a une curieuse mise en page, avec une couverture qui se
tourne dans un sens inhabituel et les appels des notes de bas de page joliment
décorés.
Vous y trouverez de nombreux articles, tous écrits par des spécialistes de
l'Internet (et j'ai bien dit l'Internet, pas les GAFA, vous n'aurez pas le Nième
article sur les turpitudes de Facebook, encore moins sur les derniers exploits
de l'IA). C'est très intéressant et couvre beaucoup de sujets, dont certains
sont rarement traités (comme l'article de Shivan Kaul Sahib sur les conséquences
politiques des CDN). Mais, vu la taille du livre et le nombre de contributions,
cela reste peu approfondi, donc ce livre vise plutôt un public de débutant·es.
(Si vous suivez ces questions depuis quelques années, vous avez certainement
déjà rencontré ces auteur·es et leurs textes.)
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : THE BOMBER MAFIA
Auteur(s) du livre : Malcolm Gladwell
Éditeur : Penguin Books
978-0-141-99840-4
Publié en 2021
Première rédaction de cet article le 22 mars 2024
--------------------------------------------------------------------------------
Le court livre « The Bomber Mafia » est l'histoire de la controverse
technico-politique au sein de l'armée de l'air des USA, juste avant la Deuxième
Guerre mondiale et pendant celle-ci : comment utiliser le mieux possible les
bombardiers, peut-on forcer un ennemi à capituler en le bombardant et comment ?
Ce n'est pas une étude historique, plutôt un récit journalistique, centré sur
deux personnes, Haywood Hansell et Curtis LeMay. Pour simplifier, le premier
était un représentant d'un groupe surnommé The Bomber Mafia, qui avait une
confiance illimitée dans les capacités des bombardiers à atteindre leur
objectif, à le toucher avec précision, et ainsi à contraindre l'ennemi à
capituler. Avant la deuxième guerre mondiale, leurs idées n'avaient pas vraiment
été testées, et les adversaires de la Bomber Mafia lui reprochaient justement sa
tendance à aborder les problèmes sous un angle trop théorique. LeMay, d'un autre
côté, tout aussi convaincu de la puissance des bombardiers, et qui allait faire
une belle carrière après la guerre, était plus pragmatique. Tous les deux
s'opposaient sur la question de l'utilisation des B-17 et des B-29 mais, à ce
conflit, se superposait aussi celui de tous les aviateurs (dont Hansell et
LeMay) contre les autres branches de l'armée qui estimaient que ces jouets très
chers ne gagneraient pas la guerre à eux seuls (« aucun soldat ne s'est jamais
rendu à un avion »).
Au débat entre les « théoriciens » de la Bomber Mafia et les « praticiens », qui
voyaient bien que les bombardements ne se passaient pas aussi bien que dans les
théories d'avant-guerre, se superposait un débat moral, la Bomber Mafia estimant
que le progrès technique permettait au bombardier de frapper avec une précision
absolue, ce qui limitait les dégâts collatéraux, alors que ses adversaires,
voyant bien la difficulté à mettre les bombes en plein sur l'objectif, dans un
monde réel plein de nuages, d'appareils déréglés, et de vents puissants en
altitude, voulaient plutôt bombarder largement, sans se soucier des
conséquences, notamment sur les civils, voire en les ciblant délibérement.
Le livre détaille (c'est sa meilleure partie) le cas d'un appareil présenté
comme magique, le viseur Norden, une incroyable merveille d'ingéniosité et de
précision, contenant un calculateur analogique et qui devait permettre à l'homme
chargé de déclencher le largage des bombes de mettre en plein dans le mille.
Malgré les promesses boursouflées de l'inventeur (un classique de l'innovation
technologique), malgré la fascination de beaucoup d'aviateurs pour cette très
haute technologie, coûteuse et très secrète (l'équipage avait ordre de tout
faire pour détruire le viseur si le bombardier tombait), le viseur Norden n'a
jamais tenu ses promesses. Spectaculaire en laboratoire, il marchait nettement
moins bien à plusieurs milliers de mètres d'altitude, dans le froid et la
condensation, à bord d'un avion en mouvement. Son échec a beaucoup contribué à
décrédibiliser la Bomber mafia et à donner raison à LeMay et à sa pratique d'un
bombardement très étendu, d'autant plus que LeMay ne s'encombrait pas
d'arguments moraux. Mais la Bomber Mafia n'a apparemment jamais admis que les
faits étaient plus forts que sa théorie, trouvant toujours des moyens de dire
que, cette fois, ça allait marcher comme ils le disaient.
L'auteur, qui a nettement tendance à présenter Hansell comme le bon et LeMay
comme le méchant, alors que tous les deux étaient dans la même armée et
poursuivaient le même but, estime que le temps a donné raison à la Bomber Mafia,
puisque, le numérique ayant remplacé l'analogique, le drone moderne peut frapper
avec une précision parfaite. Est-ce que les militaires d'aujourd'hui peuvent
vraiment, en plein dans le brouillard de la guerre, frapper pile où ils veulent,
sans dégâts collatéraux ?
L'article seul
--------------------------------------------------------------------------------
LA FAILLE DNSSEC KEYTRAP
Première rédaction de cet article le 19 mars 2024
--------------------------------------------------------------------------------
Le 16 février a été publiée la faille de sécurité DNSSEC KeyTrap. Je sais, c'est
un peu tard pour en parler mais c'est quand même utile, non ?
KeyTrap est une faille qui permet un déni de service contre des résolveurs DNS
validants, c'est-à-dire qui vérifient les signatures cryptographiques de DNSSEC.
Avec peu de messages DNS, parfois un seul, elle permet de stopper toute
résolution de noms pendant des minutes, voire des heures. Comme souvent, hélas,
en sécurité informatique, les découvreurs de la faille ont sérieusement abusé
des grands mots dans leur communication (que les médias, comme d'habitude, ont
bien relayés sans esprit critique) mais la faille est réelle et ils ont fait un
bon travail pour la cerner exactement, et la reproduire afin de tester des
remèdes.
Comment fonctionne KeyTrap ? Le point de départ est d'observer qu'un résolveur
validant ne cherche pas à échouer dans la résolution de noms, il cherche à
trouver, si nécessaire en insistant, un enregistrement correctement signé. Par
exemple, si un des serveurs faisant autorité ne renvoie pas de signatures (il
devrait), le résolveur va demander à un autre. Si une signature est invalide, le
résolveur va en essayer d'autres. Cela part d'une bonne intention, éviter un
échec des requêtes des clients. Mais cela ouvre la possibilité, pour un client
malveillant, de donner beaucoup de travail au résolveur.
Le résolveur va essayer, pour chaque signature trouvée, toutes les clés
cryptographiques présentes. En temps normal, il n'y a qu'une signature et une
clé. Lors d'opérations comme le remplacement d'une clé, il peut y en avoir deux.
Mais, et c'est le point important, ces nombres sont contrôlés par l'attaquant.
S'il envoie dix clés et dix signatures, le résolveur aura cent vérifications à
faire. Et si l'attaquant arrive à faire tenir cent clés et cent signatures dans
le message, il faudra dix mille vérifications… Elles retiendront le résolveur
pendant longtemps, l'empêchant de répondre aux autres requêtes (voire le
bloquant complètement si ces vérifications ne sont pas réellement
parallélisées).
Voyons maintenant quelques détails pratiques. D'abord, le résolveur ne va pas
tester toutes les clés mais uniquement toutes celles qui ont l'identificateur,
le keytag indiqué dans la signature. Si on trouve cette signature :
% dig +multi +dnssec brisbane.now.weather.dyn.bortzmeyer.fr TXT
…
;; ANSWER SECTION:
brisbane.now.weather.dyn.bortzmeyer.fr. 1800 IN TXT "Brisbane" "Partly cloudy" "27.0 C" "precipitation 0.17 mm" "wind 11.2 km/h" "cloudiness 25 %" "humidity 70 %"
brisbane.now.weather.dyn.bortzmeyer.fr. 1800 IN RRSIG TXT 8 6 1800 (
20240323040000 20240318154000 63937 dyn.bortzmeyer.fr.
gUXD/SnFywfzQVRstRH9t5k6DIGXLHUeuSgM8ShNfTUx
…
Alors, il n'est pas nécessaire d'essayer toutes les clés mais seulement celle(s)
qui ont un identificateur (keytag ou key id) de 63937 (il est indiqué dans la
signature, après les dates). Ce système est censé limiter le travail du
résolveur. Si un attaquant envoie cent clés, une seule sera utilisée. Mais, car
il y a un mais, ce keytag ne fait que deux octets (donc les collisions sont
relativement fréquentes) et surtout, ce n'est pas un condensat cryptographique
sûr, comme par exemple SHA-256. Il est facile pour un attaquant de générer cent
clés ayant le même keytag et celui-ci ne sert alors plus à rien, le malheureux
résolveur doit essayer toutes les clés.
Autre problème, pour l'attaquant (qui veut évidemment faire le plus de mal
possible), la taille de la réponse. En UDP, un client DNS typique ne va pas
accepter des réponses de plus de 4 096 octets, voire souvent 1 460 octets. Comme
l'attaquant veut fourrer le plus grand nombre possible de clés et de signatures
dans sa réponse, il a intérêt à utiliser les algorithmes à courbes elliptiques,
comme ECDSA, dont les clés et les signatures sont bien plus petites qu'avec RSA.
Maintenant, quelles sont les solutions ? Le rapport sur KeyTrap est plein de
phrases boursouflées comme « Solving these issues fundamentally requires to
reconsider the basics of the design philosophy of the Internet. » C'est
évidemment faux. Il faut simplement limiter le nombre d'opérations et/ou le
temps passé. C'est une nécessité général du DNS, bien antérieure à KeyTrap. Le
RFC 1035, en 1987, disait déjà « The amount of work which a resolver will do in
response to a client request must be limited to guard against errors in the
database, such as circular CNAME references, and operational problems, such as
network partition which prevents the resolver from accessing the name servers it
needs. While local limits on the number of times a resolver will retransmit a
particular query to a particular name server address are essential, the resolver
should have a global per-request counter to limit work on a single request. ».
L'oubli de ce paragraphe a déjà mené à des possibilités d'attaque par déni de
service comme l'attaque infinie, iDNS. La solution est donc évidente, limiter le
nombre de vérifications. Il y a une part d'arbitraire dans cette limite (stopper
au bout de trois clés ? de quatre ?) mais il est clair qu'il n'y a aucune raison
légitime de vérifier cent clés. C'est la modification qui a été faite dans tous
les résolveurs.
Noter que, pour l'exploitation de cette faille, il faut pouvoir parler au
résolveur, pour lui demander de résoudre un nom dans le domaine contrôlé par
l'attaquant, domaine qu'il aura rempli de clés et de signatures. C'est
évidemment facile pour un résolveur public, et pas trop difficile pour les gros
FAI, mais plus compliqué pour des petits résolveurs locaux. Donc, tout résolveur
validant était plus ou moins menacé. Ceci dit, tous les logiciels ont été
patchés très vite et tous les administrateurs système sérieux ont déjà appliqué
les patches.
Notez que cette attaque ne remet pas en cause l'importance de DNSSEC. Toute
technique de sécurité peut être (plus ou moins facilement) détournée pour en
faire une attaque par déni de service.
Quelques lectures :
* Le rapport originel. Très bon travail, très détaillé, sa lecture est
recommandée, il faut juste ignorer les nombreuses exagérations dramatiques.
Idem dans ce résumé d'une des auteures.
* Un bon résumé de Geoff Huston.
* L'attaque avait été documentée des années auparavant mais sans être
médiatisée, et était donc passé inaperçue.
* Coïncidence, le TLD .ru a connu au même moment une grande panne liée à une
collision de keytags
L'article seul
--------------------------------------------------------------------------------
IETF 119 HACKATHON: COMPACT DENIAL OF EXISTENCE FOR DNSSEC
First publication of this article on 18 March 2024
Last update on of 22 March 2024
--------------------------------------------------------------------------------
On March 16 and 17 was the IETF hackathon in Brisbane. I worked on a DNSSEC
feature called "compact denial of existence", and implemented it successfully
(which was easy).
Compact Denial of Existence (CDE) was originally called "black lies". The name
was changed, probably because of some typical US issue with every adjective of
color, but also because there was a risk of confusion with lying DNS resolvers,
which are something quite different. What is its purpose? For DNSSEC, you have
to sign your records. You can do it offline, on a primary name server (the
records and the signatures are then transferred to other authoritative name
servers), or online, in every authoritative name server. The first method is
more secure (you don't need the private key on every authoritative name server)
and uses less CPU resources but it is not usable if you have very dynamic
content, generated at every request. For this kind of content, you need online
signing.
Online signing of records does not raise any particular issue. The difficulty
starts with denial of existence, when you want to sign a statement that a name,
or a specific record type does not exist. In that case, you have no data to
sign. DNSSEC has several ways to deal with that and the simplest is NSEC
records. They are records created to say "there is no name between this one and
that one". Let's query a root name server to see these NSEC records:
% dig +dnssec @d.root-servers.net doesnotexist
…
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26586
…
;; AUTHORITY SECTION:
doctor. 86400 IN NSEC dog. NS DS RRSIG NSEC
doctor. 86400 IN RRSIG NSEC 8 1 86400 20240330170000 20240317160000 30903 . hZ08T19claSr8ZkU
…
You get a NXDOMAIN (No Such Domain), obviously, and a NSEC record (more than
one, actually, but I make things simple, but see later), which says that there
is no TLD between .doctor and .dog. This NSEC record is signed, proving that
.doesnotexist does not exist.
When signing a complete zone, creating the NSEC records is easy. But if we
generate DNS content dynamically, it is more tricky. The DNS server, when
signing, does not always know the previous name and the next name, it may not
have a complete view of the zone. A trick for dynamic signing was named "white
lies" and documented in RFC 4470. The idea is to generate dynamically a NSEC
with a previous name and a next name both very close from the requested name.
Something like (this is a real domain, you can try it yourself):
% dig +multi +dnssec +noidnout doesnotexist.dyn.bortzmeyer.fr
…
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61681
…
;; AUTHORITY SECTION:
~.doesnotexiss~.dyn.bortzmeyer.fr. 0 IN NSEC doesnotexist!.dyn.bortzmeyer.fr. RRSIG NSEC
~.doesnotexiss~.dyn.bortzmeyer.fr. 0 IN RRSIG NSEC 8 5 0 (
…
The names ~.doesnotexiss~.dyn.bortzmeyer.fr and doesnotexist!.dyn.bortzmeyer.fr
were choosen to be close enough of the requested name. This is not the exact
algorithm of RFC 4470 because I had problems with some resolvers but the general
idea is the same. (Also, +noidnout was added because dig has some ideas about
what is a displayable domain name. There are no IDN involved.) Here is how
Drink, the dynamic name server used in the hackathon, written in Elixir, did the
"white lies" trick:
previous = Drink.Dnssec.previous_name(domain)
nsec = %DNS.Resource{class: :in,
domain: to_charlist(DomainName.name(previous)),
type: @nsec,
data: Drink.Dnssec.nsec(domain, is_base)}
Now, what is the problem with this way of generating dynamic NSEC records? I
said before that you actually need two (and sometimes three) NSEC records
because you also need to prove that the name could not have been generated by a
wildcard. Each NSEC will require computation for its signature and, since all of
this is done in real-time, we wish to minimize the number of computations (and
the size of the response). Hence the Compact Denial of Existence (CDE, formerly
known as "black lies"). The idea is to have a NSEC record which does not go from
"a name just before" to "a name just after" but from "the requested name" to "a
name just after". This way, you no longer need to prove there was no wildcard
since you do not claim the name does not exist. (And this could be called a lie,
but, since it is done by the authoritative name server which, by definition,
tells the truth, the term is better left unused.) But it has an important
consequence, the response code must now be NOERROR and not NXDOMAIN, obscuring
the fact that the name does not "really" exist (something that some people at
the IETF did not like). Here is the result, as produced by Cloudflare name
servers:
% dig +multi +dnssec @ns4.cloudflare.com doesnotexist.cloudflare.com
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43367
…
;; AUTHORITY SECTION:
doesnotexist.cloudflare.com. 300 IN NSEC \000.doesnotexist.cloudflare.com. RRSIG NSEC TYPE65283
cloudflare.com. 300 IN RRSIG SOA 13 2 300 (
…
As you can see, the left-hand part of the record (the "owner name",
doesnotexist.cloudflare.com) is now set to the requested name. And the return
code is NOERROR, with no data returned in the Answer section. The response says
that the name exists, but only with RRSIG, NSEC and TYPE65283 - more on this one
later - records.
It should be noted that any ordinary, unmodified, validating resolver will have
no problem with this response. It will be validated. CDE does not require any
change to the resolver. Also, checking tools like DNSviz and Zonemaster will see
no problem. CDE can be deployed unilaterally, and this is exactly what
Cloudflare did.
So, as we saw, CDE is not new, even if it is not described in any RFC. It is
already deployed (remember that the Internet is permissionless: you do not need
a RFC to implement and deploy a technology). But what IETF is currently working
one is precisely a specification of this technique. The project is currently an
Internet-Draft, draft-ietf-dnsop-compact-denial-of-existence. This draft
describes the basic technique for generating the unique NSEC record and adds:
* In the list of record types that are present at the requested name (the "NSEC
bitmap"), a pseudo-type NXNAME, signaling that the NOERROR return code is
actually a NXDOMAIN. It is not officially allocated today and implementations
use a value reserved for experimentations, 65283 (hence the TYPE65283 above).
This can be used by resolvers to restore the NXDOMAIN from the response so
that their clients will have a proper error code.
* EDNS signaling that the client understands compact answers and can receive a
NXDOMAIN, it won't be surprised to see the NSEC claiming that the name does
not exist. This signaling is done with a bit called CO (for Compact OK).
During the IETF hackathon, two authoritative name servers were modified to
generate CDE:
* adns_server, written in Python.
* Drink, written in Elixir. The code is currently in a separate branch,
compact-denial (if you retrieved the code with git, git diff -u -r master -r
compact-denial will give you the code written during the hackathon).
In both cases, the work was simple and fast: once you have dynamic signing (it
was already in Drink), CDE is simpler than white lies. The two servers also
implemented the NXNAME reporting and accept the signaling via the CO bit. Here
is the result with Drink (this test domain was created for the hackathon, and no
longer works):
% dig +dnssec +multi nonono.ietf.bortzmeyer.fr TXT
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49495
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
…
nonono.ietf.bortzmeyer.fr. 0 IN NSEC \000.nonono.ietf.bortzmeyer.fr. \
RRSIG NSEC TYPE65283
nonono.ietf.bortzmeyer.fr. 0 IN RRSIG NSEC 8 4 0 (
20240321040000 20240316154000 43304
ietf.bortzmeyer.fr. …
…
As of today, no real resolver has been modified to implement NXDOMAIN
restoration and/or EDNS wignaling with CO. This is not mandatory, but would be
cool. Zonemaster was happy and so was DNSviz :
As usual, the hackathon pinpointed some issues that were not always noticed
before:
* Since the draft says that explicit requests for a NXNAME record are
forbidden, which error code should be returned and, if using EDE (Extended
DNS Errors, RFC 8914), which EDE? (Actually, the problem is larger than just
CDE since it seems that the replies to requests of pseudo-types - those
between 128 and 255 - are underspecified. May be another work to start.)
* When a DNS client does not set the DO bit, indicating it does not know about
DNSSEC, should we return NXDOMAIN, forgetting about CDE, like most
implementations do, or should we return NOERROR, as if the DO bit were set?
* This is not only about the non-DNSSEC clients: some people are not happy
that, by conflating NXDOMAIN and NOERROR, we lose information, and that will
make debugging more difficult (unless you have a NXDOMAIN-restoring resolver,
which does not exist today). It is important to remember that it is not
because something is simple to implement and works, that it is a good idea.
Thanks to Shumon Huque for code, conversation and explanations.
L'article seul
--------------------------------------------------------------------------------
FICHE DE LECTURE : LE LIBRE PENSÉE DANS LE MONDE ARABO-MUSULMAN
Auteur(s) du livre : Ouvrage collectif
Éditeur : Fédération de la Libre Pensée
978-2-916801-23-0
Publié en 2023
Première rédaction de cet article le 22 février 2024
--------------------------------------------------------------------------------
En France en 2024, le discours politique sur le monde arabo-musulman est souvent
fondé sur une assignation identitaire, qui suppose que toute personne élevée
dans un milieu musulman est forcément croyante, voire bigote, ou même islamiste.
La réalité est différente et le monde arabo-musulman a lui aussi ses libres
penseurs qui n'acceptent pas aveuglément les dogmes religieux, et encore moins
les humains qui les utilisent pour assoir leur pouvoir. Cet ouvrage rassemble un
certain nombre de contributions, très diverses, sur des libres penseurs dans
l'histoire du monde arabo-musulman.
Tout le monde a entendu parler d'Omar Khayyam, bien sûr. Mais la plupart des
autres libres penseurs décrits dans l'ouvrage sont nettement moins connus en
Occident. Ils ne forment pas un groupe homogène : certains sont athées, d'autres
simplement méfiants vis-à-vis de la religion organisée. Il faut aussi noter que
le livre couvre treize siècles d'histoire et une aire géographique très
étendue ; il n'est pas étonnant que la diversité de ces libres penseurs soit
grande. Le livre contient aussi des textes qui remettent en perspective ces
penseurs, par exemple en détaillant le mouvement de la Nahda ou bien en
critiquant le mythe de la tolérance religieuse qui aurait régné en al-Andalus.
Le livre est assez décousu, vu la variété des contributeurs. On va de textes
plutôt universitaires à des articles davantage militants (et certains sont assez
mal écrits, je trouve, et auraient bénéficié d'une meilleure relecture). Mais
tous ont le même mérite : tirer de l'oubli des libres penseurs souvent
invisibilisés comme Tahar Haddad ou Ibn al-Rawandi. Et vous apprendrez de toute
façon plein de choses (je ne connaissais pas le mutazilisme).
L'article seul
--------------------------------------------------------------------------------
Articles des différentes années : 2024 2023 2022 2021 2020 2019 2018
Précédentes années
Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le
contenu.
Un article de ce blog au hasard.
--------------------------------------------------------------------------------
Si vous aimez, vous pouvez payer avec Bitcoin : adresse
1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax (ou voyez le code QR). Pour toute remarque
sur ce blog, s'adresser par courrier à Stéphane Bortzmeyer
<stephane+blog@bortzmeyer.org> ou sur le fédivers à
bortzmeyer@mastodon.gougere.fr. Je suis les règles de Crocker donc pas besoin de
faire des excès de diplomatie. Ce blog est strictement personnel et les opinions
exprimées ici n'engagent donc que moi, et notamment pas mon employeur présent ou
mes employeurs passés ou mes éventuels employeurs futurs.