Stéphane Bortzmeyer a écrit 664 commentaires

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

le probleme d'introduire des autres caractères que l'ascii (tu as vu je me suis bien restreint) se produit dans le cas qu'un caractère ressemble à un autre

Et, dans ce cas, pourquoi favoriser systématiquement l'alphabet latin ? Et cet argument ne joue certainement pas pour le chinois, où le risque de confondre avec les lettres latines est faible :-)

Je sais que les anti-IDN font feu de tout bois mais cet argument-là me semble particulièrement faible.

Si deux caractères sont très ressemblants => risque de pishing ou autre.

Non, ça, c'est du baratin . Politiquement, c'est du même niveau que « si les internautes ont la liberté de s'echanger des fichiers, il n'y aura plus de création artistique » Pratiquement, je reçois beaucoup de rapport de hameçonnage au bureau et il est exceptionnel qu'il y aie un effort de vraisemblance dans l'URL. Si la cible est, mettons, la Banque Générale, on voit parfois banquegeneral-secure.com ou un truc équivalent (qui n'a pas besoin d'homographie). Mais, la plupart du temps, c'est untel.free.fr, voire une simple adresse IP. Comme personne ne vérifie l'URL, il n'a pas besoin d'être vraisemblable.

Prétendre que les IDN permettraient d'avantage de hameçonnage est donc un argument purement politicien, mis en avant par les gens qui refusent l'internationalisation de l'Internet.

On notera que cet argument n'apparait pas dans la charte du groupe de travail IETF sur IDNA v2 http://www.ietf.org/html.charters/idnabis-charter.html alors qu'il était dans les versions initiales.

.local
.dom

Ils sont peut-être courants mais très dangereux à utiliser. Ils n'ont jamais été normalisés et peuvent donc demain être délégués à un vrai TLD.

RFC 2606 <http://www.bortzmeyer.org/2606.html>

Seul .example est réservé et sûr. Mais pas prévu pour cet usage. Pourquoi ne pas utiliser un vrai domaine ?

Par contre, je m'inquiète bien plus de l'arrivée des alphabets non latin, et/ou des accents dans les noms de domaines...

Il est vrai qu'il est inquiétant que les russes veulent utiliser l'alphabet cyrillique et les iraniens l'alphabet arabe. Que font Chuck Norris et SuperDupont ?

Blague à part, si l'Internet avait été inventé en Chine, que diriez-vous de devoir taper toutes les adresses avec un bout en chinois à droite. Avec des chinois qui vous expliquent doctement que ce n'est pas si difficile que cela et que c'est dans l'intérêt de la sécurité et de la stabilité ?

Je trouve étonnant que sur un forum de logiciel libre, on lise des réactions aussi primaires contre l'internationalisation, alors que Microsoft fait des efforts pour adapter tous ses logiciels.

par exemple avec une annulation immédiate du domaine en cas de squattage manifeste

C'est sur linuxfr qu'on lit ça ? Eh bien, il ne reste plus qu'à voter un soutien enthousiaste à la loi Hadopi <http://fr.wikipedia.org/wiki/Loi_Hadopi>. « Riposte graduée » au cybersquattage ?

Au fait, jeboycottedanone.com, c'était du cybersquattage ? Pour les avocats de Danone, oui.

C'est curieux qu'il faille apprendre aux lecteurs de linuxfr qu'on ne doit pas faire confiance à ce qui est écrit par des journalistes sur du papier. Seule l'information publiée sur Internet est correcte et à jour et l'ICANN a vite démenti cet interview :

http://www.mailclub.info/article.php3?id_article=807

Un peu de bon sens aurait suffi à détecter la traduction ultra-approximative (Paul Twomey ne parle pas français). Certes, l'ICANN est une organisation assez secrète où les vraies décisions sont prises en petit comité et annoncées par suprise mais, là, quand même, l'ICANN qui a toujours été ultra-fidèle au patronat et aux détenteurs de propriété intellectuelle, qui ouvrirait les vannes tout grand à la liberté ? C'était difficilement croyable.

the root server will fit as much as it can within a 512-byte packet and mark the answer as "truncated,"

Ce n'est pas vraiment exact (sauf à utiliser le mot troncation dans un sens très général, alors qu'il a une signification bien précise pour le DNS).

Comme la taille de la section Réponse ou Autorité ne va pas changer (il n'y a toujours que treize serveurs), il n'y aura pas de troncation. Il y aura simplement sélection des enregistrements dans la section Addition, et cette section n'est pas obligatoire.

Donc, le risque n'était pas la troncation, mais le fait que la sélection des colles (les adresses IP des serveurs) pourrait ne laisser que des adresses IPv4 ou bien que des adresses IPv4, ce qui serait ennuyeux pour le client mono-protocole.

Avec EDNS0, le problème disparait.

Le rapport complet du SSAC pour ceux qui ont le courage : http://www.icann.org/committees/security/sac018.pdf