Stéphane Bortzmeyer a écrit 655 commentaires

LLMNR n'est pas un produit Microsoft (je ne crois pas que MS en ait une implémentation), mais IETF (décrit dans le RFC 4795).

Moins diplomatiquement, le projet Dot-P2P était du vaporware dès le début, n'a jamais rien fait et rien produit, comme 99,9 % des projets médiatiques lancés par une vedette (Peter Sunde) et commentés sur Slashdot.

La quasi-totalité des projets de "DNS pair-à-pair" sont dans ce cas. Utiles pour les discussions de bistrot mais cela ne va pas plus loin.

Rien à voir. HTTP est normalisé par l'IETF (RFC 2616). Bonjour est 100 % contrôlé par Apple qui peut faire évoluer le protocole (et donc casser les autres implémentations) comme ils veulent.

Apple Bonjour, comem son concurrent normalisé LLMNR sont strictement locaux. Faire la même chose au niveau de l'Internet est un défi colossal (et c'est probablement impossible, au sens où résoudre la quadrature du cercle est impossible).

Si vous arrivez à concevoir un protocole qui fait la même chose qu'Apple Bonjour ou LLMNR à l'échelle de l'Internet (très grand, pas organisé et plein de méchants), c'est le prix Nobel assuré.

Utiliser une technologie privée spécifique d'Apple (Bonjour), je ne vois pas où est le progrès. C'est amusant de voir sur linuxfr des gens qui glapiraient d'horreur si on leur demandait d'utiliser le format MS-Word mais qui adoptent les protocoles privés d'Apple sans hésitation.

Franchement, je ne vois pas le rapport avec la neutralité, la privatisation, la marchandisation... .COM continuera comme avant, .ORG aussi et .42 également. On verra apparaître des .HEINEKEN et des .TF1 et alors ? Des biens grands mots pour un évenement qui concerne surtout les avocats et les domaineurs.

Il y a des menaces bien plus graves contre l'Internet que les amusements de l'ICANN (LOPPSI, HADOPI, Internet par Orange, décret censure, etc).

Oui, c'est le même Riguidel. Ce qui indique clairement que l'HADOPI n'estime pas important d'avoir une légitimité technique.

Non, d'autres hébergeurs de machines dédiées ont déjà IPv6, notamment OVH.

Je pense que Nonolapero parlait uniquement des hébergeurs de machines dédiées, ce dont Nerim et FDN ne font pas partie.

Notez que l'affirmation comme quoi .42 n'est pas conforme aux RFC est fausse (ou alors, il faudrait me citer le paragraphe exact dudit RFC).

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.