Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

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.


Le nouveau type de données DNS WALLET

Première rédaction de cet article le 19 juillet 2024


Contrairement au cliché mille fois répété (mais faux), le DNS ne sert pas qu'à « traduire des noms de domaine en adresses IP ». Il est d'un usage général et permet de récupérer, indexées par un nom de domaine, diverses informations. Un nouveau type d'information vient d'être officiellement enregistré, WALLET, pour indiquer l'adresse d'un portefeuille de cryptomnnaie.

La capacité du DNS à résoudre un nom de domaine en divers types d'informations vient d'un champ des requêtes et réponses DNS, le type (ou, en plus long, le RR type, pour Resource Record type). Décrit dans la section 3.2.2 du RFC 1035, ce type peut prendre des valeurs diverses : AAAA pour les adresses IP, SVCB pour les serveurs d'un service donné, LOC pour une position, TXT pour du texte libre, etc.

Il est important de noter que cette liste des types possibles n'est pas figée. Elle est enregistrée dans un registre IANA et on peut ajouter des types à ce registre, en suivant la procédure décrite dans le RFC 6895. Cette procédure est délibérement très légère : le demandeur documente le nouveau type, envoie la demande à l'IANA, celle-ci la fait examiner par un expert (actuellement Ólafur Guðmundsson) et s'il n'y a pas de problèmes, le nouveau type est enregistré. Bien que la procédure soit libérale, on ne peut pas dire qu'il y ait eu une bousculade depuis la sortie du RFC 6895, la plupart des types enregistrés ayant suivi un chemin plus classique de normalisation.

Mais le nouveau WALLET, désormais ajouté au registre IANA, a utilisé le chemin simple ; une documentation, un examen par l'expert et hop, c'est enregistré. Comme les types ont un numéro en plus de leur nom (c'est ce numéro qui figure dans les paquets DNS), le 262 a été alloué. Que contient un enregistrement DNS de type WALLET ? Deux champs, une chaine de caractères qui identifie la cryptomonnaie utilisée (BTC pour Bitcoin, ETH pour Ethereum, etc) et une autre chaine de caractères qui contient l'adresse d'un compte.

L'encodage dans les paquets est identique à celui des enregistrements de type TXT : une suite de chaines de caractères est encodée en un octet qui indique la longueur de la chaine puis la suite d'octets de la chaine. Ainsi, "BTC" (pour Bitcoin) sera encodé {3, 66, 84, 67}, les trois derniers octets étant les codes ASCII.

J'ai ainsi ajouté au DNS mon adresse Bitcoin, sous bortzmeyer.fr. Mais attention, comme le type WALLET est récent (créé le 21 juin 2024), la plupart des logiciels ne le connaissent pas. Pour le mettre dans le fichier de zone du serveur primaire, j'ai dû utiliser la méthode des « types inconnus » du RFC 3597 :

@ IN	TYPE262	\# 39 03425443 223148744E4A365A465563397975397532714177423474476447775051617351476178
  

(39 octets, le premier groupe fait trois octets, les trois lettres de "BTC", regardez la table ASCII.) Et c'est également ainsi que dig l'affichera (le type WALLET n'étant pas connu, il a fallu donner son numéro, 262) :


% dig bortzmeyer.fr TYPE262
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26302
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
bortzmeyer.fr.		86400 IN TYPE262 \# 39 ( 03425443223148744E4A365A46556339797539753271
				4177423474476447775051617351476178 )
…

  

Pour le formater plus joliment, en attendant que dig soit mis à jour, j'ai écrit un petit script en Python (utilisant la bibliothèque dnspython) :

% wallet-dns.py bortzmeyer.fr
bortzmeyer.fr
Code: BTC ; Address: 1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax
  

Et voilà, l'adresse est joliment affichée. (Une gestion assez minimale de ce type est en cours de développement dans dnspython.)

PS : il existe aussi cette alternative.


L'article seul

RFC 9537: Redacted Fields in the Registration Data Access Protocol (RDAP) Response

Date de publication du RFC : Mars 2024
Auteur(s) du RFC : J. Gould, D. Smith (VeriSign), J. Kolker, R. Carney (GoDaddy)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 14 juillet 2024


RDAP est le protocole recommandé pour accéder aux données sociales sur un nom de domaine, comme le nom du titulaire ou son adresse postale. Pour d'évidentes raisons de vie privée, certains registres ne renvoient pas la totalité de l'information dont ils disposent. Que doit-on mettre dans RDAP dans ce cas ? La question n'était pas tranchée et chaque registre faisait différemment. Désormais, il existe un solution normalisée.

Au passage, oui, d'accord, il n'y a pas que RDAP pour obtenir les données sociales (cet article vous en indiquera d'autres). Mais c'est le service le plus moderne et le plus adapté aux programmeur·ses. Contacté en HTTPS, le serveur RDAP va renvoyer du JSON que le client n'aura plus qu'à filtrer et formatter. Voici par exemple une partie de la réponse RDAP obtenue en se renseignant sur nouveaufrontpopulaire.fr :

% curl -s https://rdap.nic.fr/domain/nouveaufrontpopulaire.fr | jq
…
          [
            "fn",
            {},
            "text",
            "Parti Socialiste"
          ],
          [
            "org",
            {},
            "text",
            "Parti Socialiste"
          ],
          [
            "adr",
            {},
            "text",
            [
              "",
              "",
              "99 Rue Moliere",
              "Ivry-sur-Seine",
              "",
              "94200",
              "FR"
            ]
          ],
…
  

Ici, il s'agit d'une personne morale donc les données sont toutes envoyées. Et s'il s'agissait d'une personne physique, pour laquelle la loi Informatique & et Libertés s'applique, depuis 1978 ? La solution évidente est de ne pas envoyer les données qu'on ne veut pas diffuser mais attention, il y a un piège, il ne faut pas casser la syntaxe JSON. Par exemple, RDAP utilise (c'est en cours de changement, cf. RFC 9553) jCard pour formater les adresses (RFC 7095) et les champs dans jCard ne sont pas étiquetés, c'est leur position dans le tableau qui indique leur rôle (c'est un des nombreux inconvénients de jCard). On ne peut donc pas supprimer, par exemple, la rue, en indiquant :

[
            "adr",
            {},
            "text",
            [
              "",
              "",
              "Ivry-sur-Seine",
              "",
              "94200",
              "FR"
            ]
],
          [
            "email",
            {},
            "text",
            "e5d92838d5f0268143ac47d86880b5f7-48916400@contact.gandi.net"
          ],

Car, alors, on ne saurait plus si "Ivry-sur-Seine" est la rue ou bien la ville.

Le principe de notre RFC est donc : si on peut, retirer le membre JSON. Si on ne peut pas (cas du tableau de taille fixe), mettre une valeur vide ou null.

Petit point de terminologie : comment traduire le redacted du titre ? « Censuré » est inadapté (l'intervention ne vient pas d'un tiers mais d'une des deux parties). Je vais dire « élidé », mais « caviardé », « biffé » et « expurgé » sont également de bonnes solutions. Le nom correspondant est « élision ». Évidemment, il ne faut surtout pas dire « anonymisé », il n'y a rien d'anonyme ici, puisque le registre connait toute l'information, il refuse simplement de la diffuser.

La section 1 du RFC expose les grands principes de l'élision. Elle explique notamment qu'en cas d'élision, il faut ajouter un membre (nommé redacted) à la réponse JSON, expliquant les raisons et utilisant le langage JSONPath (RFC 9535) pour désigner de manière formelle la partie élidée.

Compte-tenu des contraintes sur la syntaxe de la réponse JSON (RFC 9083), le RFC normalise quatre façons d'élider (section 3) :

  • Suppression d'un champ, si possible (c'est la méthode préférée). Cela marche dans la plupart des cas. Par exemple, si on ne veut pas publier le titulaire d'un domaine, on ne l'inclut pas dans la réponse, point.
  • Mettre une valeur vide. Quand les contraintes de syntaxe empêchent de supprimer complètement un champ, on lui met une valeur vide. C'est notamment nécessaire pour les tableaux que jCard utilise abondamment : le retrait d'un champ casserait le tableau, qui est censé avoir un nombre d'élements fixe.
  • Une valeur trop détaillée peut être remplacée par une valeur partielle. L'adresse "label":"123 Maple Ave\nSuite 901\nVancouver BC\nCanada" (un exemple du RFC 7095) peut être remplacée par une valeur moins précise comme "label":"Vancouver\nBC\nCanada\n".
  • Enfin, la dernière méthode est de remplacer une valeur par une autre, par exemple une adresse de courrier par une adresse qui masque la vraie, comme e5d92838d5f0268143ac47d86880b5f7-48916400@contact.gandi.net dans l'exemple plus haut.

Et le RFC insiste qu'il ne faut pas utiliser de texte bidon (« XXX », « lorem ipsum dolor » ou « Ano Nymous ») car ce texte ne correspond pas forcément aux règles de syntaxe du champ (et, j'ajoute, peut être difficile à identifier pour le lecteur, qui peut ne pas avoir la référence).

Pour la première méthode, la suppression d'un champ, si on supprime le titulaire, on aura un membre nommé redacted (élidé) ajouté ainsi :

    "redacted": [
     {
       "name": {
         "description": "Remove registrant"
       },
       "prePath": "$.entities[?(@.roles[0]=='registrant')]",
       "method": "removal"
     }
     ]
  

Notez le (difficile à lire) code JSONPath $.entities[?(@.roles[0]=='registrant')].

Le deuxième cas, celui d'une valeur vide, donnerait, pour le cas où on supprime juste le nom du titulaire (qui est en position 1 dans le jCard, et son nom en position 3 - sachant qu'on part de 0) :

   [
     "fn",
     {},
     "text",
     ""
   ]
   …
      "redacted": [
     {
       "name": {
         "description": "Registrant Name"
       },
       "postPath": "$.entities[?(@.roles[0]=='registrant')].
         vcardArray[1][?(@[0]=='fn')][3]",
       "pathLang": "jsonpath",
       "method": "emptyValue",
       "reason": {
         "description": "Server policy"
       }
     }
     ]
     

Troisième technique d'élision, réduire une valeur. Le redacted devient :

   
   "redacted": [
     {
       "name": {
         "description": "Home Address Label"
       },
       "postPath": "$.vcardArray[1][?(@[0]=='adr')][1].label",
       "pathLang": "jsonpath",
       "method": "partialValue",
       "reason": {
         "description": "Server policy"
       }
     }
   ]
  

Et pour finir, la quatrième et dernière méthode, le remplacement :

   "redacted": [
     {
       "name": {
         "description": "Registrant Email"
       },
       "postPath": "$.entities[?(@.roles[0]=='registrant')].
                  vcardArray[1][?(@[0]=='email')][3]",
       "pathLang": "jsonpath",
       "method": "replacementValue",
     }
     ]
  

Ce membre appelé redacted est spécifié en détail dans la section 4 du RFC. (Et il est enregistré à l'IANA parmi les extensions RDAP.) Pour signaler qu'il peut apparaitre, le membre rdapConformance de la réponse JSON va l'indiquer :

{
  "rdapConformance": [
    "itNic",
    "redacted",
    "rdap_level_0"
  ],
…

Dès qu'il y a élision, redacted doit être ajouté. Il contient un tableau JSON d'objets, dont les membres peuvent être (seul le premier est obligatoire) :

  • name : un terme qui décrit le champ élidé,
  • prePath et postPath : des expressions JSONPath (RFC 9535) qui dénotent le membre retiré ou modifié,
  • method : la technique d'élision utilisée (suppression, nettoyage, remplacement, etc),
  • reason : texte libre décrivant la raison de l'élision.

Téléchargez le RFC 9537


L'article seul

Passage de mes zones DNS à des signatures à courbes elliptiques

Première rédaction de cet article le 6 juillet 2024


Vous l'avez peut-être remarqué, mes zones DNS personnelles (comme bortzmeyer.org, que vous utilisez pour lire ce blog) viennent de changer d'algorithme de signature cryptographique. RSA a été remplacé par ECDSA.

Pourquoi ce grand remplacement ? Les signatures DNSSEC faites avec ECDSA (RFC 6605) sont plus petites, ce qui peut présenter des avantages dans certains cas (mais ne va évidemment pas diminuer l'empreinte environnementale de mes zones). Mais, surtout, l'avis de la grande majorité des experts en cryptographie (je ne fais pas partie de ces experts, très loin de là, donc je leur fais confiance) est que la cryptographie sur courbes elliptiques, qui est à la base d'ECDSA, est plus sûre, surtout face aux futures évolutions de la cryptanalyse, que le traditionnel RSA. Vous noterez d'ailleurs que beaucoup de zones DNS importantes ont changé, par exemple .com. De même, .fr a migré il y a plusieurs années et c'est uniquement la paresse qui m'avait jusque là empêché d'en faire autant. (La racine du DNS, elle, est toujours en RSA, car il est bien plus compliqué de changer une clé que tous les résolveurs de la planète doivent connaitre, et ce malgré le RFC 5011.)

J'ai un peu hésité à passer à ECDSA car il dépend d'une courbe elliptique, la P-256, conçue par la NSA et normalisée par le NIST, et à utiliser plutôt EdDSA (RFC 8080). Mais, autant tous les résolveurs DNSSEC acceptent aujourd'hui aussi bien ECDSA que RSA, autant Ed25519 reste moins répandu.

Une fois la décision prise, comment faire ? Comme toujours avec le DNS, il faut tenir compte du fait que la réjuvénation n'est pas instantanée. Si on change brutalement les clés qu'on publie, on risque que certains résolveurs aient encore dans leur mémoire des clés qui ne valideront pas les signatures récentes (ou bien le contraire). Que l'on change les clés ou, comme ici, les algorithmes, il faut procéder à ce remplacement (rollover) en intégrant les contraintes temporelles (RFC 6781 et RFC 7583).

Suivre manuellement ces contraintes (ajouter la nouvelle clé, attendre le TTL, ajouter l'enregistrement DS dans la zone parente, attendre qu'il soit publié, attendre le TTL, retirer l'ancien DS, attendre, retirer l'ancienne clé…) est pénible et le risque d'erreur est très élevé. Il faut donc automatiser, ce que j'ai fait. Mes zones DNS personnelles sont gérées avec OpenDNSSEC et c'est donc lui qui a fait tout le travail.

Prenons l'exemple de la zone cyberstructure.fr. DNSviz va nous montrer ses différents états (l'archivage des anciennes mesures et la facilité de navigation dans cet historique font partie des grandes forces de DNSviz). Elle était signée uniquement avec RSA. (Les erreurs signalées par DNSviz sont dues au non-respect du RFC 9276, j'y reviendrai.) Le 17 juin 2024, je change la configuration OpenDNSSEC. Dans ce logiciel, chaque zone gérée l'est selon une politique choisie par l'administrateur système. La politique utilisée, nommée default était d'utilise RSA. Je crée une nouvelle politique, nommée, sans imagination, new. Dans la syntaxe XML du fichier de configuration d'OpenDNSSEC, le fichier kasp.xml contient :


<Policy name="new">
<Description>A new policy with ECDSA</Description>
…
                <Keys>
                        …
                        <!-- Parameters for KSK only -->
                        <KSK>
                                <Algorithm length="512">13</Algorithm>
                                <Lifetime>P3Y</Lifetime>
                                <Repository>SoftHSM</Repository>
                                <ManualRollover/>
                        </KSK>

                        <!-- Parameters for ZSK only -->
                        <ZSK>
                                <Algorithm length="512">13</Algorithm>
                                <Lifetime>P90D</Lifetime>
                                <Repository>SoftHSM</Repository>
                                <!-- <ManualRollover/> -->
                        </ZSK>
                </Keys>
…

  

L'algorithme de numéro 13 est ECDSA (RSA est le numéro 8, cf. le registre IANA). On change ensuite la configuration de la zone (dans zonelist.xml) :


<Zone name="cyberstructure.fr">
    <Policy>new</Policy>
    …

On recharge alors OpenDNSSEC :

% sudo ods-enforcer zonelist import                            
…
Updated zone cyberstructure.fr successfully

Les nouvelles clés ECDSA (rappel : algorithme 13) sont alors créées par OpenDNSSEC :

% sudo ods-enforcer key list --verbose --zone cyberstructure.fr
Keys:
Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
cyberstructure.fr               KSK      active    2024-06-18 10:53:01      2048  8          2d63a8cc9f68602d5b98f2bcb2714119 SoftHSM     63130
cyberstructure.fr               ZSK      active    2024-06-18 10:53:01      1024  8          b8e16f9a3aad96676ae36cd6fdb955ad SoftHSM     11668
cyberstructure.fr               KSK      publish   2024-06-18 10:53:01      512   13         02e0ddf994431d5fa3d89cdc12f7addd SoftHSM     10825
cyberstructure.fr               ZSK      ready     2024-06-18 10:53:01      512   13         cebc635b489780d2fddf5efabeba5b81 SoftHSM     54500

Elles n'apparaissent pas dans le DNS immédiatement, il faut attendre leur passage en état ready (regardez la colonne Date of next transition). Une fois que c'est fait, DNSviz nous montre le nouvel état, avec pour l'instant les clés ECDSA publiées mais qui ne seront pas utilisées pour la validation. rollover-cs-1.png

Pensez aussi à recharger le signeur d'OpenDNSSEC (ods-sign update --all). Dans le DNS, on note que les deux ZSK (Zone-signing key) signent (même si, pour l'instant, les signatures ECDSA ne servent à rien) :


% dig @ns4.bortzmeyer.org. cyberstructure.fr SOA
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18279
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 8, ADDITIONAL: 1
…
;; ANSWER SECTION:
cyberstructure.fr.	7200 IN	SOA ns4.bortzmeyer.org. hostmaster.bortzmeyer.org. (
				2024061703 ; serial
				7200       ; refresh (2 hours)
				3600       ; retry (1 hour)
				604800     ; expire (1 week)
				3600       ; minimum (1 hour)
				)
cyberstructure.fr.	7200 IN	RRSIG SOA 13 2 7200 (
				20240701143938 20240617155301 54500 cyberstructure.fr.
				CW/V6zSkMn/cC8E2hUHYlaSparKbOgc03CRcbOecTOMY
				HxMTavaExj9fvvkH3srNrP9Kx/VYRQsi4YrjMFH6DA== )
cyberstructure.fr.	7200 IN	RRSIG SOA 8 2 7200 (
				20240701143938 20240617155301 11668 cyberstructure.fr.
				UCskHbeGjx20Bqo+9IyczDaHrEZ83uBYQsjDy/Etqngy
				QeCH1gADMbsl3VaBPHiLDd8MIVkzH2I73/jEUo2R22wq
				KPtSTsGHQ8I2vPff5ylplqJFXVUitiyGcEYVaAtI3hAk
				eijaGI6J3nAdcYuAxFo9Gi+WRCEmTRcL8RZAjCo= )
 

On voit notamment que la signature ECDSA est plus petite, ce qui était une des motivations pour ce remplacement. Et les clés ?



% dig @ns4.bortzmeyer.org. cyberstructure.fr DNSKEY
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51884
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
cyberstructure.fr.	7200 IN	DNSKEY 257 3 8 (
				AwEAAddHCFxVIpXyRRVCBh4zHt22o3ReQzk+Avi5J+c2
				hLnB2zSB7obXWsxj0fZSeyYE4VAClJ5/7TF687gRjVRW
				3cNTsJ9mrQzbLbuxL3nnIKWZRrVKWg9RpKHDul9QL1EC
				trgum18SK9QpRnywZx8kM0zFviu75Df2636wT1YcQZUz
				KDXRE0IGg6r9qGMcq6PXL3woDPoVmv3H7SvXZjlj/2zI
				nMvQo15Y0Y7kO6Epng9qgnJaZeTrTo4OtzIPMSOahFMJ
				YD8AxlsT5yN7lQZSRMJDYjJ1HC+PgyLMnz7y+iwvVLMZ
				6IVr1yeYbCp+inTHi+qn9fRJSIjirWJWb/7sHdk=
				) ; KSK; alg = RSASHA256 ; key id = 63130
cyberstructure.fr.	7200 IN	DNSKEY 256 3 8 (
				AwEAAcGW9K353z/T1ZKstnQ4Y0ricKlmb2DyVEE0Dcrc
				St/fNVdB3g2Y9tlXh9oQH0RzNK2UqIAm2PxmAleeWOZp
				8qzYdtWZj5O/4VXtLkjAwOUuinjaYIfDskcuue/pg+cT
				ilQhXnh/sKktyci4wtFIDZLBL7gYyiZSFrR4DCwcpITr
				) ; ZSK; alg = RSASHA256 ; key id = 11668
cyberstructure.fr.	7200 IN	DNSKEY 257 3 13 (
				zyVnEtBlrgWpNtDUnhPIikEIUaAj+/VwHfC7j1jpWeqa
				fAE04Mx9nXDFhznhDD0uvIFpY3se9wefPddNZJDVCA==
				) ; KSK; alg = ECDSAP256SHA256 ; key id = 10825
cyberstructure.fr.	7200 IN	DNSKEY 256 3 13 (
				s+HVObz03Vzug26yX3KjlyXbpMcCzoD/8CblfTR2zQsi
				e35hf2DBwLarHOCcMpu6X5+FgHMsOwmvaSJH/AzZCA==
				) ; ZSK; alg = ECDSAP256SHA256 ; key id = 54500
cyberstructure.fr.	7200 IN	RRSIG DNSKEY 13 2 7200 (
				20240701061231 20240617155301 10825 cyberstructure.fr.
				EbgfiMIxj2zhVgnAD2MPf4fZ6PZjCT4iZMhMgUb6EK/m
				o8foczgd9PFotvcaaQxaE6rybMiOvhRETbIrX9IeCA== )
cyberstructure.fr.	7200 IN	RRSIG DNSKEY 8 2 7200 (
				20240701061231 20240617155301 63130 cyberstructure.fr.
				qTI+5RbOnuWfpkXgTSiYEv04An19XjxP1vGyYEnD5ao0
				zaexw3yh1xhNGlsqFU1XLkADTilpt1w60qO/9lshE3kD
				eA73s6u03hsrLxL71YjvUEU68pO/iT4LxhpYY0P1gCPX
				rdiM50mYauiSQROnt5UeQ0wJ/Q4NSl4fQrko1cHcymcD
				05JeCS4e2gq7HlCQsn2rTQTwP2A0d9ccYBe02rPziTP4
				HnyEAcBqATHPU1U+yqd5OZLYkJh+mGJTFFHoXfxYSqKu
				6C86KVV5wtrX+bCxcNGrdRiyGI0FSDioXQG7p1+/oLYf
				j6vQnfns9INHEH2uY6P6LdJX4GTFKq3gpg== )

;; Query time: 0 msec
;; SERVER: 2001:4b98:dc0:41:216:3eff:fe27:3d3f#53(ns4.bortzmeyer.org.) (UDP)
;; WHEN: Mon Jun 17 18:53:46 CEST 2024
;; MSG SIZE  rcvd: 1048

Ouf, ça en fait, des données à envoyer. Mais ce n'est que transitoire.

À la prochaine étape (tout se déroule automatiquement et est géré par OpenDNSSEC), la clé ECDSA est prête :

% sudo ods-enforcer key  list --verbose --zone cyberstructure.fr
Keys:
Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
cyberstructure.fr               KSK      retire    waiting for ds-gone      2048  8          2d63a8cc9f68602d5b98f2bcb2714119 SoftHSM     63130
cyberstructure.fr               ZSK      active    2024-09-15 18:53:01      1024  8          b8e16f9a3aad96676ae36cd6fdb955ad SoftHSM     11668
cyberstructure.fr               KSK      ready     waiting for ds-seen      512   13         02e0ddf994431d5fa3d89cdc12f7addd SoftHSM     10825
cyberstructure.fr               ZSK      active    2024-09-15 18:53:01      512   13         cebc635b489780d2fddf5efabeba5b81 SoftHSM     54500

Maintenant, il va falloir travailler, l'étape suivante ne peut pas être automatisée. Il faut prévenir la zone parente (dans le cas de .fr, via le BE) et indiquer à OpenDNSSEC (qui ne sait pas faire de requête DNS lui-même) quand l'enregistrement DS arrivera. On lui demande d'exporter la clé :

% sudo ods-enforcer key  export --zone cyberstructure.fr  

(Si votre BE et/ou votre registre demande le DS et pas le DNSKEY, il faudra ajouter --ds à la commande.) On indique alors la nouvelle clé dans l'interface du BE (Web ou API). Attention à soigner cette étape : cette clé va désormais être utilisée pour la validation, il ne faut pas se tromper. On patiente ensuite le temps que le registre ait bien mis à jour la zone parente et, lorsque notre DS est dans le DNS, on prévient OpenDNSSEC :

% sudo ods-enforcer key ds-seen --keytag 10825   --zone cyberstructure.fr
1 KSK matches found.
1 KSKs changed.

% sudo ods-enforcer key  list --verbose --zone cyberstructure.fr
Keys:
Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
cyberstructure.fr               KSK      retire    waiting for ds-gone      2048  8          2d63a8cc9f68602d5b98f2bcb2714119 SoftHSM     63130
cyberstructure.fr               ZSK      active    2024-06-21 14:06:08      1024  8          b8e16f9a3aad96676ae36cd6fdb955ad SoftHSM     11668
cyberstructure.fr               KSK      active    2024-06-21 14:06:08      512   13         02e0ddf994431d5fa3d89cdc12f7addd SoftHSM     10825
cyberstructure.fr               ZSK      active    2024-06-21 14:06:08      512   13         cebc635b489780d2fddf5efabeba5b81 SoftHSM     54500

Parfait, la KSK (Key-signing key) ECDSA est désormais active. La KSK RSA va être retirée. Regardons d'abord le nouvel état. Il y a deux DS et deux clés actives. rollover-cs-2.png

On va maintenant retirer l'ancien DS. On le supprime via l'interface du BE puis, lorsque le registre a mis la zone à jour :

% sudo ods-enforcer key ds-gone --keytag 63130    --zone cyberstructure.fr
1 KSK matches found.
1 KSKs changed.

% sudo ods-enforcer key  list --verbose --zone cyberstructure.fr         
Keys:
Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
cyberstructure.fr               KSK      retire    2024-06-21 14:06:08      2048  8          2d63a8cc9f68602d5b98f2bcb2714119 SoftHSM     63130
cyberstructure.fr               ZSK      active    2024-06-21 14:06:08      1024  8          b8e16f9a3aad96676ae36cd6fdb955ad SoftHSM     11668
cyberstructure.fr               KSK      active    2024-06-21 14:06:08      512   13         02e0ddf994431d5fa3d89cdc12f7addd SoftHSM     10825
cyberstructure.fr               ZSK      active    2024-06-21 14:06:08      512   13         cebc635b489780d2fddf5efabeba5b81 SoftHSM     54500
  

Plus qu'un seul DS, mais l'ancienne clé RSA est toujours là, pour les résolveurs qui auraient des anciennes informations dans leur mémoire. rollover-cs-3.png

Enfin, les clés et signatures RSA seront automatiquement supprimées du DNS lorsqu'elles sont devenues inutiles, ce qui nous mène au dernier état, lorsque le remplacement est terminé. Les clés disparaitront ensuite du trousseau d'OpenDNSSEC (mais cela prendra davantage de temps).

% sudo ods-enforcer key list --verbose --zone cyberstructure.fr
Keys:
Zone:                           Keytype: State:    Date of next transition: Size: Algorithm: CKA_ID:                          Repository: KeyTag:
cyberstructure.fr               KSK      retire    2024-07-06 08:09:09      2048  8          2d63a8cc9f68602d5b98f2bcb2714119 SoftHSM     63130
cyberstructure.fr               ZSK      retire    2024-07-06 08:09:09      1024  8          b8e16f9a3aad96676ae36cd6fdb955ad SoftHSM     11668
cyberstructure.fr               KSK      active    2024-07-06 08:09:09      512   13         02e0ddf994431d5fa3d89cdc12f7addd SoftHSM     10825
cyberstructure.fr               ZSK      active    2024-07-06 08:09:09      512   13         cebc635b489780d2fddf5efabeba5b81 SoftHSM     54500
  

Voici le résultat : rollover-cs-4.png

Ah, et j'avais dit qu'il y avait des erreurs dues au non-respect du RFC 9276, qui a changé les paramètres recommandés pour les enregistrements NSEC3 (RFC 5155). C'est exact, donc il a fallu également modifier cela dans notre politique :


<!-- Régime sans sel, et sans itérations -->
<NSEC3>
…
       <Hash>
         <Algorithm>1</Algorithm>
         <Iterations>0</Iterations>
         <Salt length="0"/>
       </Hash>
</NSEC3>

Quelques liens intéressants :


L'article seul

OpenDNS plus accessible depuis la France

Première rédaction de cet article le 28 juin 2024
Dernière mise à jour le 3 juillet 2024


Le résolveur DNS public OpenDNS ne répond désormais plus aux adresses IP situées en France, se pliant aux exigences des ayant-tous-les-droits.

OpenDNS a fait un communiqué sur ces exigences. Voici le résultat, avec dig, depuis une adresse chez Free :

    
% dig @208.67.222.222 www.bortzmeyer.org

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> @208.67.222.222 www.bortzmeyer.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 102
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1410
; EDE: 16 (Censored)
;; QUESTION SECTION:
;www.bortzmeyer.org.	IN A

;; ADDITIONAL SECTION:
www.bortzmeyer.org.	0 IN TXT "Due to a court order in France issued under Article L.333-10 of the French Sport code the OpenDNS service is not currently available to users in France and certain French territories."

;; Query time: 4 msec
;; SERVER: 208.67.222.222#53(208.67.222.222) (UDP)
;; WHEN: Fri Jun 28 17:39:19 CEST 2024
;; MSG SIZE  rcvd: 249

  

Notez le status: REFUSED et l'enregistrement de type TXT qui explique. La loi en question est vouée à défendre les intérêts du sport-spectacle, qui passent avant tout, et est lisible ici (et le jugement qui a contraint OpenDNS semble être celui-ci, vous y trouverez la liste des noms concernés, ça vient de cet article de l'Informé). Les défenseurs de l'appropriation intellectuelle affirment souvent qu'elle sert à « protéger les créateurs » mais, comme on le voit ici, elle sert surtout à enrichir les clubs de rugby ou de football. Les personnes qui utilisaient OpenDNS le faisaient sans doute pour contourner une censure qui bénéficie surtout aux ayant-droits.

Ce n'est pas spécifique au nom de domaine demandé, tous donnent le même résultat. En outre, on peut vérifier, par exemple avec les sondes RIPE Atlas, que c'est pareil depuis quasiment tous les FAI français :

%  blaeu-resolve --requested 200 --country FR --nameserver 208.67.222.222 --type A www.bortzmeyer.org
Nameserver 208.67.222.222
[ERROR: REFUSED] : 180 occurrences 
[80.77.95.49] : 4 occurrences 
[TIMEOUT] : 2 occurrences 
Test #74529588 done at 2024-06-28T15:43:35Z
  

(Et inutile d'essayer en IPv6, c'est pareil.)

Celles et ceux qui avaient configuré leur réseau pour utiliser le résolveur OpenDNS n'avaient donc plus d'accès réseau (sans résolveur DNS, on ne peut quasiment rien faire, et cela bloquait un certain nombre d'équipements). C'est sans doute pour cela qu'OpenDNS a fait une exception (notée par David Ponzone) pour un service critique, la synchronisation d'horloges avec NTP :


%  dig @208.67.222.222 ntp.org           
…
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 6126
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
…
;; ADDITIONAL SECTION:
ntp.org.		0 IN TXT "Due to a court order in France issued under Article L.333-10 of the French Sport code the OpenDNS service is not currently available to users in France and certain French territories."

;; Query time: 8 msec
;; SERVER: 208.67.222.222#53(208.67.222.222) (UDP)
;; WHEN: Wed Jul 03 09:57:37 CEST 2024
;; MSG SIZE  rcvd: 238

%  dig @208.67.222.222 pool.ntp.org
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47543
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
pool.ntp.org.		130 IN A 185.123.84.51
pool.ntp.org.		130 IN A 51.15.182.163
pool.ntp.org.		130 IN A 51.38.113.118
pool.ntp.org.		130 IN A 51.255.141.76

;; Query time: 48 msec
;; SERVER: 208.67.222.222#53(208.67.222.222) (UDP)
;; WHEN: Wed Jul 03 09:57:41 CEST 2024
;; MSG SIZE  rcvd: 105

Notez qu'on observe la même chose au Portugal, pays également cité dans le communiqué d'OpenDNS :

% blaeu-resolve --requested 200 --country PT --nameserver 208.67.222.222 --type A www.bortzmeyer.org
Nameserver 208.67.222.222
[ERROR: REFUSED] : 168 occurrences 
[80.77.95.49] : 1 occurrences 
Test #74532654 done at 2024-06-28T18:07:19Z
  

OpenDNS n'est qu'un des nombreux résolveurs DNS publics (et pas forcément le plus sympathique, par exemple, pendant longtemps, ils remplaçaient les réponses négatives par des publicités à eux). Par exemple, en Europe, il y a dns.sb, DNS4ALL, en France, il y a celui de FDN et il y en a même un à moi. Si on utilise un résolveur public (ce qui n'est pas forcément une bonne idée), le choix est vaste et les alternatives nombreuses (aucune raison de tous aller sur le résolveur d'une grosse entreprise capitaliste étatsunienne). Mais il n'est pas évident de choisir.

Un de ces gros résolveurs étatsuniens est celui de Google, qui est cité dans le jugement et qui, contrairement à OpenDNS, n'a pas bloqué tout service mais censure seulement les domaines demandés par la justice. (OpenDNS a sans doute jugé plus simple de bloquer tout accès depuis la France.)


% dig @8.8.8.8 volkastream.xyz A 

; <<>> DiG 9.18.24-0ubuntu0.22.04.1-Ubuntu <<>> @8.8.8.8 volkastream.xyz A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 18572
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41939614.)
;; QUESTION SECTION:
;volkastream.xyz.	IN A

;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Fri Jun 28 20:10:16 CEST 2024
;; MSG SIZE  rcvd: 246

  

Notez l'EDE (Extended DNS Error), concept normalisé dans le RFC 8914. Le code 16 pour indiquer la censure est très rarement observé dans la nature, la plupart des censeurs étant hypocrites.

En parlant de ce domaine, volkastream.xyz, voyons sa censure par les résolveurs DNS des FAI français :

% ./blaeu-resolve --country FR --requested 100 --ede --type A volkastream.xyz
[104.21.38.55 172.67.219.135] : 68 occurrences 
[127.0.0.1] : 18 occurrences 
[ERROR: NXDOMAIN] : 2 occurrences 
[EDE 16 (Censored): The requested domain is on a court ordered copyright piracy blocklist for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41939614. ERROR: REFUSED] : 2 occurrences 
Test #74533089 done at 2024-06-28T18:26:58Z
  

Ce domaine n'est pas bloqué par le résolveur DNS public de Cloudflare mais, comme Cloudflare est son hébergeur Web, il a pu quand même le censurer, et renvoie désormais le code de statut HTTP 451 (normalisé dans le RFC 7725) :


% curl -v https://volkastream.xyz
…
* Connected to volkastream.xyz (2606:4700:3037::6815:2637) port 443 (#0)
…
> GET / HTTP/2
> Host: volkastream.xyz
> user-agent: curl/7.81.0
> accept: */*
…
< HTTP/2 451 
< date: Sat, 29 Jun 2024 17:52:55 GMT
< content-type: text/html

  

OpenDNS est un service de Cisco.

Merci à capslock pour le signalement.


L'article seul

Problème DNSSEC au Libéria

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 :

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.


L'article seul

Encore un résolveur DNS public européen, DNS4ALL

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 :

  • Quelques problèmes techniques (combiner IPv6 et TLS, je cherchais la difficulté, mais on voit à peu près la même chose en IPv4, et ce n'est pas forcément la faute de l'opérateur du résolveur, le port 853 peut être bloqué sur le réseau local),
  • Apparemment trois serveurs, si on se fie aux NSID (RFC 5001), un sur chaque continent. Un article des opérateurs du projet dit qu'il y a 30 nœuds anycast, qui envoient vers 3 résolveurs, ce que nous avons pu vérifier.

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.


L'article seul

Les Journées du Logiciel Libre à Lyon (et avec du Zig et du RDDS)

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 :

  • Une intéressante conférence d'altercarto sur les données ouvertes à partir de leur situation dans trois pays, France, Tunisie et Burkina Faso. Le point important était que les données ouvertes, c'est très bien, ça incite à bosser sur ce qui est publié (ce qui est bien le but) mais il y a aussi ce qui n'est pas publié et c'est à cela qu'il faut prêter attention. On manque ainsi de données sur les droits sociaux, la santé, l'éducation… Par exemple, en France : les données d'actes de soin remboursés par la Sécurité Sociale par ville ne sont pas disponibles. Cela serait pourtant utile pour étudier les inégalités. En Tunisie, des organisations comme Cartographie Citoyenne ne peuvent plus travailler car la dictature fait qu'il y a de moins en moins de données (par exemple sur la pollution à Gabès, sujet polémique), sous prétexte de « diffusion de fausses nouvelles ». (Comme en France, le discours sur les fake news est toujours un prétexte à censure.) Au Burkina Faso depuis le coup d'État pro-russe, les acteurs de la donnée ouverte se taisent et ont arrêté leur activité qui, il est vrai, aboutissait parfois à montrer les défauts et les faiblesses de l'action publique (par exemple en publiant les points d'eau qui fonctionnaient, pas uniquement ceux qui existaient).
  • Une conférence portait sur les noms de domaine, partant d'une explication sur le fonctionnement de l'Internet et aboutissant au projet d'un bureau d'enregistrement coopératif (puisque tous les BE ouverts au public sont désormais des entreprises commerciales, qui ne correspondent pas forcément aux besoins des particuliers et associations ; et ce alors qu'il existe des FAI et des hébergeurs sans but lucratif). L'orateur rappelait par exemple que les registres ont des règles d'enregistrement, parfois différentes. Ainsi, .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.
  • Une autre conférence venait des Restos du Cœur et détaillait leur infrastructure informatique pour gérer les applications métier comme le contenu des réfrigérateurs ou la flotte de véhicules. C'était assez stupéfiant car, avec six administrateurs système, tous bénévoles donc travaillant le soir ou le week-end, les Restos du Cœur ont une infrastructure matérielle et logicielle qui rendrait jalouses la grande majorité des entreprises spécialisées en informatique. On trouve dans les logiciels utilisés Ansible, Passbolt, Maas, Ceph, Ruddder, Unbound, PowerDNS, MariaDB, PostgreSQL, un bastion SSH, mais aussi OpenStack et Kubernetes. Cela donne quand même l'impression d'un excès d'ingéniérie. (Mais l'orateur estimait que cela correspondait aux besoins des Restos, qui ont des applications locales, et pour lesquelles il faut offrir un service « cloud ».) Le tout tourne sur du matériel donné aux Restos, pour des raisons financières, les services comme AWS ne sont pas trop utilisés. Une conférence très déroutante, qui a bien étonné les administrateurs système présents.
  • Alexis Kauffmann a énuméré les « 42 raisons de croire au logiciel libre » dans l'Éducation nationale française. Parmi les 41 (« la 42e va vous étonner »), le fait qu'il y a des libristes au ministère, des services comme Éducajou, des profs qui font des paquetages LaTeX, des profs de philo qui font du Markdown, Tchap, des belles paroles du ministère, Papillon, un concurrent libre de Pronote (qui les a menacé juridiquement), etc. Une coupure de courant a obligé l'orateur à continuer sans slides et sans micro. Une préparation au monde futur post-effondrement ?
  • Il y avait une conférence sur les outils libres pour les langues. Des langues, il y en a beaucoup, dans les 7 000 (ou à peu près, ça se discute), dans les 1 500 écrites (environ), et pour 50 écritures (tiens, j'aurais cru qu'il y en avait davantage). Il existe plusieurs efforts de classification comme celui de SIL, organisation missionnaire chrétienne qui catalogue les langues pour traduire la Bible (et qui gère Ethnologue), celui de Glottolog, etc. (Et j'ajoute le registre de langues IETF, normalisé dans le RFC 5646, qui est celui utilisé par HTTP et HTML. On peut aussi y accéder via mon site Web 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.
  • Enfin, un atelier permettait de réfléchir à l'IA en jouant les rôles de personnes fanatiquement pour (« Oui, Laurent Alexandre est si inspirant »), plutôt pour, plutôt contre ou fanatiquement contre. Une expérience intéressante pour moi (mais trop courte).
  • Par contre, la conférence sur la situation en prison a été annulée. Dommage.

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 : ens-mouton.jpg

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) :


L'article seul

Les retards du serveur racine C

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, https://c.root-servers.org/ (notez le .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 : cogent-no-info-c-root.png

(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.)


L'article seul

Fiche de lecture : La ronde des bêtes

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.


L'article seul

Fiche de lecture : Chaudun - La montagne blessée

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.)


L'article seul

RFC 9562: Universally Unique IDentifiers (UUIDs)

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 :

  • UUID version 1, fondé sur le temps (notez tout de suite que les versions 6 et 7 sont recommandées à sa place).
  • UUID version 2, réservé, non utilisé.
  • UUID version 3, fondé sur un espace de noms (par exemple le DNS) et un nom qui est condensé en MD5 (la version 5 est préférable).
  • UUID version 4, aléatoire.
  • UUID version 5, fondé sur un espace de noms et un nom qui est condensé en SHA-1.
  • UUID version 6, fondé sur le temps, avec les mêmes champs que la version 1, mais avec un format différent.
  • UUID version 7, fondé sur le temps, avec une autre définition, et des champs différents.
  • UUID version 8, pour les usages expérimentaux, si vous voulez jouer localement avec un nouveau mécanisme de génération.

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 :

  • UUID version 4 (aléatoire) avait une mauvaise localité : deux UUID créés l'un après l'autre en un temps très court n'ont aucun rapport, ce qui est gênant pour certains usages (par exemple comme étiquette dans un B-tree).
  • UUID version 1 (fondé entre autre sur le temps écoulé depuis l'epoch) utilise un incrément peu pratique (cent nanosecondes).
  • Certaines méthodes fabrication des UUID posaient des gros problèmes de vie privée, par exemple l'utilisation des adresses MAC dans UUID version 1, désormais déconseillée.
  • Le RFC 4122 descendait trop dans les détails de mise en œuvre.
  • Le RFC 4122 ne séparait pas les exigences pour la génération d'UUID et celles pour leur stockage.

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 :

  • Beaucoup d'errata dans le RFC 4122.
  • Spécification du format qui mélangeait trop les diverses versions d'UUID.
  • Absence de vecteurs de test (ils figurent désormais dans l'annexe A).

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 :

  • Pour tous les UUID fondés sur le temps, si vous avez besoin d'unicité des UUID, attention aux cas où l'horloge peut changer, en raison d'une modification manuelle, d'une seconde intercalaire ou d'un ajustement fait par NTP.
  • Si vous générez des UUID de manière répartie, sur plusieurs machines, ce qui est un des points forts des UUID, mais que vous voulez quand même de l'unicité, vous pouvez préfixer vos UUID avec un identificateur de la machine, ou bien compter sur un registre central (mais, en général, c'est justement ce qu'on veut éviter avec des UUID).
  • UUID rend les collisions (génération de deux UUID identiques) peu probables mais pas impossibles. Lorsque vous concevez une application, demandez-vous si une collision est juste un petit inconvénient ou bien si elle est inacceptable (le RFC cite l'exemple fictif d'un système de contrôle aérien où chaque avion serait identifié par un UUID ; l'attribution du même UUID à deux avions différents serait clairement catastrophique). Dans ce cas, vous devez trouver un moyen de ne pas avoir de collision.
  • Si vous voulez des UUID qui ne soient pas prévisibles par un observateur extérieur, utilisez la version 4 et assurez vous que votre générateur de nombres aléatoires suit bien les prescriptions des RFC 4086 et RFC 8937, ainsi que « Random Number Generator Recommendations for Applications ».
  • Les versions 6 et 7 (nouveautés de ce RFC 9562) sont prévues pour que les UUID soient triables chronologiquement, sans avoir besoin d'analyse, uniquement en triant la version binaire. Un des avantages est que des UUID générés à des moments proches ont des valeurs proches, ce qui peut être utile dans certaines applications.

Téléchargez le RFC 9562


L'article seul

RFC 9490: Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN)

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.


Téléchargez le RFC 9490


L'article seul

RFC 9499: DNS Terminology

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 :

  • Nom de domaine (domain name) : la définition est différente de celle du RFC 7719, qui avait simplement repris celle du RFC 1034, section 3.1. Elle est désormais plus abstraite, ce qui permet de l'utiliser pour d'autres systèmes de nommage. Un nom de domaine est désormais simplement une liste (ordonnée) de composants (labels). Aucune restriction n'est imposée dans ces composants, simplement formés d'octets (tant pis pour la légende comme quoi le DNS serait limité à ASCII). Comme on peut représenter les noms de domaine sous forme d'un arbre (la racine de l'arbre étant à la fin de la liste des composants) ou bien sous forme texte (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).
  • FQDN (Fully Qualified Domain Name, nom de domaine complet) : apparu dans le RFC 819, ce terme désigne un nom de domaine où tous les composants sont cités (par exemple, 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.)
  • Composant (label) : un nœud de l'arbre des noms de domaine, dans la chaîne qui compose un FQDN. Dans www.laquadrature.net, il y a trois composants, www, laquadrature et net.
  • Nom de machine (host name) : ce n'est pas la même chose qu'un nom de domaine. Utilisé dans de nombreux RFC (par exemple RFC 952) mais jamais défini, un nom de machine est un nom de domaine avec une syntaxe plus restrictive, définie dans la section 3.5 du RFC 1035 et amendée par la section 2.1 du RFC 1123 : uniquement des lettres, chiffres, points et le tiret. Ainsi, 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).
  • TLD (Top Level Domain, domaine de premier niveau ou domaine de tête) : le dernier composant d'un nom de domaine, celui juste avant (ou juste en dessous) de la racine. Ainsi, 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.
  • DNS mondial (Global DNS), nouveauté du RFC 8499, désigne l'ensemble des noms qui obéissent aux règles plus restrictives des RFC 1034 et RFC 1035 (limitation à 255 octets, par exemple). En outre, les noms dans ce « DNS mondial » sont rattachés à la racine officiellement gérée par l'ICANN, via le service Public Technical Identifiers (PTI). Une racine alternative, si elle sert un contenu différent de celui de PTI, n'est donc pas le « DNS mondial » mais ce que le RFC nomme « DNS privé » (private DNS). Évidemment, un système de nommage qui n'utilise pas le DNS du tout mais qui repose, par exemple, sur le pair-à-pair, ne doit pas être appelé DNS (« DNS pair-à-pair » est un oxymore, une contradiction dans les termes.)
  • IDN (Internationalized Domain Name, nom de domaine internationalisé) : un nom de domaine en Unicode, normalisé dans le RFC 5890, qui définit des termes comme U-label (le nom Unicode) et A-label (sa représentation en Punycode). Sur l'internationalisation des noms, vous pouvez aussi consulter le RFC de terminologie RFC 6365.
  • Sous-domaine (subdomain) : domaine situé sous un autre, dans l'arbre des noms de domaines. Sous forme texte, un domaine est sous-domaine d'un autre si cet autre est un suffixe. Ainsi, 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.
  • Alias (alias) : attention, il y a un piège. Le DNS permet à un nom d'être un alias d'un autre, avec le type d'enregistrement CNAME (voir la définition suivante). L'alias est le terme de gauche de l'enregistrement CNAME. Ainsi, si on met dans un fichier de zone vader IN CNAME anakin, l'alias est vader (et c'est une erreur de dire que c'est « le CNAME »).
  • CNAME (Canonical Name, nom canonique, le « vrai » nom) : le membre droit dans l'enregistrement CNAME. Dans l'exemple de la définition précédente, 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 :

  • NODATA : un mnémonique pour une réponse où le nom de domaine demandé existe bien mais ne contient aucun enregistrement du type souhaité. Le code de retour est 0, NOERROR, et le nombre de réponses (ANCOUNT pour Answer Count) est nul.
  • Réponse négative (negative answer) : le terme recouvre deux choses, une réponse disant que le nom de domaine demandé n'existe pas (code de retour NXDOMAIN), ou bien une réponse indiquant que le serveur ne peut pas répondre (code de retour SERVFAIL ou REFUSED). Voir le RFC 2308.
  • Renvoi (referral) : le DNS étant décentralisé, il arrive qu'on pose une question à un serveur qui ne fait pas autorité pour le domaine demandé, mais qui sait vous renvoyer à un serveur plus proche. Ces renvois sont indiqués dans la section Authority d'une réponse.

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 sens original, le QNAME est la question posée (le nom de domaine demandé),
  • Le sens du RFC 2308, la question finale (qui n'est pas la question posée s'il y a des CNAME sur le trajet),
  • Un sens qui n'apparait pas dans les RFC mais est parfois présent dans les discussions, une question intermédiaire (dans une chaîne de CNAME).

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) :

  • RR (Resource Record) : un enregistrement DNS.
  • Enregistrements d'adresses (Address records) : enregistrements DNS A (adresses IPv4) et AAAA (adresses IPv6). Beaucoup de gens croient d'ailleurs que ce sont les seuls types d'enregistrements possibles (« le DNS sert à traduire les noms en adresses IP » est une des synthèses erronées du DNS les plus fréquentes).
  • Ensemble d'enregistrements (RRset pour Resource Record set) : un ensemble d'enregistrements ayant le même nom (la même clé d'accès à la base), la même classe, le même type et le même TTL. Cette notion avait été introduite par le RFC 2181. Notez que la définition originale parle malheureusement de label dans un sens incorrect. La terminologie du DNS est vraiment compliquée !
  • Fichier maître (master file) : un fichier texte contenant des ensembles d'enregistrement. Également appelé fichier de zone, car son utilisation la plus courante est pour décrire les enregistrements que chargera le serveur maître au démarrage. (Ce format peut aussi servir à un résolveur quand il écrit le contenu de sa mémoire sur disque.)
  • EDNS (Extension for DNS, également appelé EDNS0) : normalisé dans le RFC 6891, EDNS permet d'étendre l'en-tête du DNS, en spécifiant de nouvelles options, en faisant sauter l'antique limitation de taille de réponses à 512 octets, etc.
  • OPT (pour Option) : une astuce d'EDNS pour encoder les informations de l'en-tête étendu. C'est un enregistrement DNS un peu spécial, défini dans le RFC 6891, section 6.1.1.
  • Propriétaire (owner ou owner name) : le nom de domaine d'un enregistrement. Ce terme est très rarement utilisé, même par les experts.
  • Champs du SOA (SOA field names) : ces noms des enregistrements SOA (comme MNAME ou RNAME) sont peu connus et malheureusement peu utilisés (RFC 1035, section 3.3.13). Notez que la sémantique du champ MINIMUM a complètement changé avec le RFC 2308.
  • TTL (Time To Live) : la durée de vie maximale d'un enregistrement dans les caches des résolveurs. C'est un entier non signé (même si le RFC 1035 dit le contraire), en secondes.

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.

  • Résolveur (resolver) : un client DNS qui va produire une réponse finale (pas juste un renvoi, pas juste une information ponctuelle comme le fait dig). Il existe plusieurs types de résolveurs (voir ci-dessous) et, en pratique, quand on dit « résolveur » tout court, c'est en général un « résolveur complet ».
  • Résolveur minimum (stub resolver) : un résolveur qui ne sait pas suivre les renvois et qui dépend donc d'un ou de plusieurs résolveurs complets pour faire son travail. Ce type est défini dans la section 6.1.3.1 du RFC 1123. C'est ce résolveur minimum qu'appellent les applications lorsqu'elles font un 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.
  • Résolveur complet (full resolver) : un résolveur qui sait suivre les renvois et donc fournir un service de résolution complet. Des logiciels comme Unbound ou PowerDNS Resolver assurent cette fonction. Le résolveur complet est en général situé chez le FAI ou dans le réseau local de l'organisation où on travaille, mais il peut aussi être sur la machine locale. On le nomme aussi « résolveur récursif ». Notez que « résolveur complet » fait partie de ces nombreux termes qui étaient utilisés sans jamais avoir été définis rigoureusement.
  • Resolveur complet avec mémoire (full-service resolver) : un résolveur complet, qui dispose en plus d'une mémoire (cache) des enregistrements DNS récoltés.
  • Serveur faisant autorité (authoritative server et traduire ce terme par « serveur autoritaire » montre une grande ignorance de l'anglais ; un adjudant est autoritaire, un serveur DNS fait autorité) : un serveur DNS qui connait une partie des données du DNS (il « fait autorité » pour une ou plusieurs zones) et peut donc y répondre (RFC 2182, section 2). Ainsi, au moment de l'écriture de cet article, 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.
  • Serveur mixte : ce terme n'est pas dans ce RFC. Autrefois, il était courant que des serveurs DNS fassent à la fois résolveur et serveur faisant autorité. Cette pratique est fortement déconseillée depuis de nombreuses années (entre autres parce qu'elle complique sérieusement le débogage, mais aussi pour des raisons de sécurité parce qu'elle mène à du code plus complexe) et n'est donc pas dans ce RFC.
  • Initialisation (priming) : le processus par lequel un résolveur complet vérifie l'information sur les serveurs de la racine. Ce concept est décrit en détail dans le RFC 8109. Au démarrage, le résolveur ne sait rien. Pour pouvoir commencer la résolution de noms, il doit demander aux serveurs de la racine. Il a donc dans sa configuration leur liste. Mais ces configurations ne sont pas forcément mises à jour souvent. La liste peut donc être trop vieille. La première chose que fait un résolveur est donc d'envoyer une requête « 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.
  • Indications de la racine (root hints) : la liste des noms et adresses des serveurs racine, utilisée pour l'initialisation. L'administrateur d'un résolveur utilisant une racine alternative changera cette liste.
  • Mémorisation des négations (negative caching, ou « cache négatif ») : mémoriser le fait qu'il n'y a pas eu de réponse, ou bien une réponse disant qu'un nom de domaine n'existe pas.
  • Serveur primaire (primary server mais on dit aussi serveur maître, master server) : un serveur faisant autorité qui a accès à la source des données (fichier de zone, base de données, etc). Attention, il peut y avoir plusieurs serveurs primaires (autrefois, ce n'était pas clair et beaucoup de gens croient qu'il y a un serveur primaire, et qu'il est indiqué dans l'enregistrement SOA). Attention bis, le terme ne s'applique qu'à des serveurs faisant autorité, l'utiliser pour les résolveurs (« on met en premier dans /etc/resolv.conf le serveur primaire ») n'a pas de sens.
  • Serveur secondaire (secondary server mais on dit aussi « serveur esclave », slave server) : un serveur faisant autorité qui n'est pas la source des données, qui les a prises d'un serveur primaire (dit aussi serveur maître), via un transfert de zone (RFC 5936).
  • Serveur furtif (stealth server) : un serveur faisant autorité mais qui n'apparait pas dans l'ensemble des enregistrements NS. (Définition du RFC 1996, section 2.1.)
  • Maître caché (hidden master) : un serveur primaire qui n'est pas annoncé publiquement (et n'est donc accessible qu'aux secondaires). C'est notamment utile avec DNSSEC : s'il signe, et donc a une copie de la clé privée, il vaut mieux qu'il ne soit pas accessible de tout l'Internet (RFC 6781, section 3.4.3).
  • Transmission (forwarding) : le fait, pour un résolveur, de faire suivre les requêtes à un autre résolveur (probablement mieux connecté et ayant un cache partagé plus grand). On distingue parfois (mais ce n'est pas forcément clair, même dans le RFC 5625) la transmission, où on émet une nouvelle requête, du simple relayage de requêtes sans modification.
  • Transmetteur (forwarder) : le terme est parfois utilisé confusément. Il désigne tantôt la machine qui transmet une requête et tantôt celle vers laquelle on transmet (c'est dans ce sens qu'il est utilisé dans la configuration de BIND, avec la directive forwarders). La définition de notre RFC est le premier sens.
  • Résolveur politique (policy-implementing resolver) : un résolveur qui modifie les réponses reçues, selon sa politique. On dit aussi, moins diplomatiquement, un « résolveur menteur ». C'est ce que permet, par exemple, le système RPZ. Sur l'utilisation de ces « résolveurs politiques » pour mettre en œuvre la censure, voir entre autres mon article aux RIPE Labs. Notez que le résolveur politique a pu être choisi librement par l'utilisateur (par exemple comme élément d'une solution de blocage des publicités) ou bien qu'il lui a été imposé.
  • Résolveur ouvert (open resolver) : un résolveur qui accepte des requêtes DNS depuis tout l'Internet. C'est une mauvaise pratique (cf. RFC 5358) et la plupart de ces résolveurs ouverts sont des erreurs de configuration. Quand ils sont délibérement ouverts, comme Google Public DNS ou Quad9, on parle plutôt de résolveurs publics.
  • Collecte DNS passive (passive DNS) : désigne les systèmes qui écoutent le trafic DNS, et stockent tout ou partie des informations échangées. Le cas le plus courant est celui où le système de collecte ne garde que les réponses (ignorant donc les adresses IP des clients et serveurs), afin de constituer une base historique du contenu du DNS (c'est ce que font DNSDB ou le système de PassiveDNS.cn).
  • Serveur protégeant la vie privée (privacy-enabled server) : ce terme désigne un serveur, typiquement un résolveur, qui permet les requêtes DNS chiffrées, avec DNS-sur-TLS (RFC 7858) ou avec DoH (RFC 8484).
  • Anycast : le fait d'avoir un service en plusieurs sites physiques, chacun annonçant la même adresse IP de service (RFC 4786). Cela résiste mieux à la charge, et permet davantage de robustesse en cas d'attaque par déni de service. Les serveurs de la racine, ceux des « grands » TLD, et ceux des importants hébergeurs DNS sont ainsi « anycastés ». Chaque machine répondant à l'adresse IP de service est appelée une instance.
  • DNS divisé (split DNS) : le fait de donner des réponses différentes selon que le client est interne à une organisation ou externe. Le but est, par exemple, de faire en sorte que 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) :

  • Zone : un groupe de domaines contigus dans l'arbre des noms, et gérés ensemble, par le même ensemble de serveurs de noms (ma définition, celle du RFC étant très abstraite). Beaucoup de gens croient que tout domaine est une zone, mais c'est faux. Ainsi, au moment de la publication de ce RFC, 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).
  • Parent : le domaine « du dessus ». Ainsi, le parent de wikipedia.org est org, le parent de .org est la racine.
  • Apex : le sommet d'une zone, là où on trouve les enregistrements NS et SOA. Si la zone ne comprend qu'un domaine, l'apex est ce domaine. Si la zone est plus complexe, l'apex est le domaine le plus court. (On voit parfois des gens utiliser le terme erroné de racine pour parler de l'apex.)
  • Coupure de zone (zone cut) : l'endroit où on passe d'une zone à l'autre. Au-dessus de la coupure, la zone parente, en dessous, la zone fille.
  • Délégation (delegation) : un concept évidemment central dans le DNS, qui est un système décentralisé. En ajoutant un ensemble d'enregistrements NS pointant vers les serveurs de la zone fille, une zone parente délègue une partie de l'arbre des noms de domaine à une autre entité. L'endroit où se fait la délégation est donc une coupure de zone.
  • Colle (glue records) : lorsqu'une zone est déléguée à des serveurs dont le nom est dans la zone fille, la résolution DNS se heurte à un problème d'œuf et de poule. Pour trouver l'adresse de 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.)
  • Délégation boiteuse (lame delegation) : un ou plusieurs des serveurs à qui la zone est déléguée ne sont pas configurés pour servir cette zone. La délégation peut avoir été boiteuse depuis le début (parce que le titulaire a indiqué des noms un peu au hasard) ou bien l'être devenue par la suite. C'est certainement une des erreurs techniques les plus courantes. Mais le RFC note que l'usage du terme a dérivé et qu'aujourd'hui, il est devenu plus flou, désignant hélas des erreurs très variées.
  • Dans le bailliage (in bailiwick) : terme absent des textes DNS originaux et qui peut désigner plusieurs choses. (La définition du RFC 8499, embrouillée, a été heureusement remplacée.) « Dans le bailliage » est (très rarement, selon mon expérience) parfois utilisé pour parler d'un serveur de noms dont le nom est dans la zone servie (et qui nécessite donc de la colle, voir la définition plus haut), mais le sens le plus courant désigne des données pour lesquelles le serveur qui a répondu fait autorité, soit pour la zone, soit pour un ancêtre de cette zone. L'idée est qu'il est normal dans la réponse d'un serveur de trouver des données situées dans le bailliage et, par contre, que les données hors-bailliage sont suspectes (elles peuvent être là suite à une tentative d'empoisonnement DNS). Un résolveur DNS prudent ignorera donc les données hors-bailliage.
  • ENT (Empty Non-Terminal pour nœud non-feuille mais vide) : un domaine qui n'a pas d'enregistrements mais a des sous-domaines. C'est fréquent, par exemple, sous 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.
  • Zone de délégation (delegation-centric zone) : zone composée essentiellement de délégations vers d'autres zones. C'est typiquement le cas des TLD et autres suffixes publics. Il est amusant de noter que les RFC 4956 et RFC 5155 utilisaient ce terme sans le définir.
  • Changement rapide (fast flux) : une technique notamment utilisée par les botnets pour mettre leur centre de commande à l'abri des filtrages ou destructions. Elle consiste à avoir des enregistrements d'adresses IP avec des TTL très courts et à en changer fréquemment.
  • DNS inverse (reverse DNS) : terme qui désigne en général les requêtes pour des enregistrements de type PTR, permettant de trouver le nom d'une machine à partir de son adresse IP. À ne pas confondre avec les vraies requêtes inverses, qui avaient été normalisées dans le RFC 1035, avec le code IQUERY, mais qui, jamais vraiment utilisées, ont été abandonnées dans le RFC 3425.

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 :

  • La section ANSWER est vide, c'est un renvoi.
  • Le serveur indique la colle pour pri.authdns.ripe.net : ce serveur étant dans la zone qu'il sert, sans son adresse IP, on ne pourrait jamais le joindre.
  • Le serveur envoie également les adresses IP d'autres machines comme sec1.apnic.net. Ce n'est pas strictement indispensable (on pourrait l'obtenir par une nouvelle requête), juste une optimisation.
  • Les adresses de 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 :

  • Joker (wildcard) : une source de confusion considérable depuis les débuts du DNS. Si on pouvait refaire le DNS en partant de zéro, ces jokers seraient la première chose à supprimer. Pour les résumer, le nom * 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.
  • Ancêtre le plus proche (closest encloser) : c'est le plus long ancêtre existant d'un nom. Si 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) :

  • Registre (registry) : l'organisation ou la personne qui gère les délégations d'une zone. Le terme est parfois employé uniquement pour les gérants de grandes zones de délégation, mais ce n'est pas obligatoire. Je suis à moi tout seul le registre de 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 ».
  • Titulaire (registrant, parfois holder) : la personne ou l'organisation qui a enregistré un nom de domaine.
  • Bureau d'enregistrement (registrar) : dans le modèle RRR (Registry-Registrar-Registrant, mais ce modèle n'est pas obligatoire et pas universel), c'est un intermédiaire entre le titulaire et le registre.
  • Hébergeur DNS (DNS operator) : la personne ou l'organisation qui gère les serveurs DNS. Cela peut être le titulaire, son bureau d'enregistrement, ou encore un acteur spécialisé dans cette gestion.
  • Suffixe public (public suffix) : ce terme pas très officiel est parfois utilisé pour désigner un suffixe de noms de domaine qui est contrôlé par un registre public (au sens où il accepte des enregistrements du public). Mais le terme est trompeur car, par exemple, .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).
  • EPP (Extensible Provisioning Protocol) : normalisé dans le RFC 5730, c'est le protocole standard entre bureau d'enregistrement et registre. Ce protocole n'a pas de lien avec le DNS, et tous les registres ne l'utilisent pas.
  • Whois (nommé d'après la question Who Is?) : un protocole réseau, sans lien avec le DNS, normalisé dans le RFC 3912. Il permet d'interroger les bases de données du registre pour trouver les informations dites « sociales », informations qui ne sont pas dans le DNS (comme le nom du titulaire, et des moyens de le contacter). Les termes de « base Whois » ou de « données Whois » sont parfois utilisés mais ils sont erronés puisque les mêmes bases peuvent être interrogées par d'autres protocoles que Whois, comme RDAP (voir définition suivante).
  • RDAP (Registration Data Access Protocol) : un protocole concurrent de Whois, mais plus moderne. RDAP est décrit notamment dans les RFC 9082 et RFC 9083.

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 :

  • DoT (RFC 7858), DoH (RFC 8484) et DoQ (RFC 9250) ont maintenant une définition complète.
  • Par contraste, le DNS traditionnel (Classic DNS), celui qui tourne directement sur UDP ou TCP, et en clair, a sa définition.
  • L'importance de TLS se traduit aussi par l'arrivée des définitions de DoT vers le résolveur (RDoT, pour Recursive DNS over TLS), de DoT vers le serveur faisant autorité (ADoT pour Authoritative DNS over TLS) et XoT (zone transfer over TLS, normalisé dans le RFC 9103).
  • Le RFC prend également acte du fait que le terme désignant les délégations invalides, lame delegation, a beaucoup dérivé.

Téléchargez le RFC 9499


L'article seul

Exposé « Normalisation technique, qui décide ? » aux journées FedeRez

Première rédaction de cet article le 29 avril 2024


FedeRez est la fédération nationale des associations d'étudiants qui gèrent des réseaux informatiques. Elle tient des journées annuelles et, à celles de 2024 dans un endroit éloigné de tout transport en commun, j'ai fait un exposé sur le thème « Normalisation technique, qui décide ? ».

Voici les transparents de mon exposé :

L'enregistrement vidéo n'est pas encore disponible.


L'article seul

RFC 9557: Date and Time on the Internet: Timestamps with Additional Information

Date de publication du RFC : Avril 2024
Auteur(s) du RFC : U. Sharma (Igalia, S.L.), C. Bormann (Universität Bremen TZI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF sedate
Première rédaction de cet article le 29 avril 2024


Ce RFC modifie légèrement le format des estampilles temporelles du RFC 3339, changeant à la marge une définition et, surtout, permettant d'y attacher des informations supplémentaires.

Le RFC 3339 décrit un des formats d'estampilles temporelles possibles sur l'Internet (car, malheureusement, toutes les normes Internet ne l'utilisent pas). Un exemple, sur Unix :

% date --rfc-3339=seconds 
2024-04-29 06:22:33+00:00
  

Le format du RFC 3339 est du type « YYYY-MM-DD HH:MM:SS » avec, à la fin, ajout d'une information sur le décalage avec le temps de référence (on verra que notre nouveau RFC 9557 change un peu cette dernière information). Un format gros boutien, donc, qui permet notamment de trier les dates-et-heures uniquement en suivant l'ordre lexicographique des caractères.

Mais certaines applications voudraient en savoir plus, et ajouter à ce format des détails. D'ailleurs, c'est déjà fait dans des solutions non normalisées, comme le format de Java, très populaire, qui permet des estampilles comme 2011-12-03T10:15:30+01:00[Europe/Paris] (fuseau horaire, ajouté après la date au format du RFC 3339 ; lisez le RFC 6557 pour en savoir davantage sur les fuseaux horaires).

Ce nouveau RFC prévoit donc une extension optionnelle (les dates-et-heures qui suivaient le format de l'ancien RFC restent parfaitement valdies), compatible avec celle de Java, et généraliste (on pourra indiquer autre chose que le fuseau horaire). Ce format étendu est baptisé IXDTF pour Internet Extended Date/Time Format. En revanche, le nouveau format ne gère pas des cas compliqués (la gestion du temps en informatique est toujours compliquée) 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 :

  • Une lettre Z indiquait qu'on utilisait UTC comme référence,
  • Un +00:00 indiquait qu'on utilisait UTC comme référence (identique au cas précédent),
  • Un -00:00 indiquait qu'on n'avait aucune idée sur la référence (typiquement parce qu'on voudrait connaitre l'heure locale mais qu'on ne la connait pas).

(Au passage, si vous ne connaissiez pas ces trois cas et leurs différences, ne vous inquiétez pas, vous n'étiez pas seul·e.) Notre RFC change cela (section 2) en décidant que Z est désormais synonyme de -00:00 plutôt que de +00:00, un changement qui aura sans doute peu d'importance en pratique.

L'autre nouveauté de ce RFC 9557 est plus marquante, c'est le format étendu IXDTF (section 3). Il consiste à ajouter à la fin de l'estampille une série (facultative) de couples {clé, valeur}, entre crochets. Si la clé est absente, c'est que la valeur est un fuseau horaire, suivant la syntaxe de la base TZ. Voici un exemple :

2022-07-08T12:14:37+02:00[Europe/Paris][u-ca=hebrew]
  

Cet exemple indique que le fuseau horaire était celui de Paris (cf. le format de ces noms de fuseaux) et que le calendrier préféré (clé u-ca), pour afficher cette date, serait le calendrier hébreu (ce qui indiquera 9 Tammouz 5782, sauf erreur).

Un point d'exclamation avant la clé indiquerait que la clé doit être comprise par le lecteur, sinon, il faut qu'il ignore l'estampille temporelle (la plupart du temps, l'application peut ignorer les clés et leurs valeurs). Un trait bas indique une clé expérimentale, non officiellement enregistrée.

Car notre RFC crée aussi un registre des clés. Pour l'instant, il ne compte qu'une seule clé, u-ca, pour indiquer le calendrier préféré. Pour enregistrer une nouvelle clé, il faut une spécification écrite (cf. RFC 8126), mais il y a aussi des enregistrements temporaires, plus légers.

Et on termine par un petit mot sur la sécurité (section 7). Le RFC rappelle que plus on donne d'informations, plus on risque d'en donner trop. Ainsi, l'indication du calendrier préféré peut indiquer une origine ethnique ou religieuse, qui peut être considérée comme privée, surtout s'il y a des risques d'attaques racistes.


Téléchargez le RFC 9557


L'article seul

RFC 9567: DNS Error Reporting

Date de publication du RFC : Avril 2024
Auteur(s) du RFC : R. Arends (ICANN), M. Larson (ICANN)
Chemin des normes
Première rédaction de cet article le 27 avril 2024


Lorsqu'un résolveur DNS détecte un problème avec une zone, l'empêchant de résoudre les noms dans cette zone, il n'avait pas de moyen simple et automatique de prévenir les gérants des serveurs faisant autorité pour cette zone. Leur envoyer un message en utilisant l'information dans l'enregistrement SOA ou les adresses classiques du RFC 2142 ? Mais, justement, si la zone ne marche pas, le courrier ne partira pas forcément. Ce nouveau RFC propose un nouveau système. Les serveurs faisant autorité annoncent un domaine (qui marche, espérons-le), qui acceptera des requêtes DNS spéciales signalant le problème.

Cela dépend évidemment du problème pratique qui se pose. Si la zone n'a aucun serveur faisant autorité qui marche, il n'y a évidemment rien à faire. Mais s'ils marchent, tout en servant des données problématiques (par exemple des signatures DNSSEC expirées), alors, le résolveur pourra agir. Les serveurs faisant autorité mettent dans leurs réponses une option EDNS qui indique le domaine qui recevra les rapports (cela doit être un autre domaine, qui n'a pas de problème), le résolveur fera alors une requête DNS se terminant par le nom du domaine de signalement, et encodant le problème. L'agent, le domaine de signalement, pourra alors récolter ces requêtes et savoir qu'il y a un problème. Cela ne traite pas tous les cas (il faudra toujours utiliser RDAP ou whois pour récolter des informations sur les contacts du domaine erroné, puis leur écrire depuis un autre réseau) mais c'est simple, léger et automatisable. Les gérants de domaine sérieux, qui prennent au sérieux les signalements de problèmes techniques (soit 0,00001 % des domaines) pourront alors agir. (Note si vous gérez un résolveur et que vous constatez un problème avec un domaine et que les contacts ne répondent pas : un message méchant sur Twitter est souvent plus efficace.)

Donc, les détails techniques : le domaine qui veut recevoir les éventuels signalements va devoir configurer ses serveurs faisant autorité pour renvoyer une option EDNS, de numéro 18 (section 5 du RFC), indiquant l'agent, c'est-à-dire le domaine qui va recevoir les signalements (il faut évidemment veiller à ce qu'il n'ait pas de point de défaillance commun avec le domaine surveillé). Notez que cette option est systématiquement envoyée, le client (le résolveur) n'a pas à dire quoi que ce soit (la question avait fait l'objet d'un sérieux débat à l'IETF).

En cas de problème, notamment DNSSEC, le résolveur qui a noté le problème va alors construire un nom de domaine formé, successivement (section 6.1.1) par :

  • Le composant _er,
  • Le type de données qui posait problème (adresse IP, enregistrement de service, etc),
  • Le nom de domaine qui était initialement demandé par le résolveur,
  • L'erreur étendue (EDE, RFC 8914),
  • Le composant _er (oui, encore),
  • Le nom de domaine de l'agent.

Par exemple, si le domaine dyn.bortzmeyer.fr annonce comme agent report.dyn.sources.org, et qu'un résolveur découvre des signatures DNSSEC expirées (EDE 7) en cherchant à résoudre hello.dyn.bortzmeyer.fr / TXT (TXT a la valeur 16), la requête de signalement du résolveur sera _er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org (ouf). Le type demandé est TXT. Lorsque cette requête arrivera au serveur faisant autorité pour report.dyn.sources.org, il pourra enregistrer qu'il y a eu un problème, et mettre cette information à la disposition de son administrateur système.

Ce serveur faisant autorité est censé répondre au signalement avec une réponse de type TXT comme ici :


% dig _er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org TXT
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12032
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
_er.16.hello.dyn.bortzmeyer.fr.7._er.report.dyn.sources.org. 30	IN TXT "Thanks for the report of error 7 on hello.dyn.bortzmeyer.fr"
…

  

L'agent peut ensuite être interrogé, par des méthodes propres à la mise en œuvre utilisée :

% echo report | socat - UNIX-CONNECT:/home/drink/drink.sock
REPORT state:
hello.dyn.bortzmeyer.fr, 7
ip.dyn.bortzmeyer.fr, 7
  

Ici, on voit que deux domaines ont été signalés comme ayant des signatures expirées (rassurez-vous, c'était juste des tests). Le nombre de signalements n'est pas indiqué, ni la source des signalements (travail futur).

Quelques petits points de sécurité à garder en tête (section 9 du RFC) :

  • Le fait de signaler va, par définition, donner au serveur faisant autorité des informations sur le résolveur (par exemple, un résolveur menteur qui signalerait les blocages informerait sur sa politique, ce que les censeurs ne font en général pas).
  • Il en donnera aussi aux serveurs des zones parentes du domaine agent, et il est donc très recommandé de minimiser le nom (RFC 9156).
  • Il n'y a pas spécialement d'authentification donc tous ces rapports doivent être traités avec prudence. Un méchant peut facilement fabriquer de faux rapports, de toute façon. Ils doivent donc toujours être vérifiés.

Cette technique a été mise en œuvre dans Drink lors d'un hackathon IETF. Drink peut à la fois signaler un domaine agent, et être serveur pour un domaine agent.

Un exemple de signalisation EDNS de cette option, vu la version de développement de Wireshark (merci à Alexis La Goutte) : wireshark-domain-report.jpeg


Téléchargez le RFC 9567


L'article seul

RFC 9547: Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022

Date de publication du RFC : Février 2024
Auteur(s) du RFC : J. Arkko, C. S. Perkins, S. Krishnan
Pour information
Première rédaction de cet article le 24 avril 2024


La question de l'empreinte environnementale du numérique suscite beaucoup de débats. L'IAB avait organisé en décembre 2022 un atelier sur le cas de l'empreinte environnementale de l'Internet dont ce RFC est le compte-rendu (tardif, oui, je sais, mais mon propre article de résumé du RFC est aussi en retard).

Le sujet est très complexe, relativement nouveau, et surtout noyé sous beaucoup d'approximations, voire de franches bêtises (l'ADEME s'en est fait une spécialité, avec des chiffres tirés du chapeau et à la méthodologie inconnue). Il y a donc du travail sur la planche. L'IAB commence par estimer que l'Internet a certes une empreinte environnementale mais peut aussi servir à diminuer l'empreinte environnementale globale, ce qui n'est franchement pas étayé (le RFC cite l'exemple de réunions physiques remplacées par des réunions en ligne, sans citer de calcul détaillé qui permettrait de voir s'il y a vraiment un gain, et en oubliant que de toute façon une réunion en ligne ne rend pas les mêmes services). Mais l'IAB note aussi que l'Internet a des effets indirects, et pas forcément positifs : il cite l'exemple de l'augmentation de la consommation de biens matériels que produit le commerce en ligne.

Clairement, l'Internet n'est pas virtuel, contrairement à ce que prétend le marketing qui abuse de termes comme cloud pour faire croire que le numérique est immatériel. A contrario, l'Internet dépend de machines, de l'électricité (et des humains qui font fonctionner ces machines). Que peut-on faire pour diminuer l'empreinte environnementale de l'Internet ? (Sans pour autant suivre les conseils débiles de l'ADEME, comme de supprimer ses messages.)

Comme tous les ateliers de l'IAB, celui-ci a fonctionné en demandant aux participants des position papers expliquant leur point de vue. Ne participent à l'atelier que des gens ayant écrit un de ces articles, ce qui garantit que tout le monde a dû travailler le sujet. Ces articles sont disponibles en ligne, plus exactement à cet endroit. (Tous les documents liés à cet atelier sont également disponibles.) Parmi les papiers acceptés :

La section 2 du RFC détaille les sujets qui étaient dans le programme de l'atelier :

  • Les impacts environnementaux directs de l'Internet (consommation électrique des machines, des routeurs aux serveurs en passant par les machines terminales, refroidissement, fabrication des machines, et leur traitement final, souvent oublié dans les études),
  • Les impacts indirects de l'Internet, provenant des effets qu'il a sur la société,
  • Les métriques (souvent très maltraitées dans les artcles parlant de l'empreinte environnementale du numérique, par exemple en confondant énergie et puissance), un sujet crucial puisqu'on ne peut pas améliorer ce qu'on ne peut pas mesurer,
  • Les questions non techniques, comme les enjeux financiers ou comme la régulation,
  • Les questions techniques où l'IETF pourrait travailler pour améliorer les choses (par exemple, mais non cité par le RFC, annoncer dans les réponses HTTP le coût environnemental de la requête),
  • Mais aussi les questions liées aux usages et aux utilisateurices, qui sont souvent sollicités, mais en général de manière culpabilisatrice (« regardez les vidéos en basse définition et pas de porno »).

Ah et, si vous vous le demandez, l'atelier a été entièrement en ligne (section 2.1 du RFC).

La première des quatre sessions de l'atelier essayait d'aborder le problème de manière générale. Le problème du réchauffement climatique est évidemment bien plus vaste que l'Internet seul et n'a pas de solution simple et unique. Et les solutions ne sont pas toutes techniques, donc il y a des limites à ce que l'IETF peut faire (ce qui ne veut pas dire qu'il ne faut rien faire !). Même la publicité est mentionnée dans cette section du RFC, avec un très prudent « davantage d'études sont nécessaires » (opinion personnelle : son attitude au sujet de la publicité est un bon moyen de savoir si votre interlocuteur veut sérieusement lutter contre le réchauffement climatique, ou bien s'il veut juste faire des discours).

Ensuite, deuxième session sur les mesures et la récolte des faits. Par exemple, où sont les gros postes de consommation électrique dans le numérique ? Les serveurs ? Les routeurs ? Les terminaux ? C'est d'autant plus important que le RFC note la quantité de fausses informations qui circulent (citant par exemple un article qui confondait MB/s et Mb/s, soit un facteur 8 de différence). De même, contrairement à ce qui est encore souvent dit, la session a mis en évidence le fait que la consommation électrique n'est pas du tout proportionnelle au trafic. Des phrases comme « envoyer un courrier dégage autant de dioxyde de carbone qu'un vol Paris-Quelquepart » n'ont donc aucun sens. (Un des papiers acceptés, « Towards a power-proportional Internet » expliquait pourquoi il fallait changer cela et comment le faire.) Par contre, les usages impactent la consommation car ils peuvent nécessiter des mises à jour du réseau.

La troisième session regardait du côté des pistes d'amélioration, plus précisement de celles sur lesquelles l'IETF pouvait agir. Le premier point est celui des mesures (insuffisantes et parfois contradictoires). Le deuxième point concernait l'influence de phénomènes comme la gigue (RFC 4689) ou l'élongation du trajet (RFC 7980) sur la consommation énergétique (si on réduit ces phénomènes grâce à de meilleurs protocoles, est-ce qu'on diminue la consommation ?). Parmi les autres optimisations possibles, le choix de meilleurs formats, plus optimisés (CBORRFC 8949 - est cité). Notez qu'un des articles acceptés pour l'atelier faisait le point sur toutes les activités de l'IETF liées à l'énergie, draft-eckert-ietf-and-energy-overview.

Et la quatrième et dernière session portait sur les étapes suivantes du travail ; en résumé, il y a du travail et, même si l'IETF ne peut pas tout, elle doit en prendre sa part. Il faut toujours garder en tête que le but n'est pas de réduire l'empreinte environnementale de l'Internet mais de réduire celle de l'ensemble de la société. Éteindre l'Internet diminuerait certainement son empreinte environnementale mais pourrait avoir des effets négatifs sur d'autres secteurs, comme les transports. Pour améliorer l'Internet sans le supprimer, plusieurs axes ont été mis en avant :

  • Mesurer, toujours mesurer, on manque d'informations,
  • Pouvoir diminuer la consommation quand il n'y a pas de travail en cours, voire hiberner, serait utile (comme dans beaucoup de cas, le problème est complexe : un routeur ne peut pas hiberner car il ne sait pas quand arrivera le prochain paquet, et il ne peut pas se réveiller instantanément),
  • Adopter de meilleurs formats de données. Comme le disait un des articles présentés, « CBOR est plus vert ».

Et les actions concrètes (section 2.4.3) ?

  • Faut-il imposer dans chaque RFC une section Environmental considerations comme il y a déjà une Security considerations obligatoire ? (La question s'était déjà posée pour une éventuelle Human rights considerations.) Pour l'instant, ce n'est pas prévu notamment parce que, dans l'état actuel des choses, la plupart des auteurs de RFC n'ont pas de connaissances suffisamment approfondies ur le sujet pour écrire une section utile.
  • Plusieurs groupes à l'IETF sont déjà au travail sur ce sujet environnemental : NMRG travaille sur les métriques (et a, par exemple, un Internet-Draft « Challenges and Opportunities in Management for Green Networking »), même chose à OPSAWG et le nouveau groupe TVR (Time-Variant Routing), comme il travaille sur le routage intermittent, a également un rôle, par exemple lorsqu'on coupe des liens pour économiser de l'énergie. Là, on est pile dans le rôle de l'IETF.
  • Curieusement, le RFC parle aussi d'éviter les NFT, qui ne sont pourtant plus guère à la mode (et n'ont jamais suscité beaucoup d'intérêt à l'IETF, de toute façon). En outre, la plupart d'entre eux tournent sur Ethereum, qui n'utilise plus la preuve de travail et n'est donc pas crucial du point de vue environnemental.

Si vous voulez participer au nouveau programme de l'IAB E-IMPACT, tout est là.

Puisqu'on parlait de la section sur la sécurité qui est obligatoire dans les RFC, notre RFC en a une, qui rappelle que :

  • Tout mécanisme par lequel on donne des pénalités (financières ou bien en terme de diminution des ressources allouées) en fonction de métriques d'empreinte environnementale doit se préparer à ce qu'il y ait des tricheurs (cf. P. McDaniel, « Sustainability is a Security Problem », à la conférence SIGSAC en 2022), qui faussent les mesures pour échapper à ces pénalités.
  • De même, tout mécanisme qui va agir sur le réseau, par exemple pour diminuer l'empreinte environnementale, peut être détourné pour une attaque par déni de service, et doit donc prévoir le problème.

Téléchargez le RFC 9547


L'article seul

Fiche de lecture : Députée pirate - comment j'ai infiltré la machine européenne

Auteur(s) du livre : Leïla Chaibi
Éditeur : Les liens qui libèrent
979-10-209-2405-6
Publié en 2024
Première rédaction de cet article le 22 avril 2024


Ce petit livre résume l'expérience de l'auteure au Parlement européen, notamment à travers ses tentatives pour faire reconnaitre le statut de salarié aux employés d'Uber (ou d'entreprises équivalentes).

Le titre et le sous-titre sont trompeurs : l'auteure n'est pas députée Pirate mais LFI, et elle n'a rien infiltré, elle a été élue au Parlement européen. Ce sous-titre ridicule fait penser à cette journaliste de droite qui avait fait un livre disant qu'elle était infiltrée chez les wokes, alors qu'elle était juste allé à quelques réunions. Mais, bon, on sait que ce n'est pas l'auteure qui fait la couverture du livre.

Donc, Leïla Chaibi raconte son expérience au Parlement européen. Elle ne surprendra pas les amateurs de l'excellente série télé Parlement, on y retrouve l'incroyable complexité du machin, le poids des lobbys, les arrangements divers, même entre partis opposés. Sauf qu'au lieu de légiférer sur le finning, comme dans la série télé, elle essaie de faire en sorte que les employés des entreprises comme Deliveroo, officiellement sous-traitants, soient reconnus pour ce qu'ils sont, des salariés.

Et ce n'est pas facile. Dans l'ambiance feutrée du Parlement, où les bruits et la réalité du monde extérieur ne pénètrent pas, intéresser les collègues à des choses concrètes n'est pas facile. Et une fois un texte voté par le Parlement, il n'est pas adopté pour autant, puisque le Parlement européen ne sert à rien. Il n'a pas l'initiative législative et ses textes ne valent que si le Conseil et la Commission le veulent bien (le fameux trilogue). Les politiciens et les journalistes qui regrettent que les électeurs ne s'intéressent pas aux élections du Parlement européen devraient se demander pourquoi (ma réponse : parce que ce Parlement n'est qu'une coquille vide, dénuée de pouvoir, il en a encore moins que le Parlement français, ce qui n'est pas peu dire).

En outre, pour cette question particulière du salariat des employés d'Uber ou de Deliveroo, l'auteure a eu à faire face à un lobbying intense du gouvernement français, très soumis à Uber, et qui a tout essayé pour saboter le projet.

Le livre est bien écrit, très vivant (malgré l'aridité du sujet), très pédagogique. Je ne voterais quand même pas LFI aux prochaines élections européennes, vu leurs positions sur l'Ukraine ou l'islamisme, mais si vous voulez comprendre le Parlement européen avant d'aller voter le 9 juin, c'est une bonne source.


L'article seul

Getting TAI time on a Debian machine

First publication of this article on 16 April 2024
Last update on of 17 April 2024


It should work by default but, apparently, on some operating systems like Debian, it does not: to get the TAI time, you need a small configuration change. I document it here for myself or for people which will use a search engine and find this page.

TAI is useful because, unlike UTC, it never adds an extra second, neither it misses one (UTC does, because of leap seconds). This makes it convenient, for instance for Internet servers. But how to get TAI time on a Debian machine?

The official answer is that when you use clock_gettime in a C program or time.clock_gettime in a Python one, you need to pass the option CLOCK_TAI. One can easily check that, on a Debian stable machine (version 12.5), it does not work: you get the same value with CLOCK_TAI or CLOCK_REALTIME (the typical clock, set on UTC). Unfortunately, no error code will tell you that something was wrong.

It seems that the kernel (which manages the clock and answers to clock_gettime) knows only UTC and, to convert to TAI, it needs to know the offset (currently 37 seconds). Debian has a file to do so, a leap seconds table, in /usr/share/zoneinfo/leap-seconds.list. This file contains all the information necessary to get TAI from UTC. But someone has to read it and to inform the kernel. This is typically done by ntpd. But it is not done by default, this is why the above test failed.

So, the system administrator needs to configure ntpd to load this file. This is done in /etc/ntpsec/ntp.conf (or /etc/ntp.conf depending on the version of ntpd you use) by adding this line:

leapfile  /usr/share/zoneinfo/leap-seconds.list
  

and restarting ntpd and waiting some time for the kernel to synchronize, it is not instantaneous.

If you see in the log file (for instance with journalctl -n 10000 -t ntpd | grep -i leap) something like:

Apr 16 08:25:39 mymachine ntpd[29050]: CLOCK: leapsecond file ('/var/lib/ntp/leap-seconds.list'): open failed: Permission denied
  

(note the file name, which is not the default one), it means you need to check the permissions of the file and that systemd or AppArmor are not adding some restrictions (the default AppArmor profile of ntpd on Debian includes /usr/share/zoneinfo/leap-seconds.list but may be you changed something).

You can check that the kernel now knows the truth, for instance with a simple Python session:


% python
Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import time

>>> time.clock_gettime(time.CLOCK_TAI)
1713284374.8322737

>>> time.clock_gettime(time.CLOCK_REALTIME)
1713284337.8329697

  

You can see that there is indeed 37 seconds of difference (plus a small value because of the delay between the two commands).

That's all. You can now use TAI in your programs. The file /usr/share/zoneinfo/leap-seconds.list is automatically managed by Debian (it is part of the package tzdata, and the reference version is https://data.iana.org/time-zones/tzdb/leap-seconds.list, itself a copy of https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, itself made by the Paris observatory) so you don't need the programs like ntpleapfetch which are necessary on other operating systems.

For instance, on a Slackware system, the file leap-seconds.list is not provided by default (there is a file named /usr/share/zoneinfo/leapseconds, with a different format, and that ntpd cannot use), so you will need to configure cron to download the proper file.

Thanks to Nicolas Sapa and Matthieu Herrb for the useful help.


L'article seul

Fiche de lecture : Des élèves à la conquête du passé

Auteur(s) du livre : Magali Jacquemin
Éditeur : Libertalia
978-2-9528292
Publié en 2023
Première rédaction de cet article le 15 avril 2024


Ce livre raconte les dix ans d'expérience de l'auteure, professeure des écoles, à enseigner l'histoire à des élèves du primaire, en essayant de ne pas se limiter à un récit venu d'en haut.

C'est tout à fait passionnant. L'auteure, partisane des méthodes Freinet (mais avec nuance et sans en faire un dogme), essaie de ne pas se contenter de parler d'histoire aux enfants mais de les faire pratiquer un peu, en partant de sources. Évidemment, vu leur âge, ielles ne feront pas de recherche vraiment originale (et ne travailleront pas forcément sur des sources primaires) mais le but est qu'ielles comprennent que l'histoire, ce ne sont pas juste des dates qu'on assène d'en haut.

Et que l'histoire ne concerne pas que des rois et des généraux. Par exemple, lorsque l'auteure enseigne dans le quartier de La Villette, elle fait travailler ses élèves sur les anciennes usines du quartier, usine à gaz ou sucrerie, avec recherche d'informations sur les conditions de travail des différentes époques.Elle les emmène même voir des archives et comprendre ainsi avec quel matériau les historiens travaillent.

La difficulté est bien sûr de laisser les élèves assez libres (principes de Freinet) tout en les cadrant pour qu'ils aient les connaissances de base. Elle note que les élèves manquent souvent de contexte et, par exemple, lors d'un travail sur les lettres entre les soldats et leurs femmes et fiancées pendant la Première Guerre mondiale, un élève a demandé pourquoi ils ne s'appelaient pas par téléphone. Il faut donc fixer les époques et leurs caractéristiques dans l'esprit des élèves.

Une autre question émouvante portait sur la guerre d'Algérie, un certain nombre de ses élèves étant issu·es de l'immigration algérienne. Faut-il parler de la torture, sachant que le grand-père d'une des élèves l'a fait ? Comment concilier l'importance de la vérité avec le souci de ne pas traumatiser les élèves ? L'auteure ne se contente en effet pas de gentilles généralités « les élèves sont créatifs, il faut les laisser faire », elle détaille les difficultés, les nombreuses questions soulevées par cet objectif de liberté, et les solutions trouvées.

Bref, je recommande ce livre à celles et ceux qui s'intéressent à l'histoire et à l'éducation.


L'article seul

Articles des différentes années : 2024  2023  2022  2021  2020  2019  2018  Précédentes années

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.

Un article de ce blog au hasard.