Quad9, résolveur DNS public, et sécurisé par TLS

Posté par  (site web personnel, Mastodon) . Édité par Davy Defaud, ZeroHeure, Florent Zara, Nils Ratusznik et Benoît Sibaud. Modéré par bubar🦥. Licence CC By‑SA.
Étiquettes :
41
17
nov.
2017
Internet

Le résolveur DNS Quad9 (prononcer « quoi de neuf » en français) a été annoncé aujourd’hui. C’est un résolveur DNS public, mais dont l’originalité est d’être accessible de manière sécurisée, avec TLS (DNS sur TLS est décrit dans le RFC 7858).

Alors, le lectorat de LinuxFr.org, étant très au fait du sujet, va dire « mais des résolveurs DNS publics, il y en a plein ! Pourquoi un de plus ? ». Le plus connu est Google Public DNS, mais il en existe beaucoup d’autres, avec des politiques et des caractéristiques techniques diverses. Notamment, tous (à l’exception de Cisco OpenDNS) sont non sécurisés : le lien entre vous et le résolveur est en clair, tout le monde peut écouter, et il n’est pas authentifié, donc vous croyez parler à Google Public DNS mais, en fait, vous parlez au tricheur que votre FAI a annoncé dans ses réseaux locaux.

Et Quad9, c’est mieux, alors ? D’abord, c’est géré par l’organisme sans but lucratif bien connu PCH, qui gère une bonne partie de l’infrastructure du DNS (et qui sont des copains, oui, je suis subjectif).

Quad9, lui, sécurise par TLS (RFC 7858). Cela permet d’éviter l’écoute par un tiers, et cela permet d’authentifier le résolveur (mais, attention, je n’ai pas encore testé ce point, Quad9 ne semble pas distribuer de manière authentifiée ses clés publiques).

Question politique, des points à noter :

  • Quad9 s’engage à ne pas stocker votre adresse IP ;
  • leur résolveur est un résolveur menteur : il ne répond pas (délibérément) pour les noms de domaines qu’il estime liés à des activités néfastes comme la distribution de logiciels malveillants.

L’adresse IPv4 de Quad9, comme son nom l’indique, est 9.9.9.9. Son adresse IPv6 est 2620:fe::fe. D’abord, un accès classique en UDP en clair, sur votre distribution GNU/Linux favorite :

% dig +nodnssec @9.9.9.9 AAAA irtf.org   

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +nodnssec @9.9.9.9 AAAA irtf.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11544
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;irtf.org.      IN AAAA

;; ANSWER SECTION:
irtf.org.       1325 IN AAAA 2001:1900:3001:11::2c

;; Query time: 4 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Thu Nov 16 09:49:41 +08 2017
;; MSG SIZE  rcvd: 65

On y voit que Quad9 valide avec DNSSEC (la réponse a bien le bit AD — Authentic Data).

Maintenant, testons la nouveauté importante de ce service : DNS sur TLS. C’est du TLS, donc on peut y aller avec openssl :

% openssl s_client -connect \[2620:fe::fe\]:853 -showcerts

On voit que Quad9 répond bien en TLS et a un certificat Let’s Encrypt.

Testons ensuite avec un client DNS, le programme getdns_query distribué avec getdns (l’option -l L lui dit d’utiliser DNS sur TLS) :

% getdns_query @9.9.9.9 -s -l L www.afnic.fr AAAA
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": <bindata for lb01-1.nic.fr.>,
  "just_address_answers":
  [
    {
      "address_data": <bindata for 2001:67c:2218:30::24>,
      "address_type": <bindata of "IPv6">
    }
 ...

On peut utiliser tshark pour vérifier qu’on est bien en TLS :

% tshark -n -i eth0  -d tcp.port==853,ssl host 9.9.9.9

Le -d tcp.port==853,ssl était là pour dire à tshark d’interpréter ce qui passe sur le port 853 (celui de DNS-sur-TLS) comme étant du TLS. On voit bien le dialogue TLS, mais évidemment pas les questions et réponses DNS puisque tout est chiffré.

Bien, maintenant que les tests se passent bien, comment utiliser Quad9 pour la vraie résolution de noms ? On va utiliser Stubby pour parler à Quad9. Le fichier de configuration Stubby sera du genre :

listen_addresses:
  - 0::1@8053

dns_transport_list:
  - GETDNS_TRANSPORT_TLS

upstream_recursive_servers:
# Quad9
   - address_data: 9.9.9.9
     tls_auth_name: "dns.quad9.net"
   - address_data: 2620:fe::fe
     tls_auth_name: "dns.quad9.net"

On indique à stubby d’écouter sur l’adresse locale ::1, port 8053, et de faire suivre les requêtes en DNS sur TLS à 9.9.9.9 ou 2620:fe::fe. On lance stubby :

% stubby

Et on peut le tester, en utilisant dig pour interroger à l’adresse et au port indiqué :

% dig @::1 -p 8053 A www.catstuff.com 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @::1 -p 8053 A www.catstuff.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20910
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65535
;; QUESTION SECTION:
;www.catstuff.com.  IN A

;; ANSWER SECTION:
www.catstuff.com.   600 IN A 216.157.88.24

;; Query time: 974 msec
;; SERVER: ::1#8053(::1)
;; WHEN: Thu Nov 16 20:29:26 +08 2017
;; MSG SIZE  rcvd: 77

Et on peut vérifier avec tshark que Stubby parle bien avec Quad9, et en utilisant TLS.

Stubby a l’avantage de bien gérer TCP, notamment en réutilisant les connexions (il serait très coûteux d’établir une connexion TCP pour chaque requête DNS, surtout avec TLS par dessus). Mais il n’a pas de cache des réponses, ce qui peut être ennuyeux si on est loin de Quad9. Pour cela, le plus simple est d’ajouter un vrai résolveur, ici Unbound. On le configure ainsi :

server:
   interface: 127.0.0.1
   do-not-query-localhost:  no
forward-zone:
  name: "."
    forward-addr: ::1@8053

Avec cette configuration, Unbound va écouter sur l’adresse de bouclage 127.0.0.1 (sur le port par défaut, 53, le port du DNS) et relayer les requêtes pour lesquelles il n’a pas déjà une réponse dans son cache vers Stubby (::1, port 8053). Interrogeons Unbound :

% dig @127.0.0.1 A mastodon.gougere.fr

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 A mastodon.gougere.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40668
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mastodon.gougere.fr.   IN A

;; ANSWER SECTION:
mastodon.gougere.fr.    600 IN A 185.167.17.10

;; Query time: 2662 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Nov 16 20:36:09 +08 2017
;; MSG SIZE  rcvd: 64

Unbound a une mémoire (le cache). Donc, si l’on recommence la requête aussitôt, la réponse arrivera bien plus vite et on verra le TTL diminué.

Aller plus loin

  • # Engagement

    Posté par  (site web personnel) . Évalué à 8.

    Quad9 s'engage à ne pas stocker votre adresse IP ;
    leur résolveur est un résolveur menteur : il ne répond pas (délibérément) pour les noms de domaines qu'il estime liés à des activités néfastes comme la distribution de logiciel malveillant.

    Il me semble que la loi française oblige la conservation des IP un an mais que la loi européenne ne soit pas aussi stricte (cf bras de fer entre FDN et la justice). Quad9 stocke actuellement combien de temps les IP dans les log par exemple ? En effet, il y a conservation des IP a des fins de stockage pour traçage / revente… et les log qui sont principalement là en cas de problème (et parfois pour faire des camemberts couleurs pour ceux qui ont du temps). De même, la géolocalisation se fait jusqu’à quel niveau (National, Régional, Communal…) ?

    Est-il possible d'avoir la liste ou les listes du menteur comme le fait l'université de Toulouse. C'est bien pratique de pouvoir ré-utiliser ces listes bien faites sans que chacun refasse le monde dans son coin, quitte à participer et proposer des noms à ajouter dans ces listes (cela m'est déjà arrivé pour Toulouse par exemple).

    • [^] # Re: Engagement

      Posté par  (site web personnel) . Évalué à 6.

      Les obligations légales de conservation de traces en France s'appliquent aux hébergeurs de contenu en ligne, et aux opérateur de télécommunication (les fournisseurs d'accès, en clair). Un DNS public me parait difficilement assimilable à l'une ou l'autre de ces catégories.

      • [^] # Re: Engagement

        Posté par  (site web personnel) . Évalué à 5.

        On n'est pourtant plus très loin (après dkim, sshfp, dane, et autres joyeusetés) de partager des photos d'Estelle Halliday avec le DNS. :)

        Adhérer à l'April, ça vous tente ?

    • [^] # Re: Engagement

      Posté par  . Évalué à 5.

      J'ai l'impression de me connecter à une instance située à Londres. Nous pouvons donc nous asseoir sur les lois française et faire confiance aux five eyes.
      D'après la politique de vie privé, la géolocalisation va aussi loin qu'elle le peut et est conservé aussi longtemps que possible.

      D'après le about. Les mensonges sont fournis par IBM X-Force.

  • # rfc7858

    Posté par  . Évalué à 10.

    Quoi de neuf ?

    On ne peut que se réjouir de l'arrivée d'un acteur qui devrait favoriser la démocratisation de l'usage de DNS sur TLS (rfc7858).
    Dans cette quête de "privacy" autour de DNS, il serait malheureux que ce soit une solution quasi propriétaire (DNSCrypt) ou promue par Google (dns-over-https) qui l'emporte.
    On regrettera évidemment le choix délibéré de filtrer les réponses mais on ne va pas faire la fine bouche, c'est préférable à tout ce que l'on a vu jusqu'à présent.
    Espérons que d'autres initiatives plus neutres viennent à l'avenir concurrencer celle-ci.

    Une (micro) contribution en complément à cet excellent journal

    De nos jours, devoir se passer de l'authentification TLS du résolveur est, pour certains, rédhibitoire.
    Pour pallier ce manque, voici une horreur permettant de "découvrir" la valeur "tls_pubkey_pinset" voulue par Stubby : 

    ip=9.9.9.9
port=853

openssl s_client -showcerts -connect $ip:$port </dev/null 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

    Cela permet d'obtenir, à l'heure qu'il est, la configuration Stubby suivante 1 : 

    dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
upstream_recursive_servers:
   - address_data: 9.9.9.9
     tls_auth_name: "dns.quad9.net"
     tls_pubkey_pinset:
       - digest: "sha256"
         value: MujBQ+U0p2eZLTnQ2KGEqs+fPLYV/1DnpZDjBDPwUqQ=

    Un (petit) retour d'expérience de DNS sur TLS

    J'ai mené ces dernières semaines quelques expérimentations autour de solutions permettant de mettre en oeuvre le rfc7858 chez soi.

    Mon retour d'utilisation de Stubby est mitigé.
    Heureux possesseur d'un routeur Turris, j'ai configuré le résolveur Knot pour rediriger les requêtes DNS vers un container LXC qui héberge une instance Stubby (ouf). J'utilise les trois premiers résolveurs de la configuration par défaut de Stubby qui, depuis ma connexion Orange, offrent une latence acceptable 2 . Cette configuration fonctionne parfaitement… jusqu'à ce qu'elle tombe en panne.
    Il faut régulièrement relancer Stubby qui se fige au bout de quelques heures.
    Le diagnostic n'est pas aisé car le logging de stubby est, pour l'instant, assez rudimentaire.
    Il faudrait effectuer une analyse de trafic réseau.
    TLS masquant la couche application, cela pourrait être fastidieux.
    Pour ne rien arranger, j'ai autour de moi des utilisateurs exigeants qui n'arrivent pas à comprendre que, sous prétexte d'échapper au regard de la NSA, twitch.tv ou vente-privee.com ne soient régulièrement plus accessibles 3 …

    Pour rétablir la paix dans mon foyer, j'ai du me rabattre sur un mode fort bien expliqué ici (et là) qui couple un tunnel TLS à destination du résolveur public (réalisé avec stunnel) avec une instance du résolveur Unbound chargée d'établir un "pont" TCP/UDP.
    Cette configuration est la plus stable que j'ai trouvée jusqu'à présent.
    Elle présente cependant le défaut majeur d'établir une session TCP/TLS à chaque requête DNS 4 . En plus de ne pas être performant, c'est assez peu respectueux des ressources sollicitées.
    Si une bonne âme avait une idée pour configurer stunnel (ou socat) afin de "persister" la session TCP client, je lui serais éternellement reconnaissant :)
    En attendant, je vais tenter un retour à Stubby avec Quad9 pour tester si la stabilité est au rendez-vous.

    À suivre © …

    1 Les lecteurs attentifs ne manqueront pas d'observer que :

    • ce hack permettrait tout aussi bien de récupérer la signature du certificat public d'un attaquant déjà en place,
    • une nouvelle valeur devra être appliquée à chaque émission d'un nouveau certificat, ce qui en utilisant une CA comme Let's Encrypt se produira fréquemment. Idéalement, Quad9 devrait utiliser un certificat autosigné (attention, troll inside) avec un délai d'expiration suffisamment long et, comme dit dans le journal, communiquer la clef publique par différents moyens sécurisés.

    2
    À propos de latence (qui est critique en matière de DNS), un traceroute lancé ce jour depuis le réseau Orange montre que le dernier saut avant 9.9.9.9 est l'adresse IP 83.231.233.182 qui s'avère géolocalisée en Grande Bretagne.
    Cela laisse penser qu'il n'y a pas (encore) d'instance Quad9 en France.
    Dommage avec un nom pareil :(

    3
    Que diraient-ils s'ils savaient que, alors que j'argumente autour de la nécessaire protection de leur vie privée, je m'abstiens de dire que le seul chiffrement du trafic DNS ne les protège pas des regards indiscrets du fait du transport en clair du champ SNI à l'initialisation d'HTTPS…
    (Quand on lit ceci qui n'est qu'à l'état de proposition, on a la désagréable impression que ce n'est pas demain que l'on aura un niveau de "privacy" acceptable même avec le fameux cadenas vert).

    4
    L'auteur de la page sus-citée a commis un outil qui cherche à résoudre le problème.

    • [^] # Re: rfc7858

      Posté par  (site web personnel) . Évalué à 3.

      Si une bonne âme avait une idée pour configurer stunnel (ou socat) afin de "persister" la session TCP client,
      je lui serais éternellement reconnaissant :)

      Les requêtes arrivent un message par connection : si on voulait que stunnel ou socat fasse passer tous les messages dans la même connections TCP, on aurait besoin de faire le framing des messages et de faire la correspondance entre les réponses obtenues et les requêtes pour envoyer la bonne réponse au bon client. On aurait besoin d'une compréhension (minimale) du protocols DNS au niveau de stunnel/socat. Ce n'est pas vraiment le rôle de stunnel/socat d'implémenter la logique de framing et matching requêtes/réponses de DNS.

    • [^] # Re: rfc7858

      Posté par  (site web personnel) . Évalué à 1.

      Dans cette quête de "privacy" autour de DNS, il serait malheureux que ce soit une solution quasi propriétaire
      (DNSCrypt) ou promue par Google (dns-over-https) qui l'emporte.

      Après, si la solution promue par Google est implémentée par d'autres que Google ce ne serait pas forcément un problème.

      Ce qui est un peu dommage, je trouve c'est que leur "dns-over-https" n'est pas du DNS/HTTPS. Ce n'est pas vraiment le protocole DNS, mais le contenu des champs des messages DNS encodés en JSON le tout transporté au dessus de HTTPS. L'idée étant, je crois, d'être facilement consommable par des client web JS (sinon, ils auraient pu faire un lib JavaScript qui parse et formate des messages DNS et faire passer des vrais messages DNS dans les tuyaux).

      Mon retour d'utilisation de Stubby est mitigé.

      Un truc que je trouve assez dommage c'est que Stubby tourne forcément en root pour le moment.

      • [^] # Re: rfc7858

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Ce qui est un peu dommage, je trouve c'est que leur "dns-over-https" n'est pas du DNS/HTTPS. Ce n'est pas vraiment le protocole DNS, mais le contenu des champs des messages DNS encodés en JSON

        Le groupe de travail DoH de l'IETF travaille justement à normaliser un DNS sur HTTPS utilisant le « wire format », c'est-à-dire l'encodage habituel du DNS (et pas JSON). Un premier prototype a été produit au hackathon à l'IETF 100 à Singapour la semaine dernière.

        Un truc que je trouve assez dommage c'est que Stubby tourne forcément en root pour le moment.

        Nuançons : il peut parfaitement tourner sous un compte utilisateur ordinaire (c'est ce qui est proposé dans la dépêche, et décrit au début). Le problème est si on veut écouter sur le port 53.

  • # Écriture

    Posté par  . Évalué à 0.

    Alors, le lectorat de LinuxFr.org étant super au courant, va dire « mais des résolveurs DNS publics, il y en a plein !

    La phrase est mal tournée. Et je trouve "le lectorat" un peu impersonnel :)

    • [^] # Re: Écriture

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      Dans le journal original, cette phrase était en écriture inclusive. Certains lecteurs de LinuxFr, ayant le niveau politique (et l'âge ?) d'un membre de l'Académie Française, ont protesté. La phrase a donc été réécrite (et ce n'est effectivement pas terrible).

      • [^] # Re: Écriture

        Posté par  . Évalué à 0. Dernière modification le 18 novembre 2017 à 21:40.

        Certains membres de LinuxFR ont des arguments, d'autres comme plus haut n'ont que des insultes, faute d'arguments.

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

        • [^] # Re: Écriture

          Posté par  (site web personnel, Mastodon) . Évalué à -2.

          Des arguments sérieux ? Parce que « c'est pas compatible avec les lecteurs d'écran pour malvoyants » est un argument faux, émis par quelqu'un qui n'a jamais testé ces lecteurs, et « c'est peu lisible » est un argument rigolo, venant sur LinuxFr où les gens lisent et écrivent des regexp toute la journée.

          • [^] # Re: Écriture

            Posté par  . Évalué à 10.

            un argument rigolo, venant sur LinuxFr où les gens lisent et écrivent des regexp toute la journée.

            Personnellement, je ne trouve pas les regex très lisibles, je les écrits surtout pour qu'elles soient lues par un ordinateur, pas par des humains.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Écriture

            Posté par  (site web personnel) . Évalué à 10.

            Des arguments sérieux ?

            Je m'en veux un peu de poursuivre sur ce hors-sujet mais il me semble que l'argument principal contre l'écriture inclusive (une dénomination déjà militante) est que le genre des mots et celui des personnes sont deux choses différentes.
            Confondre ou faire semblant de confondre les deux est une erreur.
            L'article d'Odieux Connard déjà cité dans le journal (lien) est certes outrancier et humoristique dans sa caricature mais il résume bien cet argument.
            Et pour un texte argumentatif de plus haute tenue littéraire on peut se reporter au billet de Jean-François Revel évoqué récemment sur LinuxFr.

            • [^] # Re: Écriture

              Posté par  (site web personnel) . Évalué à 10.

              J'ai plein d'arguments contre l'écriture inclusive. Je m'en veux aussi un peu de poursuivre le hors sujet, mais je vais quand-même faire une liste rapide.

              D'abord entendons-nous sur l'objets: les tenants de l'écriture inclusive proposent de mentionner les deux accords possibles d'un mot en utilisant un notation du style “Les étudiant.e.s de l'université Paris Sud demandent plus d'heures de tutorat.” le but affiché de cet usage est d'attirer l'attention du lecteur sur la possibilité offerte aux femmes d'embrasser et de s'approprier les rôles sociaux auxquels on fait ainsi référence. Dans l'exemple donné, on attire l'attention du lecteur sur le fait qu'une femme est tout aussi légitime qu'un homme pour étudier à Paris Sud, ce qui selon les tenants de l'écriture inclusive pourrait passer inaperçu dans la forme “Les étudiants de l'université Paris Sud demandent plus d'heures de tutorat.”

              Voici ma liste des reproches:

              • Le plus grave à mon avis est que les tenants de l'écriture inclusive s'immiscent dans ma liberté d'interprétation d'un texte en affirmant une nouvelle norme “étudiants” désignerait nécessairement un groupe d'hommes et le groupe mixte serait nécessairement “étudiant.e.s”. C'est un très grave contre-sens sur le fonctionnement de la communication puisque la réflexion sur le sens que voulait donner l'auteur d'un message aux mots qu'il a employé est partie intégrante de la communication. Même en mathématiques où l'on cherche à utiliser un langage particulièrement univoque, cette réflexion ne saurait être négligée. Ce point est particulièrement important à l'heure où la société commence à ouvrir les yeux sur l'intersexualité et la transsexualité.

              • Le système se base sur une confusion entre genre grammatical et genre sexué, confusion que la langue ne fait pas et qui même nous rappelle en de nombreux endroits que ces notions sont différentes – notamment par les genres des noms de métiers. Même si cela ne porte pas à proprement parler sur les questions de genre, dans les débats connexes on rappelle souvent la règle d'accord qu'un abbé du XVIIIème énonçait en disant que “le masculin l'emporte sur le féminin” en négligeant de mentionner que les grammairiens d'aujourd'hui préfèrent parler de genre non distingué pour le masculin (c'est l'accord qu'on prend pour les pluriels mixtes, les formes impersonnelles, ou les jeunes: un bébé, un enfant, un marcassin, …) et de genre distingué pour le féminin.

              • Il n'est pas clair que l'emploi de cette forme ait l'effet escompté, dans les pays parlant l'anglais comme les USA, le Royaume Uni ou l'Australie, la condition sociale des femmes semble comparable (ou pire) qu'en France ou en Allemagne.

              • En rendant l'écriture plus lourde cette forme rend plus difficile l'expression de pensées subversives et audacieuses.

              Je pense pouvoir continuer un peu cette liste, mais cessons ici. Le seul mérite que je verrais à l'écriture inclusive serait d'ouvrir vers un débat sur la place des femmes dans la société et les combats actuels du féminisme. Mais est-ce ce qu'on voit? On a déjà parlé beaucoup d'écriture inclusive sur LinuxFR et le débat s'est toujours enfermé sur les questions de forme sans jamais s'ouvrir sur celui, plus crucial à mon avis, des combats féministes qui restent à mener.

              • [^] # Re: Écriture

                Posté par  (site web personnel) . Évalué à 10.

                Deux ajouts à la liste:

                • [^] # Re: Écriture

                  Posté par  . Évalué à 5. Dernière modification le 21 novembre 2017 à 12:42.

                  D'après l'article d'Europe1, le communiqué de la Fédération des Aveugles de France contiendrait ce passage : « Pour nous personnes aveugles, cette soi-disant langue inclusive est proprement indéchiffrable par nos lecteurs d'écrans ». Je m'inscris totalement en faux contre cet argument en vertu du principe, déjà invoqué, suivant : « c'est pas compatible avec les lecteurs d'écran pour malvoyants » est un argument faux, émis par quelqu'un qui n'a jamais testé ces lecteurs. En effet, il va de soi que les aveugles n'ont jamais testé les lecteurs d'écran et sont les moins à même d'en parler. :-P

                  P.S : ceci étant dit, je n'ai pas réussi à trouver le communiqué en ligne sur leur site, bien que plusieurs journaux en parlent.

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                  • [^] # Re: Écriture

                    Posté par  (site web personnel) . Évalué à 5.

                    Il y a les personnes aveugles à proprement parler mais aussi toutes les personnes dont la vision est très détériorée, au point que cela en devient un handicap qu'on ne peut alléger en utilisant de simples lunettes. Pour ces personnes il y a plusieurs façon d'accéder à un texte imprimé, plus ou moins approprié selon la forme exacte que prend leur handicap. Les systèmes les plus basiques sont un simple agrandisseur. Il y a aussi des systèmes plus sophistiqués qui se basent sur la reconnaissance de caractère et font un agrandissement – avec l'avantage sur le système précédent que la ligne lue est isolée du reste du texte – ou bien une traduction en synthèse vocale ou vers un afficheur braille sur un dispositif approprié. Je connais seulement un peu l'agrandisseur que j'ai déjà vu mais pas les autres systèmes dont j'ai seulement lu des description ici et là. (Il y a par exemple un contributeur relativement connu de freebsd-questions@ qui utilise ce genre de dispositifs.)

                    Les personnes qui sont à proprement parler aveugles n'ont bien-sur pas pu tester les écrans auxquels l'article fait référence mais d'autres personnes dont la vision est handicapée ont pu le faire.

          • [^] # Re: Écriture

            Posté par  (site web personnel) . Évalué à 9.

            C'est très personnel mais ça m'est très pénible à la lecture et ça me ralentit beaucoup quand je lis. On pourra dire que c'est une affaire d'habitude mais je ne suis pas sûr. Je sais que j'ai une manière de lire particulière parce que je vois les typos beaucoup plus que les autres gens : elles ont tendance à me péter à la figure. Pareil, je suis quasiment incapable de lire en phonétique, ça me demande un effort surhumain.

            Si ce n'était que moi, je comprendrais que tout le monde s'en fout mais je suis assez sûr de ne pas être le seul à qui c'est très désagréable.

            Je me rappelle que dans un thread similaire quelqu'un parlait des différentes manières dont les gens lisaient et que ça perturbait plus ou moins les gens suivant la manière dont ils lisaient.

            Et je rejoins l'autre argument déjà cité par d'autres que ce n'est pas une super idée de vouloir tout sexuer. Dans la majorité des cas, je m'en fous que ce soit une femme ou un homme et vouloir rappeler cette distinction à tout bout de champ comme si c'était important, je ne suis pas sûr que ça serve la cause.

            Quand on parle de "lecteurs" typiquement, j'ai du mal à voir l'intérêt de sexuer et d'en faire quelque chose de militant ? Si on ne précise pas, on va supposer que les femmes ne savent pas lire ?

            Dans d'autres contextes, je peux comprendre l'intérêt de préciser pour marquer le coup. Mais tant qu'à faire, je rajouterai "(hommes et femmes)" (voire "de tout sexe" pour vraiment inclure tout le monde) ou utiliserai "{féminin}s et {masculin}s".

            En résumé, si mon avis devait avoir une importance, je dirai :
            - ne sexualisons que là où ça peut effectivement faire une différence et qu'il est nécessaire de marquer le coup, et au contraire, ne le faisons pas quand ça n'en a aucune ;
            - utilisons des formes syntaxiquement correctes de manière à éviter de perturber les gens qui lisent.

            Le message passera tout aussi bien, voire mieux.

      • [^] # Re: Écriture

        Posté par  (site web personnel) . Évalué à 2.

        réécrite récrite. Quand le vin est tiré… Autant persévérer dans les finasseries académiques jusqu'à la lie.

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: Écriture

          Posté par  . Évalué à 3.

          Les deux sont valables, mais merci quand même.

    • [^] # Re: Écriture

      Posté par  (site web personnel) . Évalué à 4.

      OK, j'essaie à mon tour de proposer une nouvelle tournure.

  • # autres DNS chiffrés autentifiés

    Posté par  (site web personnel) . Évalué à 7.

    tous (à l’exception de Cisco OpenDNS) sont non sécurisés

    C'est incorrect. Google Public DNS est disponible en mode DNS-over-HTTPS : https://developers.google.com/speed/public-dns/docs/dns-over-https
    Certes c'est pas standardisé dans une RFC et il peut y avoir d'autres raisons de préférer un autre resolver mais il n'est pas correct de dire que seuls Quad9 et Cicso OpenDNS permette de chiffrer/autentifier la résolution.

    Par ailleurs le lien vers « Stubby » est intitulé « Subby ».

    (je travaille chez Google)

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Quad9 et Tor

    Posté par  . Évalué à 3.

    La documentation de Tor recommande de ne pas utiliser Quad9 sur les nœuds de sortie (on rappelle que dans Tor c’est ce nœud qui se charge de la résolution DNS) :

    A bad relay is one that either doesn't work properly or tampers with our users' connections. This can be either through maliciousness or misconfiguration. Some common examples are…
    - […]
    - Using a DNS provider that censors its results (such as some ​OpenDNS or Quad9 (9.9.9.9) configurations).
    - […]

  • # CurveDNS

    Posté par  . Évalué à 1.

    Pour ce qui est du chiffrement des requêtes DNS vers un forwarder, il existe depuis longtemps http://curvedns.on2it.net/.
    Le paquet Debian se trouve ici : https://packages.debian.org/buster/curvedns
    Sur ubuntu : https://packages.ubuntu.com/search?keywords=curvedns

    Il permet de chiffrer ses requêtes via Curve25519, perso je préfère ça à du TLS.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.