Stéphane Bortzmeyer a écrit 645 commentaires

Plusieurs commentateurs ont déjà noté que cet article était très faible, question faits, et notamment que l'affirmation comme quoi les treize serveurs racine du DNS utilisaient OpenBSD était fausse. Cela vaut la peine de préciser en quoi elle était fausse. Les treize serveurs sont gérés par des équipes complètement différentes. Personne n'a d'autorité sur les treize et ne pourrait leur imposer un système particulier.

Donc, les treize serveurs utilisent des systèmes d'exploitation différents et des serveurs DNS différents. Heureusement, pour la fiabilité de l'Internet. Sinon, une seule bogue dans un logiciel particulier pourrait les faire tomber en même temps !

Hmmm, le projet, si on le résume à trois lignes (réseau construit par la base, décentralisé, etc), est politiquement tentant, et j'apprécie les gens qui tentent des choses audacieuses.

Mais, bon, à lire les articles techniques, ça fait encore pas mal « projet d'étudiant qui vient de découvrir les DHT et croit qu'il va résoudre tous les problèmes avec ». Je crains fort qu'il ne s'agisse d'un projet Powerpoint (grandes déclarations et pas de code qui tourne).

Donc, les points qui me dérangent :

Politiquement, c'est assez naïf que de croire que des problèmes comme la censure se régleront par un changement de techniques. Un régime qui filtre son Internet national (comme la Chine) en fera autant avec n'importe quel autre réseau.

Techniquement, rien n'indique que les auteurs comprennent le mot "scalability" (désolé, pas de bonne traduction en français). Par exemple, ils n'ont fait ni calcul formel, ni simulation, ni déploiement effectif pour voir si leurs techniques passaient à l'échelle. Ce n'est pas parce qu'un truc fonctionne entre trois PC dans un garage qu'il fonctionnera avec trois ou quatre milliards de machines. La première chose à demander à des gens qui veulent construire un réseau mondial, c'est « Avez-vous au moins fait tourner vos algorithmes in silico avec 10 000 machines ? »

Le protocole de résolution de noms, ANDNA, n'offre aucune sécurité. Certes, les enregistrements sont signés. Mais comme il n'existe aucun moyen de vérifier une clé publique, il s'agit d'une « auto-signature », sans aucune valeur. Ce protocole est donc en retard sur l'état de l'art en matière de DHT comme, par exemple, CoDoNS, qui traite ce problème. D'une manière générale, d'ailleurs, les auteurs d'ANDNA semblent, soit ignorants, soit méprisants du travail des autres : ils ne citent pas une seule fois les nombreux protocoles qui ont essayé, plus sérieusement, de résoudre ce genre de problème (comme HIP).

Les textes contiennent des énormités comme « The registration of a domain upon these servers is a privilege provided by InterNIC, a United States controlled company, who
grants the right to sell single domain names to end users. » affirmation qui n'a jamais été vraie et qui l'est encore moins aujourd'hui. Mais la plus énorme est « Unfortunately, all
of these protocols [BGP, OSPF] must consume massive amounts of computational resources
to function on a network of the scale of the Internet, and must exist on special
dedicated machines. So great are the physical requirements of these unique (usu-
ally even purpose-built) machines, ». Ils n'ont jamais entendu parler de Quagga ou de BIRD (qui tournent BGP sur un bête PC/Linux) et ils veulent faire du routage au niveau mondial ! (La table de routage BGP actuelle fait dans les 300 000 routes, un chiffre peu impressionnant pour les ordinateurs d'aujourd'hui.)

Et si on convainquait Liliane Bettencourt de donner tout son argent à la Fondation Abbé Pierre, il n'y aurait plus de mal logés.

Je suis sérieux : comment allez-vous faire pour convaincre ces grosses boîtes ? Les menacer des avocats de l'IANA ?

Et sur Linux, ça se change facilement http://www.bortzmeyer.org/4941.html

Euh, j'écris des adresses IPv4 et IPv6 dans un SGBD PostgreSQL avec C. J'ai rêvé, peut-être.

Et C a son type « adresse IP » (indépendante de la famille) depuis le siècle dernier, struct sockaddr.

Pour la question des applications qui stockeraient une adresse IP uniquement comme adresse IPv4, signalons qu'ils existent plusieurs plate-formes qui ont un type « adresse IP » générique. Par exemple, parmi les bases de données sur Linux, PostgreSQL a un type INET http://www.postgresql.org/docs/8.4/interactive/datatype-net-(...) qui stocke de l'IPv4 et de l'IPv6. Évidemment, si on s'obstine à utiliser un SGBD... léger, il ne faut pas se plaindre que cela ne marche pas.

6rd (normalisé dans le RFC 5569) n'est qu'une technique parmi d'autres. Elle convenait bien à Free dont le réseau interne était purement v4. Mais, pour la plupart des sites et des opérateurs, il vaut sans doute mieux passer directement à de l'IPv6 natif, comme l'ont fait les deux premiers FAI français qui ont offert de l'IPv6 à leurs clients (Nerim et Renater).

Il y en a pleins qui parlent d'un web minitel, mais si les outils de basent sont destinés à être utilisés par des équipes de professionnels (alors que franchement, pas besoin d'être pro pour un serveur de nom), la situation ne risque pas d'évoluer.

Aucun problème si quelqu'un veut développer un outil ultra-simple à utiliser. Allez-y. C'est le Yakafokon que je n'aime pas.

Le problème est compliqué. Crier « Je veux un outil utilisable même par mon chef » ne va pas le simplifier miraculeusement.

Autrement, je suis d'accord avec la réponse de Julien.

Ça devient vraiment compliqué.

C'est conçu pour les grosses zones sérieuses, gérées par une équipe de professionnels, ce n'est pas pour mondomainamoi.fr.

Il n'existe pas un projet qui consiste à rendre la configuration simple et efficace ?

Il existe plusieurs logiciels non-libres qui ont cette prétention.

j'en déduis qu'il y a un serveur DNS

Non

ça doit être en ligne de commandes et fichiers de conf'

Oui (ce qui est une bonne idée pour un outil automatique).

quelqu'un ici pourrait il nous expliquer ce qu'apporte OpenDNSSEC par rapport à l'implémentation BIND de base ?

BIND peut signer une zone, signer des mises à jour dynamiques et
resigner automatiquement (depuis la 9.7, si ne me trompe).

Mais, en matière de gestions des clés, c'est à peu près rien : il peut
génerer des clés, c'est tout.

Or, les clés DNSSEC, pour divers raisons, doivent être remplacées
régulièrement (non, en fait, ce n'est pas réellement obligatoire mais
c'est conseillé). Ce remplacement doit se faire avec précaution, pour
ne pas laisser la zone dans un état non-validable. Il faut notamment
tenir compte du TTL (durée de vie des enregistrements). Un exemple
typique : si on commence à signer avec une nouvelle clé, il ne faut
pas arrêter de distribuer l'ancienne clé car elle reste
indispensable pour valider les anciennes signatures, qui peuvent être
toujours dans les caches.

OpenDNSSEC gère donc cela : il crée automatiquement des clés lorsque
c'est nécessaire (selon la politique qu'on a définie, il passe
automatiquement les clés dans un état dans un autre en tenant compte
des TTL, etc. [http://www.bortzmeyer.org/opendnssec-states.html].

Il intervient donc en complément du serveur de noms (nsd ou BIND).

Le point d'échange Internet, situé sur la colline de Boutillier, fonctionne toujours et vient d'être ravitaillé en carburant, le point le plus critique : cf. le témoignage de son responsable en [http://mailman.nanog.org/pipermail/nanog/2010-January/017274(...)]

Une réflexion intelligente de Bill Woodcock, un des coordinateurs de l'aide au fonctionnement du réseau, en [http://mailman.nanog.org/pipermail/nanog/2010-January/017326(...)].

Je pense que les haïtiens ont assez d'urgences à traiter sur le terrain sans s'occuper de celle-là qui pouvait être traitée depuis l'extérieur. Oui, c'est le point le plus important : même si on pouvait appeler à volonté les administrateurs du .HT (on ne le peut pas), je ne pense pas que cela aurait été une bonne idée que de les harceler avec ce genre de décisions quand ils ont tant à faire.

Comme souvent avec les crises humanitaires, c'est dans deux mois, quand l'intérêt médiatique aura disparu et que les donneurs ne se manifesteront plus, que commencera le travail le plus difficile : la reconstruction (et, dans le cas du .HT, le retour de ce domaine dans le pays). C'est là qu'il faudra être vigilant, pas lors des réactions d'urgence (où on fait ce qu'on peut avec des informations incomplètes).

La question est franchement idiote. Les gens qui ont travaillé à permettre le fonctionnement du DNS ne seraient pas allés sur place « sauver des vies ». Ils n'auraient d'ailleurs pas pu, vues les extrêmes difficultés de transport. Et ça n'aurait certainement pas été une bonne idée, Haïti a besoin de spécialistes en déblaiement et de médecins, pas d'informaticiens (rappelez-vous que, lors d'une catastrophe, chaque personne qui vient « aider » coûte : il faut la loger, la transporter et la nourrir. Il ne faut donc faire venir que des gens très experts, qui apportent une aide significative, et surtout pas des amateurs, même pleins de bonne volonté.)

À Port-au-Prince, le journaliste Carel Perdre informe toute la planète, notamment via son flux Twitter. Faudrait-il qu'il déblaie les débris, plutôt ? Non, il est journaliste, il fait le travail pour lequel il est expert, c'est ça qui est utile. Même chose pour les gérants de serveurs DNS.

La question aurait été moins idiote s'il y avait eu à faire un arbitrage, un choix entre partir déblayer et rester à reconfigurer des DNS. Mais ce choix n'existe pas.

Il n'y a pas de vrai support DNSSEC dans la glibc 2.11. Le patch est un changement très préliminaire, qui permet juste de demander au résolveur les enregistrements DNSSEC, pas de les traiter. Pas moyen, donc, pour une application, de valider avec DNSSEC.

Des éléments de réponse à cette question :

http://www.bortzmeyer.org/pourquoi-idn-et-pas-un-dns-unicode(...)

http://www.bortzmeyer.org/idn-racine.html

Bien sûr que si, les IDN sont officiels depuis 2003. Le RFC 3490, qui les normalise, a été publié à cette date. Quand aux politiques des registres de noms de domaine, heureusement que ce n'est pas l'ICANN qui décide ce qu'on a le droit de mettre dans ".cn" ou ".de".

Donc, pas grand'chose de nouveau sous le soleil, surtout de l'esbrouffe ICANN.

Donc, article peu sérieux, de la part du Monde, cela ne m'étonne pas, mais pour linuxfr, c'est triste.

http://www.bortzmeyer.org/linux-driver-project-status.html

il n'est pour l'instant toujours pas conseillé pour le grand public

C'est même plus que cela. Actuellement, je ne trouve pas que le Freerunner soit même utilisable par des utilisateurs avancés. Il faut avoir beaucoup de temps libre et être patient. C'est aujourd'hui de la qualité alpha, pas beta !

Si on n'est pas développeur, l'intérêt me semble limité. http://www.bortzmeyer.org/premiers-jours-avec-freerunner.htm(...)

J'ai hélas l'impression que X tend vers +OO

En effet, la grande majorité des codes de vérification d'adresse de courrier qu'on voit trainer sur le réseau sont faux http://www.bortzmeyer.org/arreter-d-interdire-des-adresses-l(...)

chaque membre est du type [0-9a-z][0-9a-z-]{0,63}

Ah non, justement, avec les IDN et les EAI http://www.bortzmeyer.org/4952.html cette règle n'est plus vraie.

(la rfc interdit normalement le chiffre en début de membre

Faux. (Ou alors il faut citer le paragraphe exact du RFC. Moi, je peux, RFC 1123, section 2.1 « the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax. »

Oui tiens, cela ne va-t-il pas imposer une qualification complète des noms de machines internes ?

En supposant que les TLD arrivent rapidement à être chargés, que va-t-on devoir nommer notre imprimante "imprimante.mondomainepublic.tld" plutôt que "imprimante" ?

Ou alors les résolveurs DNS seront moins triviaux...

Là aussi, c'est assez surprenant. En quoi l'ajout de ".bzh", ".paris" ou ".nimportequoi" pourrait changer le nommage interne et les résolveurs ???

Un root.hint plus gros sur les serveurs des ISP et des gros hebergeurs.

Drôle d'idée, le fichier "hints" ne contient pas la liste des TLD, seulement celle des serveurs de la racine. Vous pouvez expliquer ?

Le terme "extension de domaine" est-il officiellement accepté ?

Non, c'est du n'importe quoi de journaliste. Personne ne l'utilise en effet. Le terme correct serait « domaine de premier niveau ».

http://fr.wikipedia.org/wiki/Domaine_de_premier_niveau

а et a c'est pas pareil... le premier est cyrillique.

Et pourquoi, si on décidait de n'en autoriser qu'un, n'accepter que le latin ?

C'est rigolo, lorsqu'on discute des IDN, les gens qui trouvent qu'on pourrait bien se contenter de l'alphabet latin sont toujours des gens dont la langue maternelle s'écrit avec cet alphabet.

http://www.trigeminal.com/samples/provincial.html