Stéphane Bortzmeyer a écrit 655 commentaires

Bon, mais ils n'ont rien de "rogue", ces résolveurs.

Cela risque-t-il d'impacter les rogues DNS ?

Euh, il faudrait expliquer la question.

Il y a de nombreuses années (2013 !) qu'asso.fr est fermé (les noms existants continuent mais il n'y a plus de créations)

PS : l'article cité a plus de dix-huit ans…

Une bonne réputation ? Venue d'où ? Évaluée par qui ?

Ceci dit, une fois installé, un résolveur ne tombe que très rarement en panne. Il n'y a que DNSSEC qui nécessite du soin.

Ce qui est justement une mauvaise idée.

Ce problème a été remonté aux développpeurs de RIPE Atlas, et ils cherchent une solution.

Je ne suis pas convaincu qu'il y a un problème. C'est plutôt l'affichage Web d'Atlas qui est trompeur. Quand on regarde le JSON des résultats (https://atlas.ripe.net/api/v2/measurements/22766270/results/), on n'a au contraire que des succès.

Par exemple, la sonde 12774 est marquée comme "undefined" dans l'interface graphique alors que, dans le fichier JSON, on voit qu'elle a eu un résultat positif d'un de ses résolveurs.

Je soupçonne que l'affichage trompeur vient des erreurs de connexion vers les résolveurs IPv6. C'est en tout cas ce qu'on voit dans les résultats bruts :

     {
        "dst_name": "fe80::3e81:d8ff:fede:fbf8",
        "error": {
          "socket": "connect failed Invalid argument"
        },

Toujours se méfier des jolies affichages graphiques !

https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-off-measurements-with-blaeu

« Tout le monde n'a pas une machine qu'il contrôle sur internet (moi personnellement je n'en ai pas, je fais comment alors?) » OU BIEN VERS UNE MACHINE PRÉVUE POUR CELA, c'était écrit. Les ancres Atlas, par exemple. https://labs.ripe.net/Members/stephane_bortzmeyer/checking-your-internet-connectivity-with-ripe-atlas-anchors

« si ca marche, je teste un ping sur www.google.Fr » C'est très sommaire comme test :

• ping ne donnera pas de message d'erreur détaillé s'il y a un problème DNS (juste du binaire ça marche / ça marche pas). Pour tester le DNS, il vaut mieux utiliser dig.
• s'il y a une panne, comment savoir si elle est de la faute de Google, de l'AFNIC ou du résolveur ?

« si ca marche, je pinge le 8.8.8.8 » Et si Google vient de décider d'arrêter de répondre aux requêtes ICMP echo, ou bien de limiter le taux de réponse ?

Un test général de connectivité doit se faire vers une machine qu'on contrôle, ou bien vers une machine explicitement prévue pour cela (donc pas Google Public DNS).

Pascal Courtois avait également programmé en C le serveur HTTP du CNAM, à l'époque où il n'y avait que deux ou trois serveurs HTTP publics en France (1993), et où aucun logiciel publié n'avait les performances nécessaires (aujourd'hui, c'est banal, des serveurs HTTP qui servent des milliers de requêtes par seconde, mais à l'époque c'était tout nouveau et Pascal avait contribué à défricher ce domaine, et il avait passé beaucoup de temps à régler la machine Ultrix, puis OSF/1). Cf. le livre de Valérie Schafer, « En construction ».

ISO 8601, comme toutes les normes ISO, permet de tas de variantes et vous seriez bien embêté·e·s s'il fallait écrire du code pour gérer toutes les possibilités d'ISO 8601. Notamment, contrairement à une légende répandue, ISO 8601 ne garantit pas que le tri alphabétique soit également un tri chronologique.(Si quelqu'un ici a déjà lu la norme ISO 8601, qu'ielle lève la main.)

La bonne solution pour les dates est celle du RFC 3339.

Oui, enfin, il y a UNE virgule qui n'a pas d'espace après. Je suis impressionné par le niveau de rigueur typographique de certain·e·s mais, franchement, est-ce que cela gêne la lecture ?

Juste la flemme intellectuelle de ma part :-)

Ah, le premier vote est négatif. Un·e ami·e des GAFA qui ne veut pas les voir souffrir ? Ou bien un·e programmeu·r·se qui a essayé de mettre en œuvre ActivityPub et l'a trouvé trop compliqué ?

Ce qui prouve que Python n'utilise pas la catégorie Unicode Lettre puisque ce caractère, U+1F464 BUST IN SILHOUETTE, a la catégorie Symbole, comme tous les émojis. (Mauvaise idée de Python, à mon avis.)

La date du 21 janvier ne semble plus d'actualité, la négociation se passant mal. Donc, tout cela est repoussé mais pas annulé, donc la lutte contre cette directive continue.

L'épinglage de clé publique ? Ya encore des gens qui utilisent ça ? C'est très casse-gueule, surtout avec Let's Encrypt.

Quant à TLS+HSTS, oui, les navigateurs vérifient mais les apps et autres logiciels ne le font pas forcément.

J'avais oublié quelques trucs intéressants. D'abord, beaucoup de registres de noms de domaine ont une solution nommée « verrouillage » (ou « lock » en anglais) qui permet d'empêcher toute modification d'un domaine (l'éventuel déverrouillage nécessitant une opération manuelle, avec vérification). Cela coûte de l'argent, mais cela aurait sans doute protégé linux.org.

Ensuite, l'AFNIC aussi a une documentation sur la sécurité de vos noms de domaine.

Référence ?

On n'est pas forcé de croire l'ICANN au pied de la lettre : depuis des années, des serveurs whois sont conformes (le RGPD ne date pas d'aujourd'hui) https://twitter.com/Gnppn/status/986187291566764032

Si le port 853 n'est pas bloqué. L'avantage de HTTPS, c'est qu'il passe partout.

Je trouve dommage que, jusqu'à présent, tous les commentaires portent sur le djandeur et sur la grammaire. LinuxFr n'est pas l'Académie Française, normalement, on connait le C mieux que le français. Donc, siouplè, merci de commenter aussi sur le fond, sur les MMORPG, sur le graphisme, sur le financement, et sur comment gérer sa Kimsufi.

Les ICMP "packet too big" existent aussi en IPv4. Si un administrateur réseaux incompétent les bloque, c'est tout aussi bête qu'en IPv6. Franchement, je ne vois pas l'intérêt de ces règles ultra-compliquées.