Mon blog

Traditionnellement, la règle d'un MTA était "Ne touche pas au courrier, fais-le passer sans changement". Le MTA était juste un facteur, pas un secrétaire de rédaction, afin de garantir quel acteur a la responsabilité d'un message. Pour tout un tas de raisons, cette règle semble avoir de moins en moins appliquée. Ce nouveau RFC peut donc se permettre de spécifier un mécanisme pour demander à un serveur SMTP de faire des conversions du contenu du message.

Le serveur SMTP peut donc annoncer, en utilisant les mécanismes de Extended SMTP (RFC 2821) qu'il accepte ce nouveau mécanisme, s'il est prêt à effectuer ces conversions coûteuses.

Voici un exemple de session SMTP où le client va demander une conversion d'image dans un autre format, en utilisant la syntaxe du RFC 2533 :

La version actuelle, la 4, du protocole IP avait eu bien de la chance, d'être déployée dans un environnement quasi-vierge. IP version 6 doit au contraire se frayer un passage dans un monde où tout est en IPv4. D'où l'importance des mécanismes de transition, dont ce RFC décrit deux exemples.

Cette transition est un des principaux défis auquel doit faire face IPv6. Il est même possible que sa difficulté soit la cause principale de ses problèmes, plus que ses qualités ou défauts intrinsèques.

Mettant à jour le RFC 2893, notre RFC décrit deux mécanismes (il en existe de nombreux autres, plus exotiques) pour assurer la transition : la "double pile" qui consiste pour une machine à avoir les deux protocoles (et donc les deux compétences pour son administrateur) et le tunnel configuré pour faire passer de l'IPv6 dans un Internet très majoritairement IPv4.

Dans le premier cas, la machine a les deux protocoles et, parfaitement bilingue, peut parler avec n'importe quelle autre machine, que cette dernière soit v4 ou bien v6. Mais cela empêche d'abandonner IPv4 et sa pénurie d'adresses. Et cela ne résout pas tous les problèmes comme par exemple "Quelle adresse choisir si la machine avec laquelle je veux parler est également double pile ?" (très partiellement discuté dans la section DNS du RFC).

Le tunnel traite un problème un peu différent : une des extrémités du tunnel met les paquets IPv6 dans un paquet IPv4, les envoie à l'autre extrémité du tunnel, où on décapsule le paquet IPv6. La technique étant relativement complexe dans ses détails, elle forme l'essentiel de notre RFC.

Pour plusieurs raisons, comme le problème de MTU que notre RFC discute en profondeur, les performances sont alors moins bonnes.

Dans le cas du tunnel, deux machines qui n'ont qu'IPv6 peuvent se parler au travers de l'Internet actuel (peu d'opérateurs routent la v6). Mais cela ne résout pas le problème de parler aux machines purement v4 (comme l'est, aujourd'hui, www.bortzmeyer.org).

Les blogs et la syndication étant actuellement deux des occupations les plus populaires sur le Web, il fallait donc un livre chez O'Reilly sur les formats de syndication : c'est chose faite.

Ce livre couvre les différents formats RSS et une version assez préliminaire du format Atom (qui vient d'être normalisé dans le RFC 4287). Le chapitre historique qui retrace l'histoire de la syndication et des guerres entre formats nommés RSS est d'ailleurs passionnant et éclaire bien des questions.

Il continue par un chapitre sur l'utilisation de la syndication (il cite de nombreux outils mais pas un de mes favoris, rss2email, qui permet de convertir un flux de syndication en liste de diffusion par courrier). Puis il décrit en détail les principaux formats de syndication, s'attardant sur les innombrables modules qui ont fait le succès de la version 1.0 de RSS (celle qui utilise RDF).

Les chapitres suivants sont plus techniques : analyse de flux de syndication depuis un programme (presque tous les exemples sont en Perl), avec discussion pour savoir si l'analyseur doit être strict ou bien laxiste, des considérations sur les flux réels rencontrés dans la nature et surtout un chapitre passionnant sur des utilisations « inhabituelles » de la syndication, essentiellement pour des tâches d'administration système ou bien pour exploiter des sources d'information qui ne sont pas syndicatées (par exemple Google, avec un programme de conversion de recherches Google en flux RSS).

Bref, un livre assez court, très bien fait, peu à jour pour tout ce qui concerne Atom mais qui est quand même une bonne introduction au monde merveilleux de la syndication.

Un assez court RFC, pour décrire un cas pathologique de routage BGP entrainant un coincement permanent dans un état non-optimal.

Depuis sa normalisation sous sa forme actuelle, dans le RFC 1771, le protocole de routage BGP a largement servi l'Internet et a connu peu de problèmes fondamentaux. C'est un des grands succès de l'IETF.

Néanmoins, BGP réserve toujours son lot de surprises : dans un immense réseau sans administration centralisée, comme l'Internet, il y a toujours des cas particuliers gênants. Ce RFC décrit un syndrome particulier, le "coincement" (wedgie), où le routage converge vers un état non-optimal (le trafic IP ne passe pas là où il devrait passer) qui peut être semi-permanent, c'est-à-dire survivre jusqu'au redémarrage d'un ou de plusieurs routeurs.

La syndication des sites Web, c'est-à-dire la récupération de résumés structurés par un autre site, par le biais des flux (feeds) RSS est à la mode. Tout le monde en fait et n'importe quel blog affiche un lien vers son flux RSS. Beaucoup de gens lisent le Web essentiellement via un agrégateur RSS, qui lit de nombreux flux RSS et présente ces résumés sous une forme qui permet une navigation facile.

Mais ce succès cache une rude rivalité entre les différents RSS. Il en existe plusieurs, le 0.9, le 1.0, le 2.0 et ce ne sont pas des évolutions plus ou moins récentes de la même norme, mais des normes bien différentes et incompatibles.

L'IETF tente donc de régler le problème, avec la norme Atom. Atom est spécifié dans ce nouveau RFC, et peut-être fera t-il la synthèse entre tous les formats de syndication. Ou bien peut-être rajoutera t-il juste une Nième norme incompatible avec les autres, l'avenir le dira.

Rien d'extraordinairement nouveau dans ce RFC, qui reprend les élements classiques d'un flux RSS. Atom est bâti sur XML et et ses éléments de type content peuvent inclure du texte brut, du XHTML mais aussi n'importe quel élément XML, que l'usage des espaces de noms sépare de l'XML d'Atom.

On note que ce RFC est, à ma connaissance, le premier RFC utilisant XML qui se serve de RelaxNG et non pas les W3C Schema comme langage de schéma, pour décrire les éléments autorisés et leurs relations. À une époque, un groupe de l'IETF avait tenté de rendre obligatoire l'usage des W3C Schema, plus complexes et moins expressifs mais l'IETF avait finalement pris, dans le RFC 3470 une approche plus nuancée, reconnaissant le pluralisme des langages de schémas, même si ce RFC montre un fort biais en faveur des W3C Schemas, utilisés notamment dans les RFC 3730 et RFC 3981.

Ce blog est doté d'un flux de syndication Atom, en /feed.atom. Son moteur de recherche permet de produire le résultat des recherches au format Atom.

Il existe désormais trois langages courants pour écrire des schémas XML c'est-à-dire pour décrire les éléments autorisés ou interdits dans un document XML. RelaxNG, le plus récent, est le moins connu des trois et méritait donc bien un livre chez O'Reilly, avec un faisan sur la couverture, pour gagner davantage de popularité.

Autrefois, les schémas XML ne pouvaient s'écrire qu'avec une DTD et c'est la seule solution décrite dans la norme XML. Les limitations des DTD ont mené à l'invention de nouveaux langages, le plus connu étant W3C Schema, aussi dit XSD.

XSD est très complexe, souffre d'une syntaxe XML verbeuse, et est en même temps limité dans les schémas qu'il permet de décrire. Bien qu'il bénéficie d'une présence supérieure dans les médias, il n'a pas été choisi pour certains gros projets (Docbook, OpenDocument, Atom, etc) qui ont préféré RelaxNG.

C'est un signe de la simplicité de RelaxNG que le fait que ce livre soit à la fois relativement mince et très complet : il est rare qu'un sujet en soit absent. L'annotation d'un schéma (par exemple pour le documenter ou pour y mettre des métadonnées) fait ainsi l'objet d'un chapitre entier.

L'auteur, Eric van der Vlist, est également l'auteur du O'Reilly sur XSD, il connait donc bien les deux "concurrents", même si sa préférence pour RelaxNG ne fait guère de doute. Francophone, il est également un des piliers de la liste xml-fr, où il répond en général très rapidement aux questions.

Ce livre couvre donc l'essentiel de RelaxNG : ses principes (ne valider que la structure, pas le contenu des éléments, ne pas changer les valeurs des éléments), puis sa syntaxe (RelaxNG a deux syntaxes, une XML et une dite compacte, bien plus lisible).

Il explique ensuite comment contraindre les valeurs des éléments grâce aux bibliothèques de types (extérieures à RelaxNG proprement dit), puis explique en détail comment réaliser des schémas qui, au lieu d'être des blocs monolithiques, soient extensibles ou restrictibles facilement, de façon à ce que leurs utilisateurs puissent n'utiliser que ce qu'ils veulent.

Le livre se termine sur un remarquable chapitre sur le déterminisme dans les schémas et pourquoi RelaxNG ne l'impose pas.

Notez que le schéma des fichiers XML de ce blog est écrit en RelaxNG.

OPES est composé d'un grand nombre de RFC. Celui-ci décrit l'adaptation d'OPES au cas du protocole HTTP, le protocole principal du Web.

S'appuyant sur les RFC 3835, pour la description de l'architecture, et RFC 4037 pour OCP, le protocole de communication entre un processeur OPES et son serveur sous-traitant, notre RFC décrit les adaptations spécifiques à HTTP, quels messages transmettre, lesques peuvent être ignorés, les transformations autorisées et sous quelles conditions, etc.

OPES spécifiant que les processeurs OPES doivent obéir à une exigence de traçabilité et laisser trace de leur activité, ce RFC spécifie deux nouveaux en-têtes HTTP que nous verrons dans les flux HTTP, dès que des processeurs OPES seront déployés : OPES-System, le principal, qui identifiera le processeur OPES, et OPEN-Via.

Les deux exemples complets de session donnés par notre RFC concernent un application classique pour le Web, le filtrage de certains URL (le processeur OPES reçoit une demande GET et renvoie une erreur 403, "accès interdit") et un service de traduction au vol des pages, plus futuriste.

Aujourd'hui, on entend et on lit très souvent, comme si cela allait de soi, que l'interface d'un logiciel doit être graphique et, de préférence, WYSIWYG. Toute mise en doute de ce dogme ne peut être, semble t-il, que l'œuvre de dinosaures obtus, attachés aux incompréhensibles commandes d'Unix. C'est ce dogme que Neal Stephenson, le célèbre auteur de la trilogie "Cryptonomicon" a décidé d'ébranler.

Dans ce petit livre, le raisonnement de Stephenson est simple : la ligne de commande, contrairement à l'interface graphique, est un langage. Comme tout langage, elle prend du temps à être maitrisée. Mais, une fois que c'est fait, elle permet bien plus d'expressivité qu'une interface graphique, qui ne permet que de choisir parmi des options pré-définies.

Stephenson compare l'utilisateur de l'interface graphique à un singe qui ne sait pas parler, seulement montrer du doigt (ou de la souris) la banane qu'il veut, peut-être en ajoutant quelques grognements.

Stephenson ne se limite pas au sujet évoqué dans le titre : il analyse toute l'évolution de l'informatique depuis vingt ans, l'influence des feuilletons télé et de Disneyland sur la mentalité états-unienne, les voitures, et les épopées antiques comme Gilgamesh. Qui a dit que les informaticiens étaient incultes et ne philosophaient pas ?

Après le RFC 3752, qui décrit à quoi peut servir OPES, le cadre conceptuel des entités intermédiaires qui se mettent entre client et serveur pour modifier requêtes et/ou réponses, ce RFC décrit l'architecture d'OPES.

Notre RFC décrit donc le vocabulaire d'OPES (producteurs, consommateurs, flux, entités) et explique leur rôle. L'entité va, soit modifier un flux (en s'insérant entre producteur et consommateur), soit distribuer le travail à une autre entité OPES. Plusieurs entités OPES peuvent en effet transformer successivement le flot.

La communication avec ces "sous-traitants" se fera avec le futur OCP (OPES Callout Protocol), dont le cahier des charges est le RFC 3836 et qui est décrit dans le RFC 4037.

Le RFC décrit également les règles que suit un entité OPES et qu'il faut donc lui transmettre.

Comme OPES a suscité beaucoup de réserves, notamment de la part de l'IAB (dans le RFC 3238), notre RFC consacre toute sa section 4 à y répondre.

Tel qu'il est donc spécifié, le service OPES doit donc :

• Rendre obligatoire le consentement explicite du producteur ou du consommateur,
• Être accessible en IP, donc ne pas être totalement invisible,
• Révéler sa présence en marquant son intervention (par exemple, en HTTP, en ajoutant un en-tête),
• Permettre d'exprimer des préférences de protection des données, par exemple avec P3P.
• Et d'autres obligations.

Traditionnellement, l'architecture de l'Internet était de bout en bout, ce qui signifie que les éléments intermédiaires ne jouaient qu'un rôle réduit. Aujourd'hui, cette architecture a de fait évolué et les "trucs au milieu", qui changent les données échangées sont de plus en plus nombreux. OPES (Open Pluggable Edge Services) tente de formaliser cette nouvelle architecture.

C'était un principe cardinal de l'Internet : mettre l'intelligence aux bords du réseau, chez le client et le serveur, et ne pas tenter de fournir des servics avancés dans le cœur du réseau. Ce principe a été informellement remis en cause par l'accumulation d'éléments intermédiaires qui ajoutent leur propre traitement. Citons par exemple :

• Un relais Web comme Squid qui garde en mémoire les pages demandées, pour les servir plus rapidement la prochaine fois,
• Un relais Web comme Junkbuster qui filtre les publicités hors des pages Web.

Ces logiciels ne relèvent pas d'une architecture commune et chacun utilise son propre protocole, son propre mécanisme de configuration, ses propres méthodes de traçabilité...

OPES va donc essayer d'ordonner tout cela. Ce premier RFC décrit des scénarios d'usage afin de donner une première approche d'OPES et des cas où il peut être utile.

Notre RFC décrit donc des services qui peuvent modifier les requêtes envoyées à un serveur ou bien modifier les réponses du serveur. Il explique ce qu'est un processeur OPES (l'entité qui va faire les modifications) et un serveur sous-traitant (callout server), auquel le processeur transmet certains traitements. Une description plus précisé de l'architecture d'OPES figure dans le RFC 3238.

Comme OPES soulève d'énormes problèmes à la fois liés à l'architecture (il redéfinit une architecture traditionnelle de l'Internet) et à la sécurité (puisqu'un processeur OPES s'interpose entre deux acteurs, il peut agir de façon maligne), l'IAB a exprimé, dans le RFC 3238 de sérieuses réserves auxquelles le RFC 3835, qui décrit l'architecture d'OPES, répond.

Le RFC 3513 sur l'adressage IPv6 spécifiait des adresses purement locales à un site, les adresses site-local qui commençaient par FEC0::/10. Ces adresses ayant été rendues obsolètes par le RFC 3879, notre RFC 4193 spécifie un remplacement : des adresses quasi-uniques mais attribuées sans registre central.

Les adresses locales à un site ont été très utiles lorsque les RIR n'attribuaient pas d'adresses IPv6 et qu'il était difficile d'en obtenir. Elles permettaient de se mettre doucement à IPv6, sans démarches bureaucratiques. Mais elles avaient le même inconvénient que les adresses privées IPv4 du RFC 1918 : en cas de connexion de deux sites utilisant ces adresses (par exemple suite à une fusion d'entreprises), le risque de collision est élevé.

Notre RFC propose donc une meilleure solution : dans un espace réservé, FC00::/7, le site qui souhaite des adresses quasi-uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC, qui utilise l'heure et l'adresse MAC comme point de départ, et a pour but d'éviter que tout le monde prenne le même préfixe. La probabilité de collision entre sites est donc très faible, vue la taille de l'espace d'adressage de IPv6.

Si on veut son ULA (Unique Local Address), on peut faire tourner cet algorithme en http://www.kame.net/~suz/gen-ula.html ou en http://www.sixxs.net/tools/grh/ula/.

Le DNS n'est pas sûr, on le sait (le RFC 3833 décrit les vulnérabilités du DNS en détail). Comme la quasi-totalité des applications de l'Internet dépendent du DNS à un moment ou à un autre, cette vulnérabilité inquiète beaucoup de gens. Notre RFC, avec ses compagnons RFC 4034 et RFC 4035, propose une solution à certains de ces problèmes, solution nommée DNSSEC.

Ce RFC décrit le deuxième DNSSEC, le premier était présenté dans le RFC 2535 mais n'a jamais été un succès.

DNSSEC-bis propose une sécurisation des données, pas du canal. La cryptographie permet en effet de sécuriser un canal de communication entre deux machines (ce que fait SSL) ou bien de sécuriser le message lui-même, qui peut alors être authentifié et protégé quels que soient les messagers intermédiaires : c'est ce que fait DNSSEC.

Pour cela, DNSSEC signe cryptographiquement, par la cryptographie asymétrique, les enregistrements DNS. Plus rigoureusement, il signe des RRsets ou Resource Record Sets, c'est-à-dire un ensemble d'enregistrements ayant même nom et meme type (en pratique, rassurez-vous, la différence entre enregistrement et RRset est peu importante). Cette signature est portée par un nouveau type d'enregistrement, le RRSIG. Le RRSIG authentifie un enregistrement qui figure en partie gauche tandis que la partie droite contient la signature, ainsi que quelques informations utiles comme l'algorithme utilisé (c'est typiquement RSA + SHA1).

Les parties publiques des clés utilisées par le registre de la zone pour la signature sont publiées dans des enregistrements de type DNSKEY. Pour "amorcer la pompe" de DNSSEC, on récupère typiquement ces clés via un canal non-DNS, par exemple un accès à un serveur Web authentifié.

Voici par exemple un enregistrement RRSIG tel que l'affiche dig :

   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

Ici, le signataire example.com (ce nom apparait en partie droite) a authentifié l'adresse IPv4 (la signature couvre un enregistrement de type A, c'est indiqué juste après le type RRSIG) de host.example.com. La signature est le texte en base64 (RFC 4648) qui figure à la fin. S'il possède la clé de example.com (on peut la récupérer, par exemple, dans l'enregistrement de type DNSKEY ou "hors bande", par exemple sur une clé USB remise en mains propres), un résolveur DNS pourra alors être sûr de l'authenticité de cette adresse et ceci même si l'enregistrement a été transmis via des relais inconnus.

Enfin, DNSSEC spécifie également deux autres types d'enregistrement, plus subtils : NSEC et DS.

Les NSEC servent à répondre à une question délicate : authentifier la non-existence d'un domaine. En effet, DNSSEC marche par la signature d'enregistrements (ce choix a été fait pour éviter de modifier trop fortement le protocole DNS). Mais, si un nom n'existe pas, il n'y a pas d'enregistrement à signer ! Le problème est résolu avec les enregistrements de type NSEC (Next Secure). Ces enregistrements (qui sont signés comme les autres) indiquent quel est le prochain domaine de la zone. Ainsi, lorsqu'on demande nimportequoi.example.org, le serveur de example.org peut répondre par un NSEC pointant vers le domaine suivant.example.org qui, lui, existe. Voici un exemple d'enregistrement NSEC qui dit que alfa.example.com a des enregistrements de quatre types et que le nom suivant est host.example.com (donc, on peut être certain que beta.example.com n'existe pas) :

   alfa.example.com. 86400 IN NSEC host.example.com. (
                                   A MX RRSIG NSEC)

On note que, puisque les NSEC permettent d'obtenir le domaine suivant, puis le suivant du suivant, ils donnent donc potentiellement accès à l'intégralité de la zone, tout comme un transfert de zones. Ce problème, connu sous le nom de zone walking a contribué à la décision de certains registres (typiquement ceux qui ne veulent pas distribuer leur fichier de zone) de ne pas déployer DNSSEC. C'est ainsi que Simon Josefsson a développé un programme de zone walking qui montre bien la vulnérabilité des zones DNSSEC. Ce problème est résolu en remplaçant les NSEC par les NSEC3 du RFC 5155.

Les enregistrements DS (Delegation Signer), quant à eux, permettent d'authentifier les délégations. En effet, signer les enregistrements de délégation (les NS, pour name servers) dans la zone parente ne suffit pas, puisqu'il faut aussi permettre de trouver la clé de la zone fille. Un enregistrement DS va donc pointer vers l'enregistrement DNSKEY de la zone fille (si celle-ci n'est pas elle-même signée, le DS est inutile).

DNSSEC bis est aujourd'hui mis en œuvre dans plusieurs serveurs de noms dont BIND (à partir de la version 9.2) et NSD (à partir de la version 2.3.0).

L'outil dig permet d'effectuer une requête avec DNSSEC :

% dig +dnssec @ns3.nic.fr +dnssec A ripe.net.  
...
;; ANSWER SECTION:
ripe.net.               600     IN      A       193.0.0.214
ripe.net.               600     IN      RRSIG   A 5 2 600 20051221061607 20051121061607 49526 ripe.net. 2NePKf/On6ZgcQD0zpinEou4QiojhW1A2IKoxHBdtawMa7aSeQdL+hZp RktjuqbFwv9rkVPOVXPGWhtB9sSfoI5         aMjHWjrjdsAfc6LTBLr2veHiV +6qOeiV24ALYwZKpwP5tEh6hiJXN6fVAxQ6ye32u7+01xL+dG9oaMA6x 6x/5GkJKHfS4E         EbF+OaUX2m2DlQHsh0n

On voit ici la réponse à la question posée (l'adresse de ripe.net) et la signature.

On peut aussi récupérer la partie publique de la clé :

% dig  DNSKEY ripe.net.                     
...
;; ANSWER SECTION:
ripe.net.               3480    IN      DNSKEY  256 3 5 AQPhEMiv80EEjX6gYDc8E7Osfumf4C/pZxBmTRRiOVL3h6lx1CIVCyPl V34WuVUkqqpID2fxGzmUFTG0f61x9lzRapX0lIdlo2AtRCYWpkPY+D3F IrMYukWiC8pyeHF/a/Wk6HZNLVYko2dcLwUpfiDrK7zCFgR9DLcZkOmj N5xB9CBzVrZDkd1lsGCC9hytndbLuZ3VtpE=
ripe.net.               3480    IN      DNSKEY  257 3 5 AQOTT7bx7N38sPgDWniKnHnSnTxYxdMpEq7dyrDHDaRQgq7DULPWX6ZY 0U1XKKMuNloHRP7H8r17IBhgXcPZjZhtSGYagtPe22mhAMjZ4e8KGgP9 kJTTcpgzoYulvSiETBxjQ42EZWJG+6bxK+vyrwTbqEScmdZfqQz3ltVw k6Sos0UuSmTeb2C6RSkgHaTpKCu5yIrncVer1gvyvXGv3HOel8jiDGuj 8peNByiaSRD4OIJUxu1jUqLvfDH6Anq6ZeNohxsYVUVajiRl1T+3x5+8 acgwat3V55Z1Nm4O4Z1BKECdPO65EXIEC7/pqs5XvpsiJbafdj03uqLS a3aScpy3

Et si je veux signer ma zone, quelles solutions puis-je utiliser ? Une version récente de BIND inclue les logiciels dnssec-keygen et dnssec-signzone qui fournissent tous les services nécessaires. Testons-les sur une Debian en version lenny. Il faut d'abord générer la clé de la zone :

% dnssec-keygen -a DSA  -b 1024 -n  ZONE sources.org

Cette commande laissera sur le disque les fichiers Ksources.org.+003+55957.key et Ksources.org.+003+55957.private. Il faut évidemment les sauvegarder précieusement (autrement, il faudra changer la clé, une opération complexe qu'on nomme le rollover) et vérifier que la clé privée n'est pas accessible à tous.

Il faut alors inclure la clé publique (ici, le contenu de Ksources.org.+003+55957.key) dans le fichier de zone.

Ensuite, à chaque modification de la zone, il faudra signer :

% dnssec-signzone sources.org
sources.org.signed

Le programme dnssec-signzone produit un fichier du même nom que la zone mais suffixé par .signed. Un exemple de règle dans un Makefile pour automatiser cela est :

reload: sources.org.signed example.org.signed foobar.example.signed

%.signed: %
        @echo Signing requires a lot of entropy in /dev/random, do not hesitate to load the machine...
        dnssec-signzone $^

L'avertissement sur l'entropie vient du fait que, sur une machine Linux peu chargée, /dev/random se bloque s'il n'a pas assez d'entropie pour générer des nombres vraiment aléatoires, et on a l'impression que dnssec-signzone est arrêté.

dnssec-signzone produit également un fichier avec les enregistrements DS, pour qu'on puisse les transmettre à son registre (uniquement pour une nouvelle clé ou bien une clé qui change).

Le cas présenté ici, avec une seule clé, est le plus simple. Elle est peut-être préférable pour les petites zones, ou pour ceux qui débutent avec DNSSEC. Mais le RFC recommande une autre approche, plus complexe mais plus sûre, la séparation en deux clés, la KSK (Key Signing Key) et la ZSK (Zone Signing Key). La première, introduite dans le RFC 3757, ne sert qu'à signer la seconde. Elle est typiquement très robuste (à l'heure actuelle, typiquement de 4096 bits) et change relativement rarement car c'est elle qui est utilisée par les autres zones, comme trust anchor. La seconde, la ZSK, est plus légère (par exemple 1024 bits, taille au delà de laquelle la signature des grandes zones devient vraiment pénible) et sert à signer les enregistrements. Du fait de cette utilisation, il y a davantage d'information qui « fuit »,; et qui peut donc aider un attaquant. Elle change donc plus fréquemment, ce qui ne pose pas trop de problèmes opérationnels puisqu'elle n'est connue que localement.

Pour créer la KSK, on doit normalement s'entourer de multiples précautions (si la zone qui l'utilisera est vitale, on s'enfermera dans une cage de Faraday, on se déconnectera du réseau, etc). Ensuite, on tape :

% dnssec-keygen -f KSK \
    -a RSASHA1 -b 4096 -n ZONE example.org

(Cette opération peut prendre plusieurs heures sur une machine qui a peu d'entropie.) On garde évidemment précieusement la partie privée de cette clé ! On publie la partie publique (par exemple en l'envoyant à la zone parente ou bien en la mettant sur son site Web) et on la met dans son fichier de zone.

La ZSK se génère avec une commande presque identique à part l'option -f et une clé plus petite :

% dnssec-keygen \
    -a RSASHA1 -b 1024 -n ZONE example.org

Les deux clés se mettent ensuite dans le fichier de zone. Au moment de la signature, dnssec-signzone ne signera qu'avec la ou les clés qui n'ont pas été générées avec l'option -f KSK. Toutefois, BIND ne trouve pas forcément les signatures seul et, selon la façon dont les clés ont été nommées et/ou placées, il peut être utile de dire à dnssec-signzone quelle est la KSK (option -k) et quelle est la ZSK (nom de fichier après le nom de la zone) :

dnssec-signzone -t -k example.org.KSK example.org example.org.ZSK 

Notez que tout ce processus peut s'automatiser partiellement avec des outils comme OpenDNSSEC.

Quelques documentations sur la configuration de DNSSEC :

• DNSSEC in 6 minutes,
• DNSSEC HOWTO.
• BIND 9 Administrator Reference Manual,

Voyons maintenant quelques points important de DNSSEC mais qui ne sont pas mentionnés dans le RFC (celui-ci ne fait que spécifier un protocole, il ne traite pas de tous les problèmes liés à ce protocole).

On notera que le RFC ne spécifie pas l'API du service. Que doit faire une fonction comme getaddrinfo(3) lorsqu'une vérification DNSSEC échoue ? L'API actuelle ne permet pas de donner de détails sur la cause de l'échec. En outre, à ma connaissance, aucune mise en œuvre actuelle ne permet à l'administrateur système de définir une politique de sécurité (par exemple dans son fichier de configuration /etc/resolv.conf).

Aujourd'hui, plusieurs registres ont commencé à déployer DNSSEC comme le RIPE-NCC, notamment pour les domaines de résolution inverse (in-addr.arpa) qu'il gère ou bien le registre suédois. La racine du DNS est en cours de signature.

Si on souhaite plus d'informations, on pourra regarder un excellent article de Bert Hubert, l'auteur de PowerDNS ou bien le portail de DNSSEC. Et, sur mon blog, il y a de nombreux articles sur DNSSEC.

Comme beaucoup de protocoles Internet, le DNS avait été conçu sans se préoccuper de la sécurité. Comme souvent, on s'aperçoit avec DNSsec que l'ajout de la sécurité à un protocole n'est pas si triviale que ça. Mais, avant de penser à la solution,il faut étudier le problème : c'est ce que fait ce RFC qui analyse les risques liés au DNS et les possibilités qu'offre ces failles aux fraudeurs.

Modifier des réponses DNS ou bien injecter de fausses réponses qui seraient acceptées par les clients permet en effet nombre d'attaques, comme de rediriger les requêtes censées aller au serveur d'une banque vers le serveur d'un méchant qui copierait les mots de passe.

Il faut noter que le RFC ne parle que des faiblesses du protocole, pas des bogues des mises en œuvre.

Enfin, rappelons que beaucoup d'attaques d'usurpation ne nécessitent pas de faille du DNS : ces attaques peuvent simplement exploiter la crédulité ou bien la distraction de l'utilisateur. D'où l'importance de mesures de sécurité comme celles de SSH qui contrôle la clé cryptographique du serveur où il se connecte.

Le RFC note que les attaques suivantes sont possibles :

• Interception des paquets (questions ou réponses) et émission par l'attaquant d'un autre paquet. Tous les protocoles permettent cela mais c'est plus facile avec le DNS, où question et réponse tiennent souvent dans un seul paquet chacune. Cela nécessite en général que l'attaquant soit situé entre le client et le serveur.
• Fabrication d'une réponse vraisemblable. Cela peut se faire en devinant l'ID (un numéro choisi par le client DNS et qui lui permet de mettre en correspondance requêtes et réponses) d'une requête (et le nom demandé), ce que la faible taille des ID (16 bits) rend possible.
• Chainage de noms, une technique qui consiste à injecter des données dans le cache de la victime en utilisant une indirection. Par exemple, une réponse de type NS (name server) va entrainer des requêtes dans un domaine potentiellement complètement différent, pour résoudre les noms en partie droite de la réponse.
• Trahison par un serveur : si je branche mon portable sur un réseau que je ne contrôle pas, le serveur cache de ce réseau peut envoyer à ses clients des données mensongères. Même chose si un des secondaires d'un domaine décide de tricher, alors qu'il devrait n'envoyer que ce qu'a décidé son primaire.
• Déni de service

Le RFC discute également des problèmes qui ne sont pas des vulnérabilités à proprement parler mais qui compliquent la solution de sécurité, comme la nécessité de pouvoir signer la non-existence d'un domaine ou bien les jokers (wildcards), qui compliquent tant de protocoles liés au DNS.

Le RFC se termine par une discussion des problèmes liés à DNSsec lui-même (DNSsec ne résout pas toutes les failles de sécurité du DNS).

Encore un RFC sur les procédures et pas sur les protocoles. Celui-ci vise à éduquer les participants aux organismes de normalisation en promettant plus d'efficacité à leurs actions, s'ils suivent quelques règles.

Aujourd'hui, une grande partie de la politique industrielle et parfois de la politique tout court se fait via des organismes de normalisation comme l'IETF, le W3C ou OASIS. Ce qui se passe dans ces organismes devient donc de grande importance et beaucoup de gens tentent d'y participer, souvent avec des résultats mitigés, par exemple car ils ont ignoré la culture particulière de l'organisme où ils sont intervenus.

Ce RFC est donc destiné à tous ceux qui voudraient participer à un organisme de normalisation avec succès. Il donne des conseils de bon sens, assez classiques mais toujours bons à rappeler : par exemple qu'il est normal qu'un organisme apparaisse toujours comme une secte fermée, quand on le regarde de l'extérieur. Ou que la conquête d'une certaine influence prend du temps et des efforts. Ou encore qu'il faut être actif dans le groupe, qu'on ne peut pas espérer devenir quelqu'un qui compte juste par un ou deux messages sur une liste de diffusion.

Description des techniques informatiques utilisées pour développer ce blog : XML, Relax NG, XSL, etc. Les pages sont statiques (produites essentiellement par XSL) et les fichiers XML édités avec emacs.

Ce RFC est très court mais a suscité (et suscite toujours, via d'actuelles tentatives de le modifier) beaucoup de débats. Il est en effet situé à l'intersection des domaines de l'IETF et de l'ICANN puisqu'il normalise certains noms de TLD et certains noms de domaines dans les TLD comme .com.

On a souvent besoin de noms de domaine sans avoir envie de les réserver : le cas le plus fréquent concerne la documentation. Si j'écris un texte expliquant comment configurer le logiciel, mettons, NSD, j'ai besoin de mettre des noms de domaines et il est préférable d'utiliser des noms qui ne sont pas déjà en service. En effet, un certain nombre de lecteurs utiliseront littéralement le nom qui apparait dans la documentation, au lieu de comprendre que ce n'est qu'un exemple. On voit ainsi souvent des francophones utiliser, bien à tort, le domaine toto.fr alors qu'il est bel et bien alloué et que son titulaire n'est peut-être pas ravi de cet usage !

Un autre usage courant concerne les tests de logiciel : si on veut créer un domaine "bidon" sur ses serveurs, il est préférable de ne pas masquer ainsi un domaine réel.

Ce RFC réserve donc quatre TLD, .example pour la documentation, .test pour les tests, ainsi que .invalid et .localhost. Malgré une demande fréquente, il n'existe pas dans ce RFC de TLD pour un usage local (.local était souvent proposé mais n'a acquis un statut officiel qu'avec les RFC 6761 et RFC 6762, bien plus tard). L'IETF est plutôt hostile à tout ce qui est "local", notamment en raison des problèmes que cela pose lorsque deux organisations fusionnent ou bien se connectent (c'est pour la même raison que les adresses IPv6 site-local ont été remplacées, dans le RFC 4193). La méthode recommandée est donc plutôt d'utiliser un sous-domaine pour les données privées par exemple local.example.net.

Le RFC réserve également trois domaines de second niveau, example.com, example.net et example.org. Tous ces domaines ont été bloqués par l'IANA et, pour les domaines de second niveau, un serveur Web a été installé, qui renvoie à ce RFC.

Un livre original qui est plutôt orienté vers l'apprentissage de la programmation fonctionnelle que vers celui du langage Haskell.

Il n'est probablement pas indispensable de savoir déjà programmer et ce livre pourrait être utilisé comme support de cours. L'auteur commence par les concepts de base de la programmation fonctionnelle, et, pour une fois, les exemples ne sont pas tous les sempiternels exemples mathématiques à base de factorielle et de Fibonacci mais des exemples graphiques avec des images que l'on transforme (pour faciliter la mise en œuvre, une intéressante implémentation entièrement en art ASCII est présentée par la suite).

Il explique ensuite l'environnement Hugs, utilisé pour la pratique, puis expose les différents concepts utilisés : listes, fonctions comme objets de première classe (pouvant être passées en argument), application partielle et curryfication, introduction à la preuve de programmes, le système des classes, la programmation paresseuse...

Comme le livre vise à enseigner la programmation fonctionnelle, plus que le langage Haskell, d'importants pans de celui-ci ne sont pas traités du tout : les monades sont très vite expédiées, les enregistrements nommés pas mentionnés, l'inférence de types est complètement absente (et l'auteur déclare donc systématiquement ses types). Les questions pratiques comme le contenu du Prélude, les bibliothèques existantes ou les entrées/sorties sont très peu traitées. Le lecteur ne doit donc pas s'imaginer qu'il pourra programmer en Haskell immédiatement, ni lire le code de darcs immédiatement.

Les URI comme http://www.bortzmeyer.org/4151.html ou ISBN:0-395-36341-1 (RFC 8254) sont devenus la référence en matière d'identificateurs de ressources sur le réseau. Quelques alternatives comme les DOI n'ont jamais eu aucun succès (la lettre d'information de l'International DOI foundation ne contient que des URL et aucun DOI). Les URI commencent toujours par un schéma, un plan comme http ou mailto et ce RFC crée un nouveau schéma : tag.

Ce nouvau schéma sert uniquement à construire des identificateurs uniques, stables et compréhensibles. Il n'est pas prévu de mécanisme de résolution en adresses.

Le RFC décrit les autres éléments du cahier des charges et les raisons pour lesquelles les autres mécanismes ne sont pas satisfaisants. Notamment, un identificateur doit pouvoir être créé sans recourir à une autorité centrale.

Ainsi, un identificateur tag: est typiquement construit à partir d'un nom de domaine ou d'une adresse de courrier (mais n'importe quelle source d'unicité - tagging entity - comme un numéro de téléphone pourrait être utilisée), suivie d'une date de création. Par exemple, cela peut donner tag:bortzmeyer@internatif.org,2005-10-26:/Blog/RFC4151.

Comme exemple d'utilisation, le RFC 4151 sur le format de syndication ATOM recommande que chaque entrée du flux de syndication aie un identificateur unique, le <atom:id> et conseille When an Atom Document is relocated, migrated, syndicated, republished, exported or imported, the content of its atom:id element MUST NOT change. Put another way, an atom:id element pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their atom:id elements. It is suggested that the atom:id element be stored along with the associated resource. The content of an atom:id element MUST be created in a way that assures uniqueness.

Et il est conseillé d'utiliser le schéma tag: pour cela, ce que fait le flux de syndication de ce blog.

Pour plus d'informations, une page Web de l'auteur du RFC fait le point sur le schéma tag:.

Rénuméroter son réseau, par exemple, parce qu'on change de fournisseur d'accès, n'a jamais été drôle. C'est même souvent pénible, l'adresse IP du réseau se trouvant en général dans de nombreux endroits sur les machines. Sur Unix, un outil comme grep est une aide considérable pour retrouver ces endroits. Si on a la chance d'avoir des adresses PI (Provider Independant), on ne connaitra pas ls joies de la renumérotation. Sinon, il faudra lire ce RFC.

IPv6 rend théoriquement les choses plus faciles. Notamment parce qu'il permet, depuis le début, d'attribuer plusieurs adresses IP à la même interface (c'est en général possible également en IPv4 mais c'est moins bien géré, car cela été ajouté après).

Le RFC dresse une liste de tout ce qui peut avoir besoin de changer lors de cette opération. La liste est suffisamment longue pour qu'il n'y aie aucun espoir de tout réussir en une seule journée, le flag day.

Puis il décrit la procédure à suivre soigneusement, en n'oubliant rien et en étant conscient, comme le rappelle Clausewitz, cité par le RFC, que de toute façon quelque chose ira mal...

Une grande partie de cette procédure peut d'ailleurs également convenir pour IPv4. Souhaitons que ce RFC soit donc largement utilisé pour limiter les cafouillages qui se présentent souvent lors d'une telle opération.

Depuis que les noms de domaine en Unicode sont disponibles (IDN, décrits en RFC 3490), la question se pose d'enregistrer des domaines de premier niveau (TLD, Top Level Domain comme .org ou .ci) en Unicode. Le problème n'est pas technique (un TLD est un domaine comme un autre et peut être enregistré grâce aux IDN) mais politique.

L'ajout de nouveaux TLD est en effet contrôlé par le gouvernement des États-Unis, via une organiation écran, l'ICANN. Celle-ci s'oppose régulièrement au déploiement des IDN donc il y a peu de chance que des TLD en Unicode soient acceptés.

Le RFC propose donc une autre solution : traiter la représentation des TLD en Unicode uniquement comme une question de présentation à l'utilisateur. .org resterait ainsi en US-ASCII mais le logiciel pourrait afficher et accepter en entrée une traduction chinoise, en caractères chinois.

Il n'y aurait donc pas de changement du nombre de TLD.

L'idée semble raisonnable mais on peut regretter que, pour la défendre, l'auteur du RFC ignore d'autres solutions. Par exemple, la section 1.3.2 du RFC discute de certains mécanismes qui pourraient être utilisés pour s'assurer que le TLD en US-ASCII et le TLD en Unicode aient le même contenu. Il conclut que ces mécanismes ne sont pas suffisants (et donc qu'il vaut mieux avoir un seul TLD par pays) mais il oublie d'autrs possibilités techniques comme un simple lien symbolique entre les deux fichiers de zone (solution qui marche très bien avec les logiciels BIND et NSD).

Le multihoming, ou capacité pour un site Internet d'être relié à plusieurs fournisseurs d'accès Internet (FAI), est à la fois une très forte demande de la part des utilisateurs et un problème très complexe, qui n'a pas encore de solution satisfaisante. Le protocole IPv6 apporte quelques outils supplémentaires mais ne résout pas magiquement le problème.

Si tous les FAI étaient parfaitement fiables, et merveilleusement connectés, il n'y aura guère besoin de multihoming. Mais, en pratique, tout site qui veut une bonne fiabilité et une bonne connexion avec tout le monde a souvent intérêt à avoir plusieurs fournisseurs. La technique "normale" pour cela est d'avoir des adresses IP indépendantes (PI pour Provider Independant) et de faire du BGP avec tous ses fournisseurs. C'est techniquement assez complexe et c'est surtout très coûteux, sans compter la difficulté d'obtenir des adresses PI auprès des RIR (IPv6 ne change rien à ce sujet).

En attendant, le client de base reste donc très dépendant de son FAI.

Le groupe de travail Multi6 de l'IETF travaille sur la question et ce RFC explique son analyse des différentes architectures envisageables (le RFC 3582 détaillait le cahier des charges du multihoming IPv6). On est encore loin d'une solution.

Le RFC identifie cinq architectures possibles. Pour les comprendre, il faut d'abord lire la section 2 du RFC, qui rappelle que l'adresse IP est actuellement utilisée pour deux choses bien différentes, comme identificateur d'une machine et comme index dans les tables de routage (certaines solutions de multihoming vont séparer les deux fonctions) :

• Adresses PI et routage BGP, comme vu plus haut. Le problème est de passage à l'échelle : que deviendront les routeurs BGP si un million de sites publient leur route ? Le problème n'est pas celui du nombre d'adresses IP (qu'IPv6 résoud) mais celui du nombre de routes.
• Utilisation des techniques de mobilité : être connecté à un deuxième FAI n'est pas différent d'être en voyage et connecté par un FAI distinct de son FAI habituel.
• Les trois dernières architectures prévoient toutes une séparation des deux fonctions de l'adresse IP. Les sessions (par exemple TCP) seraient maintenus entre deux machines identifiées, non pas par une adresse IP, mais par un identifiant de plus haut niveau.

Le RFC décrit ensuite en détail les différentes façons de réaliser cette séparation et ces conséquences (il s'agit de remettre en cause un principe central des applications Internet).

Ce RFC spécifie un nouveau type d'enregistrement DNS, le SRV pour "service". Traditionnellement, les enregistrements contenus dans le DNS permettaient seulement de spécifier l'adresse IP correspondant à un nom comme www.bortzmeyer.org. Si on voulait avoir plusieurs machines mettant en œuvre un service, il fallait mettre plusieurs adresses dans le RRset, dans l'ensemble des enregistrements. Et, si on voulait en plus que certaines de ces adresses ne soient utilisés qu'en secours, si les premières ne répondent pas, ou si on voulait que certains adresses soient utilisés davantage que d'autres, parce qu'elles correspondent à des machines plus rapides, eh bien il n'y avait pas de solution. Plus exactement, il n'y en avait que pour le courrier, qui avait un type spécial, MX, ayant à peu près ces capacités. Mais les autres services, comme le Web, ne pouvaient pas en bénéficier.

Ce RFC introduit donc un nouvel enregistrement, SRV, qui est depuis longtemps disponible dans les serveurs de noms. Un enregistrement SRV permet d'obtenir, pour un service, non pas une adresse IP mais le nom d'un serveur physique, avec une priorité, qui permet de rendre obligatoire le passage par certaines machines d'abord, et un poids, qui permet de donner une plus grande probabilité d'usage pour certaines machines. La priorité est déterministe et absolue (si une machine de meilleure priorité est disponible, elle doit être utilisée), le poids est probabiliste (il vaut mieux essayer les serveurs de meilleur poids). L'enregistrement donne également le port à utiliser.

Le service se spécifie en le préfixant d'un trait souligné (_), caractère illégal dans les noms de machine, ce qui supprime le risque de collision. Par exemple, certains clients LDAP cherchent le serveur LDAP de leur domaine, non pas en essayant une convention comme ldap.MONDOMAINE.org mais en demandant le SRV de _ldap._tcp.MONDOMAINE.org. Une telle convention a également été proposée pour whois, afin de découvrir le serveur whois faisant autorité pour un domaine donné.

Un RRset, un ensemble d'enregistrements SRV pour le service Web de example.org pourrait donc être :

_http._tcp     SRV 0 1 80 old-slow-box.example.org.
               SRV 0 3 80 new-fast-box.example.org.
               SRV 1 0 80 personal-box.adsl.my-isp.net.

ici avec deux serveurs de même priorité (zéro), un rapide ayant un poids de 3 et un lent ayant un poids de 1, puis un serveur de secours (priorité 1). Tous écoutent sur le port 80.

Pour les développeurs, il existe déjà une bibliothèque qui met en œuvre le RFC 2782 : Ruli (pour Resolver User Layer Interface) qui simplifie considérablement la tâche du développeur. Si un si faible nombre d'applications utilise les enregistrements SRV, ce n'est donc pas faute de support logiciel.

Car, malheureusement, on constate que très peu d'applications acceptent d'utiliser les SRV. Je ne connais par exemple aucun navigateur Web qui le fasse, même pas Firefox, pour lequel la discussion a commencé il y a des années (idem pour Chrome). Pour des raisons qui m'échappent, une très belle idée, qui résoudrait de nombreux problèmes de gestion d'un parc de serveurs, reste ainsi, six ans après sa normalisation, quasiment inconnue.

À part XMPP, l'utilisation la plus courante aujourd'hui doit être dans le DNS Service Discovery du RFC 6763.

Un RFC très politique, que ce 1984 qui s'attaque aux restrictions d'usage à la cryptographie. Au moment où il est sorti, la cryptographie était de fait interdite en France (et la situation, si elle s'est améliorée, est encore loin d'être parfaite). Et les États-Unis restreignaient très sévèrement l'exportation de logiciels cryptographiques (là encore, ces restrictions n'ont pas complètement disparu).

Le RFC prend nettement position : l'IAB et l'IESG, ensemble, affirment que la cryptographie forte (pas les systèmes ultra-bridés qui étaient proposés à l'époque avec les navigateurs Web) est indispensable à la sécurité de l'Internet, qu'il n'existe aucune autre méthode réaliste d'assurer une sécurité raisonnable sur un réseau ayant l'architecture de l'Internet et que cette sécurité ne doit pas être sacrifiée aux intérêts des polices et des services secrets.

Le RFC se penche aussi sur des cas plus techniques, comme sur les clés cryptographiques ne servant qu'à la signature, qui ne devraient jamais faire l'objet d'un dépôt de séquestre, puisqu'il n'existe aucune raison légitime de les "saisir".

Ce RFC dont le numéro ne doit rien au hasard, a marqué une étape dans la construction politique de l'Internet.

Au jour d'aujourd'hui, ce livre représente un état de l'art du Web débarassé des scories de la "guerre des browsers", déclenchée par Netscape et qui avait abouti à un grande balkanisation du Web.

Un des effets de cette guerre avait été la prolifération d'éléments HTML non-standards, produisant des effets visuels supposés attirer les clients vers un navigateur particulier, comme le célèbre <BLINK>.

En même temps que cette guerre, et s'appuyant sur cette course aux effets visuels, le webmestre moyen, en général peu cultivé en informatique documentaire, avait pris l'habitude de ne plus séparer contenu et présentation (ce qui était pourtant un principe cardinal du Web) et de tout mélanger, structure et effets visuels. La version 3.2 de HTML était allé particulièrement loin en ce sens.

Aujourd'hui, on en est revenu, on comprend mieux l'intérêt de séparer le fond (utile par exemple aux moteurs de recherche) de la forme. Et les normes ont évolué, la version 2 de CSS ajoutant à CSS ce qui lui manquait : la possibilité de positionner des éléments sur la page. Même les sites très pro-CSS devaient utiliser des tables HTML dès qu'il fallait positionner, par exemple un menu à droite. Avec CSS 2, on peut enfin écrire une page HTML sans une seule indication de présentation, celle-ci étant concentrée dans la feuille de style CSS.

Il ne reste donc plus qu'à apprendre CSS 2. Si CSS 1 était assez simple, la version 2 oblige les webmestres à apprendre un peu d'informatique graphique et un livre n'est donc pas inutile. Celui-ci répond bien aux problèmes, il est très concret, ne couvre pas uniquement la norme mais aussi sa mise en œuvre dans les navigateurs, par exemple avec ses énormes bogues et limitations dans Microsoft Internet Explorer (CSS 2 est loin d'être correctement mis en œuvre partout).

Démarrant doucement, avec un exposé de CSS accessible aux débutants, le livre continue par un festival de trucs et de bricolages qui devraient satisfaire même les bons connaisseurs de CSS.

Le ton assez pontifiant du livre est souvent assez énervant, ainsi que la préciosité du langage mais les concepteurs de pages Web sont comme les informaticiens, ils manquent souvent de distance avec leur sujet.

Ce RFC normalise une pratique ancienne, l'attribution automatique d'adresses IP à des machines sur des réseaux "non-gérés". Il existe plein d'ordinateurs qui ne sont pas administrés par un professionnel et qui ont besoin d'adresses IP pour communiquer. C'est le problème connu à l'IETF sous le nom de "problème du bureau du dentiste" : le dentiste est riche, il a plusieurs ordinateurs, mais il n'est pas informaticien, il ne va pas configurer un serveur DHCP (RFC 2131) pour attribuer une adresse à ses ordinateurs.

IPv6 résout ce problème avec l'autoconfiguration sans état, RFC 4862, un mécanisme peer-to-peer, qui ne demande pas de serveur central (DHCP étant l'autoconfiguration avec état, il dépend d'un serveur central).

Depuis des années, une solution pour IPv4 existe dans Microsoft Windows mais n'était pas encore normalisée : c'est désormais chose faite avec ce RFC.

Selon notre RFC, lorsque une machine se retrouve connectée à un réseau, elle peut utiliser un algorithme normalisé pour obtenir une adresse dans la plage 169.254.0.0/16, qui avait été réservée dans le RFC 3330.

L'algorithme est simple dans son principe, même si le RFC a besoin de beaucoup de pages pour expliquer les détails : chaque machine choisit au hasard une adresse dans la plage et elle n'a ensuite qu'à tester pour voir si une autre machine ne l'utilise pas déjà.

Cette norme correspond à l'expansion des réseaux non-gérés, ceux du bureau du dentiste, bien sûr, mais aussi à tous ces réseaux d'appareils qui ne sont pas des ordinateurs mais ont déjà ou auront bientôt une adresse IP (lecteurs RFID, imprimantes, badgeuses, etc).

On note que ce RFC ne résout pas le problème des noms de ces machines, qui, à l'IETF, a été traité par le groupe de travail DNS extensions via Linklocal Multicast Name Resolution (LLMNR) (RFC 4795).

[Avertissement : c'est le premier livre de la série "Pragmatic" que je lis. Cette série tente apparemment de faire l'intermédiaire entre O'Reilly et "XXX pour les nuls".]

Un bon livre pour deux sortes de public, ceux qui ne connaissent pas les systèmes de contrôle de versions (ou qui connaissent uniquement des systèmes très archaïques comme RCS ou ClearCase) et ceux qui font du CVS depuis dix ans et passent à Subversion.

Mise en page très agréable, bons dessins, la présentation vaut les O'Reilly.

Les explications sont correctes et détaillés. Une fois qu'on a accepté que tous les exemples soient avec des sources Java, tout se passe bien :-)

Le titre de pragmatic est assez mérité, il y a peu de discussions (par exemple les systèmes de contrôle de versions décentralisés sont à peine mentionnés), pour pouvoir passer aux tâches concrètes tout de suite.

Alors que j'utilisai déjà beaucoup Subversion, j'ai encore appris des commandes dans ce livre ("svn praise" qui affiche un fichier avec le nom du committeur de la ligne en face de chaque ligne) et des options ("svn status -u" qui vérifie le statut avec le serveur, pas uniquement en local).

Regret principal : dans une série qui se veut concrète, l'auteur n'a pas pensé à séparer clairement l'utilisation de Subversion de son administration (notamment dans les chapitres 7 et 8 sur l'organisation du dépôt). Or, il y a beaucoup plus d'utilisateurs que d'administrateurs et un livre où les chapitres Administration seraient regroupés en un endroit clairement marqué serait sans doute préférable pour les utilisateurs ordinaires.

Autrefois, tout était simple, il n'y avait qu'un seul type d'accès Internet : l'accès complet. Aujourd'hui, les offres sont bien plus éclatées : il y a la traduction d'adresse (NAT), le filtrage (plusieurs FAI bloquent le port 25 - celui du courrier - en sortie, pour gêner les vers Windows qui tentent d'émettre du spam), les passages obligatoires par des relais plus ou moins transparents.

Très peu de fournisseurs documentent ces restrictions.

Rien de plus agaçant que d'avoir payé l'hôtel pour avoir "une connexion Internet" avant de découvrir qu'elle ne donne pas accès au port 22 et qu'on ne peut donc pas faire du SSH vers ses serveurs lorsqu'on est en déplacement.

Une des raisons au manque de documentation est l'absence d'un vocabulaire commun pour décrire ces offres. Le marché ne peut fonctionner qu'en présence d'information et il n'y a pas d'information sans la standardisation des termes.

C'est ce à quoi s'attaque le RFC 4084. Tâche difficile car, selon les mots de l'auteur, "il faut éviter d'utiliser un vocabulaire péjoratif". Il est en effet essentiel que ce vocabulaire soit utilisé par les fournisseurs d'accès. L'IETF n'a aucune autorité pour forcer l'usage de ces termes et ils doivent donc plaire à tous, clients et fournisseurs. D'autre part, il faut parler en termes de services pour l'utilisateur et évidemment pas en termes techniques, pour être compréhensible par le client.

Le RFC distingue donc notamment : "Connectivité Web", qui ne donne accès qu'à ce service, ce qui est le cas de beaucoup de points chauds WiFi, "Client seulement" (qui interdit la plupart des services "peer to peer" comme la téléphonie Skype ou comme BitTorrent), "Connectivité Internet filtrée" et "Connectivité Internet complète".

Peut-être verra t-on un jour une loi sur la protection des consommateurs obliger à décrire une offre de connexion Internet avec les termes du RFC 4084 :-)

On se souvient que Microsoft avait annoncé officiellement que la compagnie n'entendait pas gérer les noms de domaine internationaux (IDN) dans son navigateur Internet Explorer tant qu'il n'était pas possible d'internationaliser tout l'URL.

En effet, si IDN (RFC 3490) permet d'écrire http://www.académie-française.fr/seances, il ne permet pas de gérer http://www.académie-française.fr/séances. Les IRI, que normalisent le RFC 3987, permettent cela et, si Microsoft tient parole, devraient permettre au dernier navigateur Web sans support IDN de rejoindre ses concurrents.

Les IRI fonctionnent en complément des IDN. Dans l'IRI http://www.académie-française.fr/séances, le nom de machine est géré par IDN et apparaitra donc comme www.xn--acadmie-franaise-npb1a.fr lors des échanges entre logiciels. En revanche, la partie droite de l'IRI, /séances, restera parfois en Unicode. Elle n'est interprétée que par le serveur final et n'a pas forcément à subir les règles très restrictives qui affectent les noms de machines.

La nécessité de traduire l'IRI (en Unicode) en URI (en US-ASCII) dépendra du schéma de l'IRI (le schéma est indiqué par le premier terme, avant le deux-points). Certains schémas existants comme "http" n'acceptent pas forcément l'Unicode et il faudra alors que le logiciel traduise l'IRI en URI, selon un mécanisme analogue à celui des IDN, en utilisant le traditionnel encodage en %. Les schémas les plus récents et les futurs schémas pourront éviter cette étape.

Naturellement, il faudra mettre à jour navigateurs et serveurs, mais les navigateurs gèrent déjà tous Unicode pour l'affichage et cela ne devrait pas être trop difficile pour eux.

Malgré les inquiétudes habituelles de ceux qui verraient bien l'Internet rester exclusivement en anglais, les IRI marquent donc une nouvelle étape vers une internationalisation réelle.

Un bon article sur le sujet est An Introduction to Multilingual Web Addresses.

Le RFC, 3981, décrit le protocole IRIS, Internet Registry Information Service, qui va tenter de remplacer le protocole whois.

Les limites du protocole whois d'accès à l'information sociale du registre sont connues depuis longtemps (et citées dans le cahier des charges du groupe de travail CRISP, le RFC 3707). Citons notamment :

• aucun mécanisme d'authentification (donc pas possible de donner des réponses différentes selon le client),
• pas de structuration des données (donc nécessité d'analyser une sortie texte en essayant plus ou moins de deviner, tâche pour laquelle Gandi avait développé un script Perl de 6000 lignes),
• pas de mécanisme standard de redirection, permettant par exemple de faire des requêtes hiérarchiques (cas des registres minces, ou bien cas d'allocation en cascade comme avec les adresses IP ou encore cas d'un prestataire ayant sa propre base, avec davantage de détails, comme le fait EuroDNS).

IRIS va tenter de résoudre ces limites. Il est bâti sur le langage XML, et le mécanisme des W3C Schema. Le RFC 3982 décrit le premier schéma, "dreg", conçu pour les registres de noms de domaine, un autre schéma, "areg", pour les RIR, étant en préparation. Notons donc qu'un registre de nom de domaines pourrait utiliser le protocole IRIS (RFC 3981) avec un autre schéma que dreg (RFC 3982), par exemple si son modèle de données est très différent du consensus de Marina de Rey.

Le RFC 3981 n'est pas évident à lire et le lecteur pressé peut se contenter du RFC 3707, puis de l'appendice B du RFC 3981, "IRIS Design Philosophy". Le RFC 3982 est tout aussi trappu mais c'est une tentative de formaliser le modèle de données d'un registre de noms de domaines et c'est donc un document important.

IRIS, par ses nouvelles possibilités, pose plein de questions politiques ou sociales. Par exemple, par son mécanisme d'authentification, il permet des réponses différenciées, peut-être verra t-on des registres faire payer pour avoir accès à plus de renseignements. D'autre part, en faisant sauter une limite technique aux redirections, IRIS encouragera peut-être le déploiement de serveurs IRIS privés, en plus de ceux des TLD ou des RIR.

La question du déploiement effectif d'IRIS est ouverte. Il faut rappeler que IRIS n'est pas le premier protocole à tenter d'éjecter whois : rwhois, whois++ et LDAP avaient déjà essayé. whois, simple et bien connu, a toujours résisté. Verisign a déjà créé deux mises en œuvre libres d'IRIS, je n'en connais pas encore d'autres : le choix des W3C Schema rend de toute façon très complexe la mise en œuvre d'IRIS. Le RIPE-NCC dispose d'un serveur IRIS pilote.

(Depuis, IRIS n'a eu aucun succès et, en mars 2015, un autre candidat à la succession de whois est apparu, RDAP.)