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.
Première rédaction de cet article le 13 juin 2024
Dernière mise à jour le 16 juin 2024
Le 12 juin, une panne (partielle ?) a touché
le TLD
.lr
. Il s'agit
d'un problème DNSSEC (qui a fait l'objet d'un
retex détaillé par le gestionnaire technique.
L'alerte a été donné sur la liste de l'OARC. Au matin du 13 juin, on constate :
.lr
. Principale exception : celui de
Cloudflare, 1.1.1.1
.Les sondes RIPE Atlas sont d'accord pour dire que ça marche mais pas parfaitement :
% blaeu-resolve --requested 200 --type SOA --displayvalidation lr [ (Authentic Data flag) rip.psg.com. hostmaster.psg.com. 1718251170 345600 3600 2592000 14400] : 88 occurrences [rip.psg.com. hostmaster.psg.com. 1718251170 345600 3600 2592000 14400] : 85 occurrences [ERROR: SERVFAIL] : 13 occurrences [ERROR: NXDOMAIN] : 11 occurrences [ (Authentic Data flag) rip.psg.com. hostmaster.psg.com. 1718225894 345600 3600 2592000 14400] : 1 occurrences [] : 1 occurrences Test #73322645 done at 2024-06-13T07:39:43Z
L'explication technique est probablement la suivante : en
interrogeant tous les serveurs faisant
autorité pour .lr
, avec la requête
lr/DNSKEY
, on voit que certains envoient deux
signatures (ayant le même identificateur de clé, 29984) :
lr. 86400 IN DNSKEY 257 3 8 ( AwEAAbdBaOsz0xNn+L+8+GopcC0w9NneWhKl9GJyCR5d … ) ; KSK; alg = RSASHA256 ; key id = 29984 lr. 86400 IN DNSKEY 256 3 8 ( AwEAAci9weuAQKBbKsqkOYnm1H0C5a7ZX/8xoQDmNp8Y … ) ; ZSK; alg = RSASHA256 ; key id = 42940 lr. 86400 IN RRSIG DNSKEY 8 1 86400 ( 20240626012025 20240611235025 29984 lr. YeZQ3KiSsDQD3jizNHXnTUYxRtzJwXl0aoctrgqDqajW … lr. 86400 IN RRSIG DNSKEY 8 1 86400 ( 20240626205813 20240612192813 29984 lr. lDt9P1RZtcs+/SDilJZ6tNRsZr+F5EdisfmsNw7E62+1 …
Cela ne se voit pas à l'œil nu mais une des deux signatures est invalide (cf. les rapports de DNSviz et Zonemaster). Les résolveurs qui réussissent sont ceux qui sont tombés sur le serveur faisant autorité qui ne servait que la bonne signature, ou bien testaient les deux signatures (d'où l'importance de tester plus qu'une signature, malgré KeyTrap). Notez que, malgré cette différence des réponses, tous les serveurs faisant autorité ont le même numéro de série :
% check-soa lr fork.sth.dnsnode.net. 77.72.229.254: OK: 1718251170 2a01:3f0:0:306::53: OK: 1718251170 ns-lr.afrinic.net. 196.216.168.61: OK: 1718251170 2001:43f8:120::61: OK: 1718251170 rip.psg.com. 2001:418:1::39: OK: 1718251170 147.28.0.39: OK: 1718251170
La commande pour interroger tous les serveurs est :
% for server in 77.72.229.254 2a01:3f0:0:306::53 2001:43f8:120::61 196.216.168.61 2001:418:1::39 147.28.0.39; do echo $server dig +dnssec @$server lr DNSKEY done > lr.txt
Comme elle est faite depuis un seul point de mesure (mon bureau), elle a ses limites, notamment, elle ne détectera pas les différences entre instances d'un même nuage anycast.
Y avait-il collision des identificateurs de clé comme en Russie en début d'année ? Comme vu plus loin, le problème était autre. Un indice : le Liban, qui a le même gestionnaire technique, avait le même problème.
Bref, les explications techniques complètes figurent dans cet article très détaillé ; une attaque par déni de service a déclenché une bogue assez bizarre dans le signeur, Knot.
Première rédaction de cet article le 7 juin 2024
Utiliser un résolveur DNS public est souvent nécessaire pour contourner la censure faite, notamment, au profit des ayant-tous-les-droits. Mais il ne faut pas que tout le monde se concentre sur deux ou trois gros résolveurs, surtout s'ils sont gérés depuis un pays qui se moque de la protection des données personnelles. Il faut au contraire une multiplicité de résolveurs DNS publics, et gérés depuis des pays divers. D'où l'intérêt de ce nouveau résolveur public géré aux Pays-Bas, DNS4ALL.
Merci donc à SIDN, registre de
.nl
, pour cette
contribution au pluralisme et à la diversité. (Il y a peu de
résolveurs DNS publics européens mais on peut citer celui de FDN ou celui de DNS.sb.) Peut-être que cela fera
enfin taire la propagande qui essaie de s'opposer à ces résolveurs
publics en faisant semblant de croire qu'il n'y a que ceux de
Google et
Cloudflare ?
Commençons par le commencement, est-ce qu'il marche ? Regardons avec dig :
% dig @2001:678:8::3 www.bortzmeyer.org ; <<>> DiG 9.18.24-1-Debian <<>> @2001:678:8::3 www.bortzmeyer.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20893 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;www.bortzmeyer.org. IN A ;; ANSWER SECTION: www.bortzmeyer.org. 86397 IN A 80.77.95.49 ;; Query time: 4 msec ;; SERVER: 2001:678:8::3#53(2001:678:8::3) (UDP) ;; WHEN: Fri Jun 07 11:05:20 CEST 2024 ;; MSG SIZE rcvd: 63
OK, il fonctionne (« status: NOERROR »), il donne bien la bonne réponse, et il valide avec DNSSEC (« flags: ad », ce qui veut dire Authentic Data). Ici, on a utilisé du DNS classique sur UDP, en clair, testons avec du DNS chiffré via TLS (kdig nous donne un peu plus de détails que dig, mais ce dernier marche aussi pour DNS sur TLS) :
% kdig +tls @2001:678:8::3 www.bortzmeyer.org ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 57888 ;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; www.bortzmeyer.org. IN A ;; ANSWER SECTION: www.bortzmeyer.org. 86259 IN A 80.77.95.49 ;; Received 63 B ;; Time 2024-06-07 11:07:37 CEST ;; From 2001:678:8::3@853(TCP) in 94.9 ms
Parfait, là aussi, on s'est connecté en TLS (authentifié par RSA, clés échangées par ECDHE, chiffré par AES). On peut donc utiliser ce résolveur de manière sécurisée. (Il a également DoH mais pas encore DoQ.)
Que se passe-t-il avec les domaines qui ont un problème technique, nous donne-t-il des détails ?
% dig +tls @2001:678:8::3 servfail.nl … ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40616 … ; EDE: 9 (DNSKEY Missing): (validation failure <servfail.nl. A IN>: signatures from unknown keys from 96.126.104.187 for <servfail.nl. SOA IN>) …
C'est à juste titre qu'il échoue (« status: SERVFAIL donc Server Failure) et il nous explique pourquoi en utilisant les EDE (Extended DNS Errors) du RFC 8914 : « signatures from unknown keys » (ce domaine sert à des tests et ses signatures DNSSEC sont délibérement cassées).
Bon, on utilise souvent les résolveurs publics pour contourner la censure mais certains peuvent aussi censurer. Je dois dire que j'ai été trop paresseux pour lire leur politique de censure et je me suis contenté de tester Sci-Hub (il n'est pas possible de tout vérifier, mais, si vous connaissez un nom censuré, vous pouvez le tester) :
% dig +tls @2001:678:8::3 sci-hub.se … ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20416 … ;; ANSWER SECTION: sci-hub.se. 60 IN A 186.2.163.219
Au moins Sci-Hub fonctionne (c'est l'adresse IP légitime).
Les gérants de ce service disent qu'il est anycasté, ce qui est une bonne chose mais vérifions avec les sondes Atlas :
% blaeu-resolve --requested 200 --nsid --tls --nameserver 2001:678:8::3 www.gouda.nl Nameserver 2001:678:8::3 [2001:9a8:a6:0:87:233:198:3 NSID: america-mex1;] : 24 occurrences [2001:9a8:a6:0:87:233:198:3 NSID: asia-sin1;] : 60 occurrences [2001:9a8:a6:0:87:233:198:3 NSID: eur-fra1;] : 106 occurrences [TIMEOUT] : 5 occurrences [NO RESPONSE FOR UNKNOWN REASON at probe 1006022] : 1 occurrences [TUCONNECT (may be a TLS negotiation error or a TCP connection issue)] : 1 occurrences [NO RESPONSE FOR UNKNOWN REASON at probe 62742] : 1 occurrences Test #73149926 done at 2024-06-07T09:18:33Z
On notera :
L'article cité mentionne que les nœuds utilisent dnsdist (qui a sa propre mémoire, donc n'envoie pas forcément aux résolveurs) et les résolveurs utilisent Unbound. (C'est amusant, c'est pareil pour mon propre résolveur public.)
Terminons avec un exemple de configuration où on utilise sur son réseau local ou sur sa machine un résolveur Unbound qui fait suivre les requêtes dont les réponses ne lui sont pas connues à DNS4ALL. On notera qu'on indique le nom du serveur, ce qui permet à Unbound de vérifier le certificat (dont le titulaire est « CN=*.dns4all.eu,O=Stichting Internet Domeinregistratie Nederland,ST=Gelderland,C=NL ») :
forward-zone: name: "." # DNS4ALL forward-addr: 2001:678:8::3#dot.dns4all.eu forward-tls-upstream: yes
En tout cas, voici un nouveau résolveur public (alors que le projet officiel de la Commission, DNS4EU, est toujours inexistant, des années après son annonce), ce qui contribue à accroitre la diversité des offres.
Première rédaction de cet article le 27 mai 2024
Les 25 et 26 mai 2024, à Lyon, c'étaient les Journées du Logiciel Libre. Comme toujours, deux jours passionnants avec plein de gens bien. J'y ai fait une conférence « Trouver de l'information sur un nom de domaine » et un atelier « Initiation à la programmation en Zig ».
La conférence « Trouver de l'information sur un nom de domaine » venait de l'observation que beaucoup d'internautes ont du mal à naviguer dans le monde, effectivement très complexe, des noms de domaine et, par exemple, à trouver de l'information correcte sur les données associées à un nom (comme l'identité du titulaire). Les outils pour cela sont parfois nommés collectivement RDDS (pour Registration Data Directory Services) et, si leur utilisation est parfois simple, l'interprétation de leurs résultats ne l'est pas. Voici les supports de la conférence (et leur source). Je n'ai pas compté le nombre de personnes présentes mais il m'a semblé que ce sujet suscitait l'intérêt.
Pour ce qui est de l'atelier sur le langage de programmation Zig, la forme choisie avait été celle d'une session où les participants (pas d'écriture inclusive ici, il n'y avait que des hommes) suivaient un support en ligne, faisaient les exercices et éventuellement posaient des questions. (Le source du support et l'ensemble des fichiers est disponible). À ma grande surprise, alors que je m'attendais à une participation très réduite, puisque le langage est peu connu, la salle était pleine comme un œuf (16 personnes) et avec tous ces humains et tous ces ordinateurs portables, plus les fixes pour ceux qui n'avaient pas apporté le leur, ça chauffait.
Parmi les autres activités du week-end (je n'ai pas tout fait, le programme était riche !), il y avait :
.coop
est réservé aux
coopératives et aux organismes qui en font la promotion. Le BE est
l'intermédiaire qui, par exempe pour un
.fr
, paie 5,07 € au
registre (l'Afnic) chaque année par nom. Le
futur bureau d'enregistrement nommé Le Bureau, devrait être sous
forme d'une coopérative. (Pour l'instant,
le projet semble largement porté par Hashbang.) Pour être BE de
.coop
, il faut l'accréditation ICANN (3500 $
+ 4000/an, « cinq salariés à temps plein suffisent », dit
l'ICANN), l'accréditation auprès du registre (qui n'est pas une
copérative…) et un contrat avec l'OTR (l'opérateur technique du registre). C'est très lourd et, a priori, le
futur BE commencera comme BE dans certains TLD, comme
.fr
mais sera sans doute au début simple
revendeur d'un BE pour .coop
,
.com
, etc. Notez que
je ne suis pas d'accord avec certains points de la présentation,
comme les pouvoirs excessifs prêtés à l'ICANN
(« L'organisation qui a le plus de pouvoir sur l'Internet est
l'ICANN » ou des phrases percutantes mais fausses comme « Si les
États-Unis veulent couper une zone géographique d'Internet ils
peuvent. »). Une beta privée du futur BE pourrait apparaitre à
l'automne.https://www.langtag.net/
.) Il y a aussi les
bases de données : Wiktionnaire, bien sûr
mais aussi Yiotta, le Dictionnaire
des francophones, ou bien Lingua Libre
et Common Voice pour l'audio… Il y a aussi les
outils plus techniques utilisés par les
linguistes professionels comme FLEx
(FieldWorks Language Explorer), qui sert à
décrire une langue (« usine à gaz qui bouffe toute la mémoire »
mais libre), ou ELAN, qui sert à
annoter de l'audio et de la vidéo. Un article
récent de LinuxFr discutait ces bases et ces outils.
Ah, et j'ai découvert aux JDLL l'existence du syndicat de la cybersécurité.
Cette année, le lieu historique des JDLL n'a pas accueilli l'événement. Il a fallu trouver rapidement un lieu alternatif et les JDLL se sont tenues à l'ENS. Le parc intérieur est superbe, et entretenu par des animaux consciencieux, dont la position est même donnée sur OpenStreetMap, avec l'émoji qui va bien 🐑 dans la description :
Et bien sûr mille mercis aux nombreux·ses bénévoles qui ont travaillé pour cette édition des JDLL, très réussie comme d'habitude.
Autre(s) compte-rendu(s) des JDLL publié(s) :
Première rédaction de cet article le 22 mai 2024
Dernière mise à jour le 23 mai 2024
On fait souvent remarquer que c'est pendant les pannes qu'on peut le mieux observer comment un système marche. Les perturbations qui affectent le serveur racine du DNS identifié par la lettre C sont donc l'occasion d'apprendre comment fonctionne ce système des serveurs racine.
À la racine du DNS, se trouvent treize serveurs (« serveur » au
sens virtuel car cela fait évidemment bien plus que treize
machines), chacun identifié par une lettre de A à M, et nommés dans
le domaine root-servers.net
. Un programme comme
check-soa
permet de les voir en action (l'option -i
permet d'avoir le temps de réponse), ici le 22 mai à 08:47:24
UTC :
% check-soa -i . a.root-servers.net. 2001:503:ba3e::2:30: OK: 2024052200 (14 ms) 198.41.0.4: OK: 2024052200 (15 ms) b.root-servers.net. 2801:1b8:10::b: OK: 2024052200 (14 ms) 170.247.170.2: OK: 2024052200 (14 ms) c.root-servers.net. 2001:500:2::c: OK: 2024052101 (25 ms) 192.33.4.12: OK: 2024052101 (25 ms) d.root-servers.net. 2001:500:2d::d: OK: 2024052200 (4 ms) 199.7.91.13: OK: 2024052200 (5 ms) e.root-servers.net. 192.203.230.10: OK: 2024052200 (6 ms) 2001:500:a8::e: OK: 2024052200 (6 ms) f.root-servers.net. 2001:500:2f::f: OK: 2024052200 (6 ms) 192.5.5.241: OK: 2024052200 (6 ms) g.root-servers.net. 2001:500:12::d0d: OK: 2024052200 (52 ms) 192.112.36.4: OK: 2024052200 (65 ms) h.root-servers.net. 2001:500:1::53: OK: 2024052200 (11 ms) 198.97.190.53: OK: 2024052200 (14 ms) i.root-servers.net. 192.36.148.17: OK: 2024052200 (10 ms) 2001:7fe::53: OK: 2024052200 (10 ms) j.root-servers.net. 2001:503:c27::2:30: OK: 2024052200 (15 ms) 192.58.128.30: OK: 2024052200 (14 ms) k.root-servers.net. 2001:7fd::1: OK: 2024052200 (8 ms) 193.0.14.129: OK: 2024052200 (14 ms) l.root-servers.net. 199.7.83.42: OK: 2024052200 (15 ms) 2001:500:9f::42: OK: 2024052200 (14 ms) m.root-servers.net. 2001:dc3::35: OK: 2024052200 (4 ms) 202.12.27.33: OK: 2024052200 (5 ms)
(Le point désigne la racine.)
Avez-vous remarqué le problème ? L'un des serveurs,
C.root-servers.net
, est en retard. Le numéro de
série dans l'enregistrement SOA est
2024052101 alors que tous les autres sont à 2024052200. Dans le cas
de la racine (c'est une convention courante mais pas du tout
obligatoire), le numéro de série indique la date de modification, on
voit donc qu'il est resté à hier, 21 mai.
C'était pire avant : du 18 au 21 mai, ce serveur est resté en 2024051801, ignorant donc tout changement qui aurait pu avoir lieu dans le contenu de la racine (heureusement, il n'y en a eu aucun pendant cette période) :
% date -u Tue 21 May 20:03:11 UTC 2024 % check-soa -i . a.root-servers.net. 198.41.0.4: OK: 2024052101 (23 ms) 2001:503:ba3e::2:30: OK: 2024052101 (96 ms) b.root-servers.net. 170.247.170.2: OK: 2024052101 (23 ms) 2801:1b8:10::b: OK: 2024052101 (84 ms) c.root-servers.net. 192.33.4.12: OK: 2024051801 (22 ms) 2001:500:2::c: OK: 2024051801 (22 ms) d.root-servers.net. 199.7.91.13: OK: 2024052101 (16 ms) 2001:500:2d::d: OK: 2024052101 (16 ms) e.root-servers.net. 192.203.230.10: OK: 2024052101 (16 ms) 2001:500:a8::e: OK: 2024052101 (16 ms) f.root-servers.net. 192.5.5.241: OK: 2024052101 (22 ms) 2001:500:2f::f: OK: 2024052101 (96 ms) g.root-servers.net. 2001:500:12::d0d: OK: 2024052101 (54 ms) 192.112.36.4: OK: 2024052101 (66 ms) h.root-servers.net. 198.97.190.53: OK: 2024052101 (23 ms) 2001:500:1::53: OK: 2024052101 (96 ms) i.root-servers.net. 192.36.148.17: OK: 2024052101 (23 ms) 2001:7fe::53: OK: 2024052101 (23 ms) j.root-servers.net. 192.58.128.30: OK: 2024052101 (23 ms) 2001:503:c27::2:30: OK: 2024052101 (96 ms) k.root-servers.net. 2001:7fd::1: OK: 2024052101 (23 ms) 193.0.14.129: OK: 2024052101 (22 ms) l.root-servers.net. 199.7.83.42: OK: 2024052101 (16 ms) 2001:500:9f::42: OK: 2024052101 (22 ms) m.root-servers.net. 2001:dc3::35: OK: 2024052101 (16 ms) 202.12.27.33: OK: 2024052101 (16 ms)
Le serveur C est anycasté donc le test ci-dessus laisse ouverte la possibilité d'un problème spécifique à l'instance à laquelle je parle. Mais une mesure faite avec les sondes RIPE Atlas montre que non, le problème touche presque toutes les instances :
% blaeu-resolve --requested 200 --nsid --type SOA --nameserver c.root-servers.net . Nameserver c.root-servers.net [NSID: lax1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 10 occurrences [NSID: fra1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 37 occurrences [NSID: mad1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 5 occurrences [NSID: rio1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 2 occurrences [NSID: fra1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 37 occurrences [NSID: iad1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 10 occurrences [NSID: lax1b.c.root-servers.org; … 2024052101 1800 900 604800 86400] : 8 occurrences [NSID: sin1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 3 occurrences [NSID: par1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 20 occurrences [NSID: par1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 20 occurrences [TIMEOUT] : 9 occurrences [NSID: mad1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences [NSID: iad1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 7 occurrences [NSID: sin1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences [NSID: bts1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 4 occurrences [NSID: ord1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 9 occurrences [NSID: jfk1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 1 occurrences [NSID: bts1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 6 occurrences [NSID: ord1b.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 3 occurrences [NSID: jfk1a.c.root-servers.org; … 2024051801 1800 900 604800 86400] : 2 occurrences [… 2024052100 1800 900 604800 86400] : 1 occurrences Test #72103734 done at 2024-05-21T20:15:03Z
Quelles sont les conséquences pratiques pour les
utilisateurices ? Si leur résolveur interroge C (ce qui dépend
d'un certain nombre de facteurs, dont le temps de réponse des
différents serveurs
faisant autorité), ledit résolveur aura des informations
peut-être dépassées. Ainsi, ce matin du 22 mai, on voit que le
TLD
.int
a publié hier un nouvel
enregistrement DS (dans le cadre de sa
migration vers la cryptographie en courbes
elliptiques) mais le serveur C ne le voit toujours pas :
% dig +short @a.root-servers.net int DS 59895 13 2 10C789F286599316D3A74C2C513434C3F8A33B9238976D5DE2A178E5 4DA353F3 27433 7 2 5864812D4DF2A4A455D905AF311389F479AFCD96FD369060941C7E17 0B40CA4F % dig +short @c.root-servers.net int DS 27433 7 2 5864812D4DF2A4A455D905AF311389F479AFCD96FD369060941C7E17 0B40CA4F
Un problème identique se pose pour
.gov
qui planifiait la
même transition vers ECDSA et a dû la
retarder. Cela sera encore pire si un TLD était redélégué ou
si les signatures DNSSEC servies par C
finissaient par expirer.
Que peut-on faire ? Pas grand'chose. Le gestionnaire du serveur C, Cogent va peut-être réparer mais on ne sait pas quand et on n'a pas d'informations. Techniquement, il serait possible de retirer C de la liste des serveurs racine ou bien de confier C à un autre opérateur, mais personne n'a le droit et/ou l'autorité de supprimer ou de réaffecter un serveur racine. Contrairement à ce qu'écrivent les journalistes, l'ICANN n'est pas régulateur du DNS, encore moins de l'Internet et ne peut donc pas agir. (La liste des serveurs et de leurs opérateurs est disponible en ligne.)
Le problème a finalement été réparé vers le 23 mai, d'abord sans explications et sans communication de la part de Cogent, puis finalement par un court texte sur leur site Web : « 2024‑05‑23 - On May 21 at 15:30 UTC the c-root team at Cogent Communications was informed that the root zone as served by c-root had ceased to track changes from the root zone publication server after May 18. Analysis showed this to have been caused by an unrelated routing policy change whose side effect was to silence the relevant monitoring systems. No production DNS queries went unanswered by c-root as a result of this outage, and the only impact was on root zone freshness. Root zone freshness as served by c-root was fully restored on May 22 at 16:00 UTC. ».
À noter qu'à peu près au même moment (mais nous ne savons pas
s'il s'agit d'une coïncidence ou bien si les deux problèmes sont
liés), le site Web d'information sur le serveur C,
(notez le
https://c.root-servers.org/
.org
alors que le
serveur DNS est en .net
)
avait cessé de fonctionner vers le 17 mai. Il utilisait l'adresse IP
38.230.3.4
, allouée à
Orange Côte d'Ivoire
et, depuis le 17 mai, annoncée
par eux dans BGP.
% whois 38.230.3.4 ... Found a referral to rwhois.cogentco.com:4321. %rwhois V-1.5:0010b0:00 rwhois.cogentco.com (CGNT rwhoisd 1.2.0) network:ID:NET4-26E6000011 network:Network-Name:NET4-26E6000011 network:IP-Network:38.230.0.0/17 network:Org-Name:Orange Cote d'Ivoire network:Street-Address:CABLE SAT3 CLS, RUA AMÉLIA FRADE network:City:SESIMBRA network:Country:PT network:Postal-Code:2970 – 712 network:Tech-Contact:ZC108-ARIN network:Updated:2024-05-10 16:33:20
Orange Côte d'Ivoire est un client de Cogent
et, manifestement, Cogent avait délégué ce préfixe à son client sans
remarquer qu'ils l'utilisaient pour
C.root-servers.org
. Ou bien ils ne s'étaient
pas aperçus du problème car, en interne, cela marchait, en
raison d'une route plus spécifique. (Quand j'ai signalé le
problème à Cogent, l'employé avait répondu que ça marchait pour
lui. De manière très peu professionnelle, il testait le service
depuis sa machine, sur le réseau interne de son employeur.)
Il n'y avait donc aucun détournement BGP, contrairement à ce qui a parfois été écrit, l'annonce d'Orange Côte d'Ivoire est parfaitement légitime. Le service Web a désormais une autre adresse IP et qui fonctionne, ce qui permet de voir le site et de constater qu'il n'y avait aucune information publiée avant le 23 mai :
(Merci à Bert Hubert pour avoir détecté le problème de
synchronisation du serveur DNS racine C, à Jan-Piet Mens pour avoir
détecté le problème avec le serveur Web
C.root-servers.org
et à Alarig Le Lay pour ses
explications sur le routage dans Cogent.)
Auteur(s) du livre : François Jarrige
Éditeur : La Découverte
9782-348-07671
Publié en 2023
Première rédaction de cet article le 17 mai 2024
Autrefois, on utilisait des « moteurs » animaux pour les travaux pénibles, puis on est passé aux moteurs à combustion interne, qui ont pris le dessus parce que, plus récents, ils étaient forcément meilleurs. Dans ce livre, François Jarrige montre que le remplacement des animaux par les machines aux 18e et 19e siècles a été plus compliqué que cela. Le « moteur animal » avait des avantages et le processus n'a pas été simple. C'est donc aussi un livre d'histoire des techniques et de leur déploiement.
Les chiffres indiquent en effet que c'est au 19e siècle et non pas au Moyen Âge qu'il y avait le plus d'animaux au travail dans les campagnes françaises. La révolution industrielle a d'abord conduit à une augmentation du travail animal, pour suivre l'évolution de la demande. Et puis l'auteur, à travers l'analyse de nombreux documents du passé, montre que le « progrès » n'est pas unilatéral. Les machines ont des défauts : le risque d'incendie (un risque sérieux dans une ferme en bois où on stocke du foin, ou dans une usine où on produit de l'alcool), le coût, notamment en capital, la nécessité de disposer de techniciens qualifiés pour soigner ces merveilleuses machines souvent en panne. De même qu'aujourd'hui, les gens qui travaillent dans un bureau vont souvent parcourir les couloirs à la recherche du sorcier informaticien qui va pouvoir remettre en service l'ordinateur mécontent, au 19e siècle, la machine à vapeur ou, plus tard, à pétrole, rendait les paysans ou les artisans dépendants de spécialistes rares et chers (alors que tout le monde savait s'occuper des animaux). Bref, si les animaux sont restés utilisés longtemps après l'arrivée des machines, ce n'était pas par conservatisme stupide des paysans (contrairement à ce qu'écrivaient des experts urbains méprisants dans des journaux) mais c'était souvent un choix rationnel.
Au bout du compte, les animaux effectuant un travail ont peu à peu disparu. Le 19e siècle a été également marqué par une plus grande sensibilité aux souffrances des animaux (qui travaillaient dans des conditions éprouvantes, comme les humains à l'époque, d'ailleurs). Est-il légitime de faire travailler les animaux ? Les promoteurs des machines, engins chers et difficiles à vendre, ont en tout cas saisi l'occasion de devenir défenseurs de la cause animale pour promouvoir leurs produits. Et les animaux de trait n'existent plus.
Auteur(s) du livre : Luc Bronner
Éditeur : Seuil
978.2.02.143954.0
Publié en 2020
Première rédaction de cet article le 13 mai 2024
Chaudun est un village en France. Ou plutôt un ex-village. Lassés de la dureté de la vie à Chaudun, tous ses habitants sont partis en 1895, après avoir vendu tout le village et ses terrains à l'État. Luc Bronner, dans ce livre très prenant, fait revivre ces habitants. Qui étaient-ils et comment vivaient-ils ? Partons pour une plongée dans les archives.
L'auteur a fait un travail extraordinaire, collectant les archives de l'état civil (Félicie Marin, décédée le 30 avril 1877, à l'âge de 17 ans), celles de l'Église (étonnant questionnaire envoyé aux curés de tout le département, écrit en français sauf une question en latin, je vous laisse lire pour trouver laquelle), celles de l'armée (descriptions détaillées du physique et de la taille des conscrits mais aussi beaucoup d'insoumis, marqués « parti en Amérique »), celles du conseil municipal (faut-il vraiment utiliser l'argent destiné aux « indigents » pour rembourser le mulet du facteur ?), celles de l'Éducation nationale (Chaudun était un « territoire perdu de la République » où on ne nommait que les enseignants qu'on voulait sanctionner), remontant aux cahiers de doléance… La misère du village se voit partout (mortalité infantile, émigration, lettres des curés et des instituteurs à leur supérieur demandant une mutation…). Il manque évidemment les témoignages des habitants, qui s'exprimaient peu, et dont l'auteur essaie de deviner les pensées, en marchant dans les ruines du village, ou en épluchant des vieux documents. Est-ce que vraiment les habitants continuaient à rendre un culte païen au Soleil, comme le prétend un religieux ?
À la fin du livre, on passe aux archives des Eaux & Forêts, qui ont pris les commandes et planté des arbres.
J'ai été très touché par ce livre, qui raconte tant d'histoires sur la France pauvre de l'époque. Au moins, toutes ces bureaucraties qui notaient et enregistraient ont un avantage : les habitants de Chaudun ne sont pas complètement oubliés et le travail minutieux du journaliste-historien permet de faire revivre une partie de leur vie. On saura ainsi les noms et la carrière des quatre curés qui ont exercé à Chaudun pendant la vie de Félicie Marin.
(Le livre décrit plusieurs photos de l'époque, qui ne sont pas reproduites mais qu'on peut trouver en ligne, avec également des photos récentes des ruines. Et si vous voulez randonner jusqu'aux ruines, suivez cette fiche.)
Date de publication du RFC : Mai 2024
Auteur(s) du RFC : K. Davis (Cisco Systems), B. Peabody (Uncloud), P. Leach (University of Washington)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF uuidrev
Première rédaction de cet article le 12 mai 2024
Ce RFC normalise les UUID, une famille d'identificateurs uniques, obtenus sans registre central. Il remplace l'ancienne norme, le RFC 4122, avec pas mal de nouveautés et un RFC complètement refait.
Les UUID, également connus autrefois sous le nom de GUID (Globally Unique IDentifiers), sont issus à l'origine du système des Apollo, adopté ensuite dans la plate-forme DCE. Les UUID ont une taille fixe, 128 bits, et sont obtenus localement, par exemple à partir d'un autre identificateur unique comme un nom de domaine, ou bien en tirant au hasard, la grande taille de leur espace de nommage faisant que les collisions sont très improbables (section 6.7 du RFC). Ce RFC reprend la spécification (bien oubliée aujourd'hui) de DCE de l'Open Group (ex-OSF) et ajoute la définition d'un espace de noms pour des URN (sections 4 et 7). (Il existe aussi une norme ITU sur les UUID et un registre des UUID, pour ceux qui y tiennent.)
Les UUID peuvent donc convenir pour identifier une entité sur le réseau, par exemple une machine mais aussi, vu leur nombre, comme identificateur unique pour des transactions (ce qui était un de leurs usages dans DCE). En revanche, ils ne sont pas résolvables, contrairement aux noms de domaine. Mais ils sont présents dans beaucoup de logiciels (Windows, par exemple, les utilise intensivement). On les utilise comme clé primaire dans les bases de données, comme identificateur de transaction, comme nom de machine, etc.
Les UUID peuvent se représenter sous forme d'un nombre binaire de
128 bits (la section 5 du RFC décrit les différents champs qui
peuvent apparaitre) ou bien sous forme texte. Sur
Unix, on peut fabriquer un UUID avec la
commande uuidgen
, qui affiche la représentation
texte standard que normalise notre RFC (section 4) :
% uuidgen 317e8ed3-1428-4ef1-9dce-505ffbcba11a % uuidgen ec8638fd-c93d-4c6f-9826-f3c71436443a
Sur Linux, vous pouvez aussi simplement
faire cat /proc/sys/kernel/random/uuid
. Sur une machine FreeBSD, un UUID de la
machine est automatiquement généré (par le script
/etc/rc.d/hostid
) et stocké dans le fichier
/etc/hostid
.
Pour l'affichage sous forme d'URN (RFC 8141), on ajoute
juste l'espace uuid
par exemple
urn:uuid:ec8638fd-c93d-4c6f-9826-f3c71436443a
. Il
a été ajouté au registre
IANA des espaces de noms des URN.
La section 4 du RFC détaille le format de l'UUID. En dépit des apparences, l'UUID n'est pas plat, il a une structure, mais il est très déconseillé aux applications de l'interpréter (section 6.12). Un des champs les plus importants est le champ Version (qui devrait plutôt s'appeler Type) car il existe plusieurs types d'UUID :
Ces différents types / versions figurent dans un registre IANA. Ce registre ne peut être modifié que par une action de normalisation (cf. RFC 8126).
uuidgen, vu plus haut, peut générer des UUID de
version 1 option -t
, de version 3
(-m
), de version 4 (c'est son comportement par
défaut, mais on peut utiliser l'option -r
si on
veut être explicite) ou de version 5 (-s
). Ici,
on voit les UUID fondés sur une estampille temporelle (version 1)
augmenter petit à petit :
% uuidgen -t 42ff1626-0fc7-11ef-8162-49e9505fb2f3 % uuidgen -t 4361fae8-0fc7-11ef-8162-49e9505fb2f3 % uuidgen -t 45381d02-0fc7-11ef-8162-49e9505fb2f3
Ici, dans le cas d'un UUID fondé sur un nom (version 3), l'UUID est stable (essayez chez vous, vous devriez obtenir le même résultat que moi), une propriété importante des UUID de version 3 et 5 :
% uuidgen -m -n @dns -N foobar.example 8796bf1a-793c-3c44-9ec5-a572635cd3d4 % uuidgen -m -n @dns -N foobar.example 8796bf1a-793c-3c44-9ec5-a572635cd3d4
Les espaces de noms sont enregistrés dans un
registre IANA, d'autres peuvent être ajoutés si on écrit une spécification
(cf. RFC 8126). Notez que chaque espace a son
UUID (6ba7b810-9dad-11d1-80b4-00c04fd430c8
pour
l'espace DNS).
Les UUID de version 6 et 7, nouveautés de ce RFC 9562, ne sont pas mis en œuvre par uuidgen, ni d'ailleurs par beaucoup d'autres programmes.
Les sections 6.1 et 6.2, elles, décrivent le processus de génération d'un UUID à base temporelle. Idéalement, il faut utiliser une graine enregistrée sur le disque (pour éviter de générer des UUID identiques) ainsi que l'instant de la génération. Mais lire sur le disque prend du temps (alors qu'on peut vouloir générer des UUID rapidement, par exemple pour identifier des transactions) et l'horloge de la machine n'a pas toujours une résolution suffisante pour éviter de lire deux fois de suite le même instant. Ces sections contiennent donc également des avis sur la génération fiable d'UUID, par exemple en gardant en mémoire le nombre d'UUID générés, pour les ajouter à l'heure.
La section 8, consacrée à la sécurité, rappelle qu'un UUID ne doit pas être utilisé comme capacité (car il est trop facile à deviner) et qu'il ne faut pas demander à un humain de comparer deux UUID (ils se ressemblent trop pour un œil humain).
Il est évidemment recommandé d'utiliser les UUID de version 5 plutôt que de version 3 (RFC 6151) mais SHA-1 a aussi ses problèmes (RFC 6194) et, de toute façon, pour la plupart des utilisations des UUID, les faiblesses cryptographiques de MD5 et de SHA-1 ne sont pas gênantes.
La section 2.1 du RFC détaille les motivations pour la mise à jour du RFC 4122 et quels sont les changements effectués. Certaines utilisations des UUID ont remis en cause des suppositions originales. Ainsi, les UUID sont souvent utilisés dans un contexte réparti, où leur capacité à être uniques sans registre central est très utile. Mais quelques points manquaient au RFC 4122 :
Seize mises en œuvre des UUID ont été étudiées pour préparer le nouveau RFC (vous avez la liste dans la section 2.1), menant aux constations suivantes :
En Python, il existe un module UUID qui offre des fonctions de génération d'UUID de différentes versions (mais pas les plus récentes) :
import uuid myuuid = uuid.uuid1() # Version 1, Time-based UUID heruuid = uuid.uuid3(uuid.NAMESPACE_DNS, "foo.bar.example") # Version # 3, Name-based ("hash-based") UUID, a name hashed by MD5 otheruuid = uuid.uuid4() # Version 4, Random-based UUID yetanotheruuid = uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.org") # Version 5, a name hashed by SHA1 if (myuuid == otheruuid or \ myuuid == heruuid or \ myuuid == yetanotheruuid or \ otheruuid == yetanotheruuid): raise Exception("They are equal, PANIC!") print(myuuid) print(heruuid) # Will always be the same print(otheruuid) print(yetanotheruuid) # Will always be the same
Et comme le dit la documentation, Note that uuid1() may compromise privacy since it creates a UUID containing the computer’s network address. (méthode de génération des UUID version 1 qui est désormais déconseillée).
Le SGBD PostgreSQL inclut un type UUID. Cela évite de stocker les UUID sous leur forme texte, ce qui est techniquement absurde et consomme 288 bits au lieu de 128 (section 6.13 du RFC).
essais=> CREATE TABLE Transactions (id uuid, value INT); CREATE TABLE essais=> INSERT INTO Transactions VALUES ('74738ff5-5367-5958-9aee-98fffdcd1876', 42); INSERT 0 1 essais=> INSERT INTO Transactions VALUES ('88e6441b-5f5c-436b-8066-80dca8222abf', 6); INSERT 0 1 essais=> INSERT INTO Transactions VALUES ('Pas correct', 3); ERROR: invalid input syntax for type uuid: "Pas correct" LINE 1: INSERT INTO Transactions VALUES ('Pas correct', 3); ^ -- PostgreSQL peut seulement générer la version 4, les aléatoires essais=> INSERT INTO Transactions VALUES (gen_random_uuid () , 0); INSERT 0 1 essais=> SELECT * FROM Transactions; id | value --------------------------------------+------- 74738ff5-5367-5958-9aee-98fffdcd1876 | 42 88e6441b-5f5c-436b-8066-80dca8222abf | 6 41648aef-b123-496e-8a4c-52e573d17b6a | 0 (3 rows)
Attention, le RFC (section 6.13) déconseille l'utilisation des UUID fondés sur un nom pour servir de clé primaire dans la base de données, sauf si on est absolument certain (mais c'est rare) que les noms ne changeront pas.
Il existe plusieurs exemples d'utilisation des UUID. Par exemple,
Linux s'en sert pour identifier les disques
attachés à la machine, de préférence à l'ancien système où l'ajout
d'un nouveau disque pouvait changer l'ordre des numéros sur le bus et
empêcher le système de trouver un disque. Un
/etc/fstab
typique sur Linux contient donc
des :
UUID=da8285a0-3a70-413d-baed-a1f48d7bf7b2 /home ext3 defaults ...
plutôt que les anciens :
/dev/sda3 /home ext3 defaults
car sda3
n'est pas un identificateur
stable. L'UUID, lui, est dans le système de fichiers et ne changera
pas avec les changements sur le bus. On peut
l'afficher avec dumpe2fs :
# dumpe2fs -h /dev/sda3 ... Filesystem UUID: da8285a0-3a70-413d-baed-a1f48d7bf7b2 ...
Un exemple d'utilisation de la nouvelle version 7 est décrit dans l'excellent article « Goodbye integers. Hello UUIDv7! ». Une mise en œuvre de cette version 7 apparait dans « UUIDv7 in 20 languages ».
La section 6 décrit les bonnes pratiques de génération d'un UUID. Ainsi :
Date de publication du RFC : Janvier 2024
Auteur(s) du RFC : M. Knodel, W. Hardaker, T. Pauly
Pour information
Première rédaction de cet article le 9 mai 2024
Aujourd'hui, l'essentiel du trafic sur l'Internet est chiffré, et pour d'excellentes raisons. Pas question de revenir là-dessus, mais, ceci dit, il va falloir adapter certaines pratiques de gestion des réseaux. L'IAB a organisé en 2022 un atelier sur ce sujet, dont ce RFC est le compte-rendu.
Comme les autres ateliers de l'IAB, il s'agit de faire s'exprimer diverses personnes, pas forcément d'arriver à une position commune (surtout sur un sujet… sensible). Tenu entièrement en ligne, cet atelier commençait par la soumission d'articles, qui devaient être lus d'abord, et discutés lors de l'atelier. La liste des articles figure dans l'annexe A du RFC, et les articles sont disponibles en ligne.
D'abord, notre RFC réaffirme que la cryptographie est absolument nécessaire à la protection de la vie privée. Les difficultés réelles qu'elle peut poser ne doivent jamais être un prétexte pour réduire ou affaiblir le chiffrement. Qu'il y ait une tension entre l'impératif du chiffrement et certaines méthodes de gestion du réseau, OK, mais la priorité reste la lutte contre la surveillance (RFC 7258).
Ensuite (section 1), le RFC pose le paysage : le trafic étant largement chiffré, des méthodes traditionnelles de gestion du réseau ne fonctionnent plus. tcpdump ne montre plus les données, on ne peut donc pas distinguer différentes méthodes HTTP, par exemple. Avec QUIC (RFC 9000), c'est même une partie de la couche transport qui est chiffrée donc un observateur extérieur ne peut plus, par exemple, évaluer le RTT d'une session qu'il observe (ce qui était possible avec TCP). Il va donc falloir s'adapter notamment en coopérant davantage avec les applications qui, elles, ont accès à tout. Pour l'instant, on a vu surtout passer des récriminations d'acteurs habitués à surveiller le trafic et qui se plaignent que le chiffrement les en empêchent (le RFC 8404 est un bon exemple de ces récriminations). Au contraire, il faut chercher à résoudre une contradiction : permettre aux réseaux d'appliquer leur politique sans céder d'un millimètre sur le principe du chiffrement.
Outre le cas des opérateurs réseau qui veulent examiner le trafic, à des fins louables (améliorer le réseau) ou critiquables (défavoriser certains usages), on peut aussi citer, parmi les intermédiaires qui voudraient observer et/ou interférer avec le trafic réseau, les réseaux d'entreprise qui veulent, par exemple, empêcher les employés d'accéder à certains services, ou bien les mécanismes de contrôle des enfants (appelés à tort « contrôle parental », alors que leur but est justement de remplacer les parents).
Trois thèmes importants étaient discutés à l'atelier : la situation actuelle, les futures techniques et la façon dont on pourrait arriver à déployer ces futures techniques.
Pour la situation actuelle, on sait que, depuis longtemps, les administrateurices réseau comptent sur de l'observation passive, par exemple pour classer le trafic (tant de HTTP, tant de SSH, etc). C'est à la base de techniques comme IPFIX (RFC 7011), qui permet de produire de beaux camemberts. Outre la production de rapports, cette observation passive peut (mais n'est pas forcément) être utilisée pour prévoir les évolutions futures, prioriser certains types de trafic, détecter des comportements malveillants, etc. Les protocoles Internet étaient en effet traditionnellement trop bavards, faisant fuiter des informations vers des observateurs passifs (cf. le concept de « vue depuis le réseau », RFC 8546).
La lutte
de l'épée et de la cuirasse étant éternelle, il y a évidemment eu
des travaux sur des mécanismes pour empêcher ce genre d'analyses
comme l'article soumis pour l'atelier « WAN
Traffic Obfuscation at Line Rate ». (Au passage,
sur cette idée d'obfuscation, je recommande le
livre de Brunton et Nissenbaum.)
Le RFC mentionne aussi une discussion sur l'idée d'exiger une
permission explicite des utilisateurs pour les analyses du trafic
(je ne vous dis pas les difficultés pratiques…). Voir
l'Internet-Draft
draft-irtf-pearg-safe-internet-measurement
.
Dans un monde idéal, le réseau et les applications coopéreraient (et, dans un monde idéal, licornes et bisounours s'embrasseraient tous les jours) mais on voit plutôt une lutte, le réseau essayant d'en savoir plus, les applications de préserver leur intimité. Pourtant, le RFC note qu'une coopération pourrait être dans leur intérêt réciproque. Bien sûr, des applications comme Tor refuseraient certainement toute coopération puisque leur but est de laisser fuiter le moins d'information possible, mais d'autres applications pourraient être tentées, par exemple en échange d'informations du réseau sur la capacité disponible. Après tout, certaines techniques sont justement conçues pour cela, comme ECN (RFC 3168).
OK, maintenant, quelles sont les techniques et méthodes pour résoudre le problème de la gestion des réseaux chiffrés (section 2.2) ? Le RFC exprime bien le fait que le but du chiffrement est d'empêcher tout tiers d'accéder aux informations. Donc, sauf faille de sécurité, par exemple suite à une faiblesse du chiffrement, tout accès à l'information impose la coopération d'une des deux parties qui communiquent. Cette question du consentement est cruciale. Si on n'a pas le consentement d'une des deux extrémités de la communication, on n'a pas le droit d'accéder aux données, point. Cf. la contribution « What’s In It For Me? Revisiting the reasons people collaborate ». Comme le répète souvent Eric Rescorla « Sur l'Internet, tout ce qui n'est pas une des extrémités est un ennemi. » (Cela inclut donc tous les équipements réseaux et les organisations qui les contrôlent.) Bref, les utilisateurs doivent pouvoir donner un consentement éclairé, et juger si les bénéfices de la visibilité l'emportent sur les risques. Évidemment, ce principe correct va poser de sérieuses difficultés d'application, car il n'est pas évident d'analyser proprement les bénéfices, et les risques (songez aux bandeaux cookies ou aux permissions des application sur votre ordiphone). Développer des nouveaux mécanismes de communication avec l'utilisateurice sont nécessaires, sinon, comme le note le RFC, « les ingénieurs devront choisir pour les utilisateurs ». Le RFC estime que les utilisateurs donneront toujours la priorité à leur vie privée (notamment parce qu'ils ne comprennent pas l'administration de réseaux et ses exigences), mais cela ne me semble pas si évident que cela. Personnellement, il me semble que le choix par défaut est crucial, car peu d'utilisateurices le modifieront.
Une des techniques qui permettent d'avoir accès à de l'information sans avoir toute l'information est celle des relais (cf. « Relying on Relays: The future of secure communication ». Le principe est de séparer les fonctions : l'utilisateur parle à un relais qui parle au serveur final. Le relais ne connait pas le contenu de la demande, le serveur ne connait pas le demandeur. C'est utilisé dans des techniques comme Oblivious HTTP (RFC 9458) ou Oblivious DNS (RFC 9230). La préservation de la vie privée est donc bien meilleure qu'avec, par exemple, un VPN, où l'opérateur du VPN voit tout, le demandeur et la demande (contrairement à ce que prétendent les publicités pour NordVPN que de nombreux youtubeurs transmettent avec leurs vidéos). Le relais permet donc un accès à une information limitée, ce qui permet d'assurer certaines fonctions (comme le filtrage de contenu malveillant) sans avoir un accès complet.
Un exemple souvent cité par les opérateurs de l'intérêt d'accéder à la communication et de la modifier est celui de l'optimisation des flux TCP. Des PEP (Performance Enhancing Proxies) violant le modèle en couches (car, normalement, TCP est de bout en bout) sont souvent déployés, notamment sur les liaisons satellites, dont les performances sont plus mauvaises, et les caractéristiques techniques très spéciales. (Cf. l'exposé de Nicolas Kuhn, « QUIC for satellite communications » à la Journée du Conseil Scientifique de l'Afnic en 2021.) Le PEP va modifier les en-têtes TCP, voire parfois boucler la connexion TCP et en faire une autre lui-même. Cette technique ne marche évidemment plus avec QUIC, qui chiffre même la couche transport. Et elle mène à l'ossification de l'Internet puisqu'elle rend plus difficile de faire évoluer TCP, car toute évolution risque de perturber les PEP. QUIC avait en partie été explicitement développé pour empêcher ces intermédiaires de bricoler la session. Une autre approche est celle proposée dans « The Sidecar: "Opting in" to PEP Functions ».
Bon, maintenant, comment arriver à déployer de meilleures méthodes ? Dans un environnement fermé ou semi-fermé, cela doit être possible de faire en sorte que, par exemple, toutes les machines mettent en œuvre telle fonction (cf. RFC 8520 pour un exemple). Mais cela ne marche clairement pas pour l'Internet.
Parmi les moyens proposés de résolution de la contradiction entre visibilité par le réseau et protection de la vie privée, le RFC mentionne les Zero-Knowledge Middleboxes. Décrites dans l'article du même nom, cette méthode utilise les preuves à divulgation nulle de connaissance pour prouver à l'intermédiaire qui fait le filtrage qu'on a bien respecté sa politique de filtrage, sans lui dire ce qu'on a fait. L'article détaille par exemple comment cela peut s'appliquer au DNS, qui est le principal outil de censure de l'Internet dans l'Union européenne. Ces preuves à divulgation nulle de connaissance ayant toujours été mystérieuses pour moi, je ne vous expliquerai pas comment elles marchent, mais notez que les auteurs ont fait un article pédagogique.
Enfin, le RFC mentionne la proposition Red Rover, qui propose encore un arrangement bisounours où les utilisateurs et les opérateurs collaboreraient pour un filtrage géré en commun. Les auteurs disent que ça marcherait car les utilisateurs « ne veulent probablement pas violer les CGU » (ben si : ils veulent utiliser Sci-Hub même si c'est censuré).
En conclusion, le RFC note en effet qu'on peut être sceptique quant aux chances d'une solution négociée. Mais il met aussi en avant le fait qu'il va être très difficile de trouver une solution qui marche pour toute la variété des réseaux. Et que l'expérience prouve largement que toute nouvelle technique va avoir des effets inattendus et que, par exemple, une solution qui visait à donner aux opérateurs des informations utiles pour la gestion de réseaux, va parfois être détournée pour d'autres buts.
Sinon, sur la question du déboguage des applications dans un monde où tout est chiffré, j'avais fait un exposé à Capitole du Libre.
Date de publication du RFC : Mars 2024
Auteur(s) du RFC : P. Hoffman (ICANN), K. Fujiwara
(JPRS)
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 3 mai 2024
Comme beaucoup de protocoles très utilisés sur l'Internet, le DNS est ancien. Très ancien (la première norme, le RFC 882, date de 1983). Les normes techniques vieillissent, avec l'expérience, on comprend mieux, on change les points de vue et donc, pour la plupart des protocoles, on se lance de temps en temps dans une révision de la norme. Mais le DNS est une exception : la norme actuelle reste fondée sur des textes de 1987, les RFC 1034 et RFC 1035. Ces documents ne sont plus à jour, modifiés qu'ils ont été par des dizaines d'autres RFC. Bref, aujourd'hui, pour comprendre le DNS, il faut s'apprêter à lire de nombreux documents. En attendant qu'un courageux et charismatique participant à l'IETF se lance dans la tâche herculéenne de faire un jeu de documents propre et à jour, ce RFC 9499, successeur du RFC 8499 (il y a peu de modifications), se limite à une ambition plus modeste : fixer la terminologie du DNS. Ce n'est pas un tutoriel : vous n'y apprendrez pas le DNS. C'est plutôt une encyclopédie.
En effet, chacun peut constater que les discussions portant sur le DNS sont difficiles : on manque de terminologie standard, et celle des RFC officielles ne suffit pas, loin de là. Souvent, le DNS a tellement changé que le RFC officiel est même trompeur : les mots ne veulent plus dire la même chose. D'autres protocoles ont connu des mises à jour de la norme. Cela a été le cas de SMTP, passé successivement du RFC 772 à l'actuel RFC 5321, en passant par plusieurs révisions successives. Ou de XMPP, qui a vu sa norme originale mise à jour dans le RFC 6120. Et bien sûr de HTTP, qui a connu plusieurs toilettages complets (cf. RFC 9110). Mais personne n'a encore osé faire pareil pour le DNS. Au moins, ce RFC 9499, comme son prédécesseur RFC 8499, traite l'un des problèmes les plus criants, celui du vocabulaire. Le RFC est évidemment en anglais, les traductions proposées dans cet article, et qui n'ont pas de valeur « officielle » sont de moi seul.
Notre RFC 9499 rassemble donc des définitions pour des termes qui étaient parfois précisément définis dans d'autres RFC (et il fournit alors un lien vers ce RFC original), mais aussi qui n'étaient définis qu'approximativement ou parfois qui n'étaient pas définis du tout (et ce RFC fournit alors cette définition). Du fait du flou de certains RFC anciens, et des changements qui ont eu lieu depuis, certaines définitions sont différentes de l'original. Le document a fait l'objet d'un consensus relatif auprès des experts DNS mais quelques termes restent délicats. Notez aussi que d'autres organisations définissent des termes liés au DNS par exemple le WHATWG a sa définition de ce qu'est un domaine, et le RSSAC a développé une terminologie.
Ironiquement, un des termes les plus difficiles à définir est
« DNS » lui-même (section 1 de notre RFC). D'accord, c'est le sigle
de Domain Name System mais ça veut dire quoi ?
« DNS » peut désigner le schéma de nommage (les noms de domaine comme
signal.eu.org
, leur syntaxe, leurs
contraintes), la base de données répartie (et faiblement cohérente)
qui associe à ces noms des informations (comme des certificats, des
adresses IP, etc), ou le
protocole
requête/réponse (utilisant le port 53) qui permet d'interroger cette
base. Parfois, « DNS » désigne uniquement le protocole, parfois,
c'est une combinaison des trois éléments indiqués plus haut
(personnellement, quand j'utilise « DNS », cela désigne uniquement
le protocole, un protocole relativement simple, fondé sur l'idée
« une requête => une réponse »).
Bon, et ces définitions rigoureuses et qui vont mettre fin aux discussions, ça vient ? Chaque section du RFC correspond à une catégorie particulière. D'abord, en section 2, les noms eux-même, ces fameux noms de domaine. Un système de nommage (naming system) a plusieurs aspects, la syntaxe des noms, la gestion des noms, le type de données qu'on peut associer à un nom, etc. D'autres systèmes de nommage que celui présenté dans ce RFC existent, et sont distincts du DNS sur certains aspects. Pour notre système de nommage, le RFC définit :
www.madmoizelle.com
), le vocabulaire s'en
ressent. Par exemple, on va dire que com
est « au-dessus de
madmoizelle.com
» (vision arborescente) ou
bien « à la fin de www.madmoizelle.com
»
(vision texte). Notez aussi que la représentation des noms de
domaine dans les paquets IP n'a rien à voir avec leur représentation
texte (par exemple, les points n'apparaissent pas). Enfin, il faut
rappeler que le vocabulaire « standard » n'est pas utilisé
partout, même à l'IETF, et qu'on voit parfois « nom de domaine »
utilisé dans un sens plus restrictif (par exemple uniquement pour
parler des noms pouvant être résolus avec le DNS, pour lesquels il
avait été proposé de parler de DNS
names).ldap.potamochère.fr.
est un FQDN alors que
ldap
tout court ne l'est pas). En toute
rigueur, un FQDN devrait toujours s'écrire avec un point à la fin
(pour représenter la racine) mais ce n'est pas toujours le
cas. (Notre RFC parle de « format de présentation » et de « format
courant d'affichage » pour distinguer le cas où on met
systématiquement le point à la fin et le cas où on
l'oublie.)www.laquadrature.net
, il y a trois
composants, www
,
laquadrature
et
net
.brienne.tarth.got.example
peut être un nom
de machine mais www.&#$%?.example
ne
peut pas l'être. Le terme de « nom de machine » est parfois
aussi utilisé pour parler du premier composant d'un nom de
domaine (brienne
dans
brienne.tarth.got.example
).fr
ou
name
sont des TLD. N'utilisez surtout pas le terme erroné
d'« extension ». Et ne dites pas que le TLD est le
composant le plus à droite, ce n'est pas vrai dans
l'alphabet arabe. La distinction courante
entre gTLD, gérés par l'ICANN, et
ccTLD, indépendants de l'ICANN, est
purement politique et ne se reflète pas dans le DNS.www.cl.cam.ac.uk
est un sous-domaine de
cl.cam.ac.uk
, qui est un sous-domaine de
cam.ac.uk
et ainsi de suite, jusqu'à la
racine, le seul domaine à n'être sous-domaine de
personne. Quand le RFC parle de suffixe, il s'agit d'un suffixe
de composants, pas de caractères :
foo.example.net
n'est pas un sous-domaine
de oo.example.net
.vader IN CNAME anakin
, l'alias est
vader
(et c'est une erreur de dire que
c'est « le CNAME »).anakin
est le CNAME,
le « nom canonique ».Fini avec les noms, passons à l'en-tête des messages DNS et aux codes qu'il peut contenir. Cet en-tête est défini dans le RFC 1035, section 4.1. Il donne des noms aux champs mais pas forcément aux codes. Ainsi, le code de réponse 3 indiquant qu'un domaine demandé n'existe pas est juste décrit comme name error et n'a reçu son mnémonique de NXDOMAIN (No Such Domain) que plus tard. Notre RFC définit également, dans sa section 3 :
Voici un renvoi depuis la racine vers .fr
:
% dig @l.root-servers.net A blog.imirhil.fr ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16572 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 11 ... ;; AUTHORITY SECTION: fr. 172800 IN NS d.ext.nic.fr. fr. 172800 IN NS d.nic.fr. fr. 172800 IN NS e.ext.nic.fr. fr. 172800 IN NS f.ext.nic.fr. fr. 172800 IN NS g.ext.nic.fr.
La section 4 s'intéresse aux transactions DNS. Un des termes définis est celui de QNAME (Query NAME), nouveauté du RFC 8499. Il y a trois sens possibles (le premier étant de très loin le plus commun) :
Le RFC 2308 est clairement en tort ici. Il aurait dû utiliser un terme nouveau, pour le sens nouveau qu'il utilisait.
Passons maintenant aux enregistrements DNS, stockés dans cette base de données répartie (section 5 du RFC) :
Voici un ensemble d'enregistrements (RRset), comptant ici deux enregistrements :
rue89.com. 600 IN MX 50 mx2.typhon.net. rue89.com. 600 IN MX 10 mx1.typhon.net.
(Depuis, ça a changé.)
Et voici un pseudo-enregistrement OPT, tel qu'affiché par dig, avec une indication de la taille maximale et l'option client subnet (RFC 7871) :
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ; CLIENT-SUBNET: 13.176.144.0/24/0
Ensuite, un sujet chaud où le vocabulaire est particulièrement peu défini, et très mal utilisé (voir les forums grand public sur le DNS où les discussions prennent un temps fou car les gens utilisent mal les mots) : les différents types de serveurs et clients DNS (section 6). Pour commencer, il est crucial de se méfier quand un texte parle de « serveur DNS » tout court. Si le contexte ne permet pas de savoir de quel genre de serveur DNS on parle, cela indique un manque de compréhension du DNS par l'auteur du texte. Serveurs faisant autorité et serveurs résolveurs, quoique utilisant le même protocole, sont en effet très différents.
getaddrinfo()
ou
getnameinfo()
. Sur
Unix, le résolveur minimum fait en
général partie de la libc et trouve l'adresse du ou des résolveurs
complets dans /etc/resolv.conf
.f.root-servers.net
fait autorité pour la
racine, d.nic.fr
fait autorité pour
pm
,
etc. Des logiciels comme NSD ou Knot assurent cette fonction. Les serveurs
faisant autorité sont gérés par divers acteurs, les registres, les
hébergeurs DNS (qui sont souvent en même temps bureaux
d'enregistrement), mais aussi parfois par
M. Michu. La commande dig NS $ZONE
vous
donnera la liste des serveurs faisant autorité pour la zone
$ZONE
. Ou bien vous pouvez utiliser un
service sur le Web en visitant
https://dns.bortzmeyer.org/DOMAIN/NS
où
DOMAIN est le nom de domaine qui vous intéresse.NS .
» à un des serveurs de sa
liste. Ainsi, tant qu'au moins un des serveurs de la vieille
liste répond, le résolveur est sûr d'apprendre la liste
actuelle./etc/resolv.conf
le
serveur primaire ») n'a pas de sens.forwarders
). La définition de notre RFC est
le premier sens.www.organisation.example
aille sur le site
public quand on vient de l'Internet mais sur un site interne de
la boîte quand on est sur le réseau local des employés.Voici, vu par tcpdump, un exemple d'initialisation d'un résolveur BIND utilisant la racineYeti (RFC 8483) :
15:07:36.736031 IP6 2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6.35721 > 2001:6d0:6d06::53.53: \ 21476% [1au] NS? . (28) 15:07:36.801982 IP6 2001:6d0:6d06::53.53 > 2a01:e35:8bd9:8bb0:21e:8cff:fe76:29b6.35721: \ 21476*- 16/0/1 NS yeti-ns.tisf.net., NS yeti-ns.lab.nic.cl., NS yeti-ns.wide.ad.jp., NS yeti.ipv6.ernet.in., NS yeti-ns.as59715.net., NS ns-yeti.bondis.org., NS yeti-dns01.dnsworkshop.org., NS dahu2.yeti.eu.org., NS dahu1.yeti.eu.org., NS yeti-ns.switch.ch., NS bii.dns-lab.net., NS yeti.bofh.priv.at., NS yeti-ns.conit.co., NS yeti.aquaray.com., NS yeti-ns.ix.ru., RRSIG (619)
La question était « NS .
» (quels sont les
serveurs de la racine) et la réponse contenait les noms des seize
serveurs racine qu'avait Yeti à l'époque.
Voici aussi des exemples de résultats avec un résolveur ou bien avec un serveur faisant autorité. Si je demande à un serveur faisant autorité (ici, un serveur racine), avec mon client DNS qui, par défaut, demande un service récursif (flag RD, Recursion Desired) :
% dig @2001:620:0:ff::29 AAAA www.iab.org ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54197 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ... ;; AUTHORITY SECTION: org. 172800 IN NS b0.org.afilias-nst.org. ...
C'est pour cela que dig affiche WARNING: recursion requested but not available. Notez aussi que le serveur, ne faisant autorité que pour la racine, n'a pas donné la réponse mais juste un renvoi aux serveurs d'Afilias. Maintenant, interrogeons un serveur récursif (le service de résolveur public Yandex DNS) :
% dig @2a02:6b8::feed:0ff AAAA www.iab.org ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63304 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ... ;; ANSWER SECTION: www.iab.org. 1800 IN AAAA 2001:1900:3001:11::2c
Cette fois, j'ai obtenu une réponse, et avec le
flag RA, Recursion
Available. Si je pose une question sans le
flag RD (Recursion Desired,
avec l'option +norecurse
de dig) :
% dig +norecurse @2a02:6b8::feed:0ff AAAA www.gq.com ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59438 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ... ;; ANSWER SECTION: www.gq.com. 293 IN CNAME condenast.map.fastly.net.
J'ai obtenu ici une réponse car l'information était déjà dans le cache (la mémoire) de Yandex DNS (on le voit au TTL, qui n'est pas un chiffre rond, il a été décrémenté du temps passé dans le cache). Si l'information n'est pas dans le cache :
% dig +norecurse @2a02:6b8::feed:0ff AAAA blog.keltia.net ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19893 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ...
Je n'obtiens alors pas de réponse (ANSWER: 0, donc NODATA). Si je demande au serveur faisant autorité pour cette zone :
% dig +norecurse @2a01:e0d:1:3:58bf:fa61:0:1 AAAA blog.keltia.net ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62908 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 15 ... ;; ANSWER SECTION: blog.keltia.net. 86400 IN AAAA 2a01:240:fe5c:1::2 ...
J'ai évidemment une réponse et, comme il s'agit d'un serveur faisant autorité, elle porte le flag AA (Authoritative Answer, qu'un résolveur ne mettrait pas). Notez aussi le TTL qui est un chiffre rond (et qui ne change pas si on rejoue la commande).
Passons maintenant à un concept relativement peu connu, celui de zones, et le vocabulaire associé (section 7) :
gouv.fr
n'est pas une zone séparée, il
est dans la même zone que fr
(cela se teste
facilement : gouv.fr
n'a pas
d'enregistrement NS ou de SOA).wikipedia.org
est org
, le parent de
.org
est la racine.ns1.mazone.example
, le résolveur doit
passer par les serveurs de mazone.example
,
qui est déléguée à ns1.mazone.example
et
ainsi de suite... On rompt ce cercle vicieux en ajoutant, dans
la zone parente, des données qui ne font pas autorité sur les
adresses de ces serveurs (RFC 1034,
section 4.2.1). Il faut donc bien veiller à les garder
synchrones avec la zone fille. (Tanguy Ortolo me suggère
d'utiliser « enregistrement de raccord » plutôt que
« colle ». Cela décrit bien leur rôle, en effet.)ip6.arpa
ou sous les
domaines très longs de certains CDN. Cela se trouve aussi avec les
enregistrements de service : dans
_sip._tcp.example.com
,
_tcp.example.com
est probablement un
ENT. La réponse correcte à une requête DNS pour un ENT est
NODATA (code de réponse NOERROR, liste des répoonses vide) mais
certains serveurs bogués, par exemple, à une époque, ceux
d'Akamai, répondaient NXDOMAIN.
Voyons ici la colle retournée par un serveur faisant autorité (en
l'occurrence un serveur de .net
) :
% dig @a.gtld-servers.net AAAA labs.ripe.net ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18272 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9 ... ;; AUTHORITY SECTION: ripe.net. 172800 IN NS ns3.nic.fr. ripe.net. 172800 IN NS sec1.apnic.net. ripe.net. 172800 IN NS sec3.apnic.net. ripe.net. 172800 IN NS tinnie.arin.net. ripe.net. 172800 IN NS sns-pb.isc.org. ripe.net. 172800 IN NS pri.authdns.ripe.net. ... ;; ADDITIONAL SECTION: sec1.apnic.net. 172800 IN AAAA 2001:dc0:2001:a:4608::59 sec1.apnic.net. 172800 IN A 202.12.29.59 sec3.apnic.net. 172800 IN AAAA 2001:dc0:1:0:4777::140 sec3.apnic.net. 172800 IN A 202.12.28.140 tinnie.arin.net. 172800 IN A 199.212.0.53 tinnie.arin.net. 172800 IN AAAA 2001:500:13::c7d4:35 pri.authdns.ripe.net. 172800 IN A 193.0.9.5 pri.authdns.ripe.net. 172800 IN AAAA 2001:67c:e0::5
On notera :
pri.authdns.ripe.net
: ce serveur étant
dans la zone qu'il sert, sans son adresse IP, on ne pourrait
jamais le joindre.sec1.apnic.net
. Ce n'est pas
strictement indispensable (on pourrait l'obtenir par une
nouvelle requête), juste une optimisation.ns3.nic.fr
et
sns-pb.isc.org
ne sont pas renvoyées. Le
serveur ne les connait probablement pas et, de toute façon,
elles seraient hors-bailliage, donc ignorées par un résolveur prudent.Voyons maintenant, un ENT,
gouv.fr
(notez que, depuis, ce domaine n'est
plus un ENT) :
% dig @d.nic.fr ANY gouv.fr ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42219 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
Le serveur fait bien autorité pour ce domaine (flag AA dans la réponse), le domaine existe (autrement, le status aurait été NXDOMAIN, pas NOERROR) mais il n'y a aucun enregistrement (ANSWER: 0).
Et, ici, une délégation boiteuse, pour
.ni
:
% check-soa ni dns.nic.cr. 2001:13c7:7004:1::d100: ERROR: SERVFAIL 200.107.82.100: ERROR: SERVFAIL ns.ideay.net.ni. 186.1.31.8: OK: 2013093010 ns.ni. 165.98.1.2: ERROR: read udp 10.10.86.133:59569->165.98.1.2:53: i/o timeout ns.uu.net. 137.39.1.3: OK: 2013093010 ns2.ni. 200.9.187.2: ERROR: read udp 10.10.86.133:52393->200.9.187.2:53: i/o timeout
Le serveur dns.nic.cr
est déclaré comme
faisant autorité pour .ni
mais il ne le sait
pas, et répond donc SERVFAIL.
Les jokers ont une section à eux, la section 8 du RFC. S'appuyant sur le RFC 4592, elle définit, entre autres :
*
dans
une zone déclenche la synthèse automatique de réponses pour les
noms qui n'existent pas dans la zone. Si la zone
foo.example
contient
bar.foo.example
et
*.foo.example
, une requête pour
thing.foo.example
renverra le contenu de
l'enregistrement avec le joker, une requête pour
bar.foo.example
donnera les données de
bar.foo.example
. Attention,
l'astérisque n'a son rôle particulier
que s'il est le composant le plus spécifique (le premier). Dans
foo.*.bar.example
, il n'y a pas de
joker.foo.bar.baz.example
n'existe pas, que
bar.baz.example
n'existe pas non plus,
mais que baz.example
existe, alors
baz.example
est l'ancêtre le plus proche
de foo.bar.baz.example
. Ce concept est
nécessaire pour le RFC 5155.Allez courage, ne faiblissons pas, il reste encore la question de l'enregistrement des noms de domaine (section 9) :
bortzmeyer.org
😁.
C'est le registre qui décide de la politique d'enregistrement,
qui peut être très variable selon les zones (sauf dans celles
contrôlées par l'ICANN, où une certaine
uniformité est imposée). Mes lecteurs français noteront que,
comme le terme « registre » est court et largement utilisé, le
gouvernement a inventé
un nouveau mot, plus long et jamais vu auparavant,
« office d'enregistrement »..aquarelle
se trouve dans la
Public Suffix List alors qu'il
s'agit d'un « .marque
», un de ces TLD où
une seule entreprise peut enregistrer des noms. Le terme est ancien mais est apparu
pour la première fois dans un RFC avec le RFC 6265, section 5.3. com
, co.uk
et
eu.org
sont des suffixes publics. Rien dans la syntaxe du nom n'indique
qu'un nom de domaine est un suffixe public, puisque ce statut ne
dépend que d'une politique d'enregistrement (qui peut
changer). Il est parfaitement possible qu'un domaine, et un de
ses enfants, soient tous les deux un suffixe public (c'est le
cas de .org
et
eu.org
).
Prenons par exemple le domaine eff.org
. Au
moment de la publication du RFC :
Enfin, pour terminer, les sections 10 et 11 de notre RFC couvrent DNSSEC. Pas grand'chose de nouveau ici, DNSSEC étant plus récent et donc mieux défini.
L'annexe A de notre RFC indique quelles définitions existaient dans de précédents RFC mais ont été mises à jour par le nôtre. (C'est rare, puisque le but de ce RFC de terminologie est de rassembler les définitions, pas de les changer.) Par exemple, la définition de QNAME du RFC 2308 est corrigée ici.
L'annexe B liste les termes dont la première définition formelle se trouve dans ce RFC (ou dans un de ses prédécesseurs, les RFC 7719 et "RFC 8499). Cette liste est bien plus longue que celle de l'annexe A, vu le nombre de termes courants qui n'avaient jamais eu l'honneur d'une définition stricte.
Notre RFC ne contient pas une liste exhaustive des changements depuis son prédécesseur, le RFC 8499, mais ils sont peu importants. Parmi les changements sérieux :
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é :
L'enregistrement vidéo n'est pas encore disponible.
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) comme 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 :
+00:00
indiquait qu'on utilisait UTC
comme référence (identique au cas précédent),-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.
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 :
_er
,_er
(oui, encore),
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) :
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) :
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 :
La section 2 du RFC détaille les sujets qui étaient dans le programme de l'atelier :
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 :
Et les actions concrètes (section 2.4.3) ?
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 :
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.
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
,
itself a copy of https://data.iana.org/time-zones/tzdb/leap-seconds.list
,
itself made by the Paris observatory)
so you don't need the programs like
https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list
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.
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.
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.
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 :
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 :
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.
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 :
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 :
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 :
Facile, me direz-vous ? Non, construire ces machines va nécessiter de s'attaquer à quelques problèmes physiques :
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 :
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.
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.