Stephane Bortzmeyer a écrit 479 commentaires

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.

Tiens, justement, le clown ridicule qui publie ces drafts (pas ses meilleurs : le meilleur était celui où il concevait un réseau de satellites connectés par des fibres optiques) vient de faire une nouvelle version, la -11 :-}

Cette fois, il a ajouté une section DNS :-(

Ben, d'abord, la plupart des utilisat·eur·rice·s ne comprennent pas IPv4, et cela ne les empêche pas de dormir. Donc, qu'ielles ne comprennent pas IPv6 n'est pas trop grave.

Ensuite, pour ce·ux·lles qui ont besoin de comprendre (administrat·eur·rice réseaux, par exemple) IPv6 n'est pas un autre protocole, c'est une nouvelle version du même protocole, donc ça s'apprend comme IPv4, les concepts de base sont les mêmes (datagrammes, adresses, préfixes, routage, (in-)sécurité, etc).

L'autoconfiguration fondée sur l'adresse MAC est officiellement fortement déconseillée depuis 2012 http://www.bortzmeyer.org/6724.html mais, en pratique, Ubuntu, Windows et quelques autres ne l'utilisait déjà plus par défaut.

Pour les pare-feux, comme indiqué plus haut, c'est comme en IPv4.

Et pour l'histoire de vie privée, c'est 99 % de FUD http://www.bortzmeyer.org/7721.html

Au passage, au FOSDEM, ce week-end, le Wifi est en IPv6 seul par défaut. Avec NAT64. Et ça juste marche. Quand les gens bossent, au lieu de chouiner et de faire des réunions, IPv6 est simple. Juste fais le.

    % iwconfig wlp2s0
    wlp2s0    IEEE 802.11abgn  ESSID:"FOSDEM"  
              Mode:Managed  Frequency:5.24 GHz  Access Point: 64:D9:89:90:2E:2C   
              Bit Rate=300 Mb/s   Tx-Power=22 dBm   
              Retry short limit:7   RTS thr:off   Fragment thr:off
              Power Management:on
              Link Quality=27/70  Signal level=-83 dBm  
              Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
              Tx excessive retries:0  Invalid misc:4   Missed beacon:0

    % ip addr show wlp2s0
    3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1350 qdisc mq state UP group default qlen 1000
        link/ether b8:08:cf:18:6f:48 brd ff:ff:ff:ff:ff:ff
        inet6 2001:67c:1810:f051:5da8:d941:e88b:c1f4/64 scope global temporary dynamic 
           valid_lft 604636sec preferred_lft 85636sec
        inet6 2001:67c:1810:f051:6196:815a:49b3:d495/64 scope global mngtmpaddr noprefixroute 
           valid_lft forever preferred_lft forever
        inet6 fe80::d22:3668:c059:8007/64 scope link 
           valid_lft forever preferred_lft forever