Stéphane Bortzmeyer a écrit 655 commentaires

Bon, qui parmi les lecteurs de LinuxFr est sur Twister, qu'on puisse essayer ensemble ? Moi, c'est "bortzmeyer" sur Twister.

Mon compte-rendu d'expérience : http://www.bortzmeyer.org/twister.html

Oui, j'ai en effet l'impression que c'est pas mal endormi. Mais, bon, pour les serveurs faisant autorité, entre BIND, NSD et Knot, on a déjà un bon choix.

La comparaison avec IRC est tout à fait injuste. D'abord, ce n'est pas la même sémantique (IRC : chaque membre du canal écrit à tous les membres du canal, Twister : chacun écrit à ses suiveurs). Ensuite, IRC est centralisé. Le serveur sait tout (qui communique, depuis quelle adresse IP) et décide tout (de supprimer ton compte, par exemple). Enfin, le cahier des charges en terme de sécurité n'est pas le même (IRC diffuse ton adresse IP à tous les membres du canal).

IRC est cool mais vaut absolument zéro, question vie privée !

Namecoin n'a absolument rien à voir avec le DNS (à moins qu'on baptise tous les protocoles de nommage « DNS »).

Outre l'argument « petite machine qu'on veut économiser », il y a un argument de sécurité/résilience : les attaques par déni de service étant fréquentes, il faut de la marge. Les serveurs racine ou des TLD ont typiquement une marge de 20 à 40 (pouvoir encaisser 20 à 40 fois le trafic habituel).

La supervision est l'ensemble des mécanismes qui teste régulièrement l'état d'un système ou réseau et alerte s'il y a un problème. Par exemple, si on a deux serveurs DNS pour une zone (le minimum recommandé), la panne d'un des deux serveurs n'est pas visible par les utilisateurs, en raison de la redondance du DNS. La supervision permettra à l'admin' système de se dire « ah, il faut réparer ns2.example.com, BIND a encore crashé »

Un adjudant est autoritaire mais un serveur DNS fait autorité.

"Zone BIND" n'a pas de sens. Le format des fichiers de zone n'a rien à voir avec BIND, il est normalisé dans le RFC 1035.

Aussi bien NSD que BIND et Knot ont une configuration très simple dans ce cas, en quatre ou cinq lignes (l'exemple Knot donné dans mon article est complet et marche).

C'est plutôt la supervision qu'il faut soigner.

Mettre quelque chose sur LinuxFr procure un bon référencement ? Ça m'intéresse, alors :-)

Il y a plusieurs solutions. Dans des cas similaires précédents (l'opération Tulipe Noire, par exemple), Google avait utilisé OCSP http://www.bortzmeyer.org/6960.html Il y a aussi des règles spéciales dans Chrome pour prévenir Google en cas de certificats suspects de la maison mère (si l'utilisateur a Chrome). Enfin, il y a la possibilité d'un utilisateur qui détecte le loup (il suffit d'une courte bogue dans le logiciel d'interception qui laisse échapper un message d'erreur non-Googlien), copie le certificat, et l'envoie à Google.

http://www.ietf.org/mail-archive/web/perpass/current/msg01162.html

Je ne comprends pas la remarque sur "une seule IP derrière une URL". C'est clairement faux. (Il y en a trois derrière http://www.bortzmeyer.org/)

Pourquoi gâchée ? Ce n'était pas dans le cahier des charges, c'est tout. Aujourd'hui, ça y est. Participez à perpass plutôt que de regretter le passé :-)

Déjà, c'est mal de dire « cryptage » http://www.bortzmeyer.org/cryptage-n-existe-pas.html

Si, mais cela ne marche pas si on veut TLS et d'autres protocoles (en l'occurrence SSH, car plein de réseaux ne laissent d'accès que via le port 443).

Tout à fait. Une durée de validité des signatures DNSSEC de deux mois me convient tout à fait. Ceci dit, quand la re-signature est automatique (ce qui est fortement recommandé), la question du délai est moins cruciale.

Et la comparaison avec TLS n'est pas bonne car TLS ne permet pas facilement d'attaques par rejeu.

"Certaines" ? Non. Sans authentification, TLS est vulnérable à toutes les attaques de l'homme du milieu. Sans DNSSEC, le DNS est même vulnérable à l'homme du bord (pas besoin d'être homme du milieu pour faire un empoisonnement DNS.) Sans authentification, TLS ne protège que contre un attaquant passif (genre Firesheep).

Tout à fait d'accord sur le risque que la sécurité n'empêche les "petits" acteurs de se développer et les décourage, avant de les jeter dans les bras des gros silos fermés.

Pour LinuxFr, je suppose qu'il y a assez de compétences disponibles. Pour M. Michu qui voudrait faire un truc équivalent, on manque en effet d'outils simples et bien intégrés. Une bonne discussion avait eu lieu sur LinuxFr à ce sujet : https://linuxfr.org/users/bortzmeyer/journaux/rendre-l-auto-hebergement-facile-et-sans-douleur

Attention, c'est vrai qu'il faut re-signer périodiquement lorsqu'on utilise DNSSEC mais ce n'est pas forcément à la main, il est même au contraire très recommandé d'utiliser un outil automatique. Je suggère OpenDNSSEC (libre, évidemment, et tournant sur Linux, évidemment). http://www.opendnssec.org/

C'est pas qu'on s'en éloigne, c'est qu'on file à l'autre bout de la galaxie : la solution OVH est du pur claoude. On peut aimer mais question liberté, c'est pas ça…

L'accès à www.bortzmeyer.org en HTTPS est sur mon TODO. Le principal problème est la pénurie d'adresses IPv4. J'ai peu d'adresses et le port 443 est déjà pris par autre chose.

C'est vrai que seulement deux serveurs de noms pour linuxfr.org, tous les deux chez le même opérateur, ça fait un peu léger. Je suis sûr qu'on trouverait des secondaires volontaires dans la communauté (je suis volontaire, par exemple).

Je ne comprends pas l'allusion à dns2tcp (c'est quoi ? juste un tunnel IP sur DNS ?) Il y a encore des gens compétents (pas des certifiés Cisco) pour limiter la taille des paquets DNS à 512 octets ???

Aucun détail, aucune référence ? Du pur FUD.