Stéphane Bortzmeyer a écrit 645 commentaires

Sans compter le fait que tous les gens raisonnables ignorent (et à juste titre), la majorité des trolls de ce paranoïaque ?

Je ne dirai pas que cette conférence est sans intérêt :-) mais son but principal n'est pas de répondre à l'excellente question « quel est l'intérêt d'IPv6 pour la mamie du Cantal ? ».

Le terme de 6to4 est incorrect pour désigner le truc de Free (6rd). http://www.bortzmeyer.org/5969.html

DaveNull écrit

qui ne dépendent que d'un seul organisme, privé, américain : l'ICANN 

L'ICANN n'a joué aucun rôle dans le cas de Megaupload. L'ICANN sert surtout à faire des réunions, le travail opérationnel se partage entre le gouvernement états-unien et Verisign. C'est Verisign qui a redirigé le domaine megaupload.com.

Pour un résumé technique http://seenthis.net/messages/53427

(via le fichier /etc/resolv.conf il me semble).

C'est nettement plus complexe http://www.bortzmeyer.org/changer-dns.html

La décentralisation de la résolution des noms de domaines est-elle possible/réalisable/efficace contre la censure ?

Dans le cas de Megaupload, cela n'aurait rien changé puisqu'il y a eu aussi saisie des serveurs.

Quant aux projets de DNS en pair-à-pair, c'est une vieille lune http://www.bortzmeyer.org/dns-p2p.html

.fr est ouvert aux personnes physiques, depuis 2006. Il est ouvert aux européens depuis 2011.

Le fait d'avoir des noms parlants et mémorisables n'est qu'une partie des motivations au DNS, et pas la plus importante. L'essentiel est que le DNS fournit de la stabilité. linuxfr.org est aujourd'hui en 88.191.250.176 (incroyablement, il n'a toujours pas d'adresse IPv6). Demain, si linuxfr.org change d'hébergement et quitte sa Dedibox, c'est grâce au DNS qu'on pourra continuer à y accéder. http://www.bortzmeyer.org/pourquoi-le-dns.html

Ceci dit, il est vrai que beaucoup de gens dépendent de Google pour tout et ne peuvent plus rien faire sans lui. http://www.bortzmeyer.org/maintenant-j-ai-plus-google.html

Si, vous vous trompez. http://www.bortzmeyer.org/pakistan-pirate-youtube.html

Ben justement, ce n'est pas du tout sécurisé et c'est pour cela qu'il y a régulièrement des problèmes. Jusqu'à présent, ce n'est pas trop grave puisqu'il y a relativement peu d'opérateurs et qu'ils se connaissent. Ça se règle entre soi. Mais il y a bien plus de domaines (et d'acteurs) que de routes. http://www.bortzmeyer.org/securite-bgp-et-reaction-rapide.html http://www.bortzmeyer.org/alarmes-as.html

OpenRoot est du pur blabla, fait par des gens qui ne comprennent rien au DNS. Cf. http://owni.fr/2012/01/13/les-nouvelles-root-de-l%E2%80%99internet/ C'est un problème courant avec les racines alternatives http://www.bortzmeyer.org/racines-alternatives.html

Je ferais plus court la prochaine fois :-)

Je ne suis pas tellement d'accord avec le résumé. Le coeur de mon article était justement que « bon système de nommage » n'était pas un concept bien défini. Ce n'est pas la réalisation qui est compliquée, c'est le cahier des charges.

Très bien, la minute de silence. Mais le commentaire à la syntaxe C++ détonne un peu...

http://www.icann.org/en/news/releases/release-14oct11-en.pdf

Question quantité d'avocats, l'ICANN peut tenir tête aux astrologues à copyright.

Je ne sais pas si je suis « intéressant et compétent » mais l'article a été publié sur mon blog d'abord... et n'a eu que peu d'impact (ah, ah). PC Inpact l'a ensuite repris (après m'avoir demandé la permission, ce qui n'était pas formellement nécessaire, mon blog étant sous GFDL, mais c'est sympa) et cela fait tout de suite bien plus de lecteurs.

Moi oui, j'ai besoin de résoudre des noms un peu partout.

Les 100 noms de domaine par jour est un chiffre ridiculement bas. Un utilisateur normal en utilise davantage par heure. Utilisez tcpdump si vous ne me croyez pas. Même en virant les noms des services de pub, Google Analytics, etc, on dépasse les 100 très vite dès qu'on suit quelques liens sur linuxfr.

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