Stéphane Bortzmeyer a écrit 645 commentaires

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.

DNS-over-HTTPS est très cool mais :

1) Aucun client DNS ne sait l'utiliser donc ce n'est pas une alternative à des systèmes présentés dans la dépêche. Ça n'a aujourd'hui d'intérêt que pour un client Javascript, ou bien pour ceux qui utilisent leur script shell avec curl et jq.

2) Il y avait bien d'autres de ces « DNS looking glasses » avant celui de Google.

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).

« la géolocalisation va aussi loin qu'elle le peut » Euh, non. Je ne comprends pas à quelle partie de la politique de vie privée cela fait référence.

Le problème, c'est aussi que ce n'est pas du DNS : il n'existe pas de client qui envoie les requêtes sur HTTPS et interprètent le JSON de sortie.

Parce que des DNS-sur-HTTPS en JSON, il y en avait bien avant Google, par exemple le mien en https://dns.bortzmeyer.org/

Parmi les différences avec Cisco OpenDNS et Google Public DNS :

• Quad9 est géré par une organisation sans but lucratif, PCH,
• organisation que je connais (c'est le point « spécial copinage »),
• Quad9 s'engage à ne pas enregistrer les adresses IP des clients (oui, je sais, c'est impossible à vérifier, cf. le point précédent)
• Quad9 a DNS-sur-TLS (ce qui est très important car, quand on utilise Google Public DNS ou bien les résolveurs DNS publics de FDN, le problème n'est pas uniquement la politique de Google ou de FDN, c'est aussi « est-ce que je parle vraiment à Google ou FDN ? » et « qui d'autre que Google ou FDN peut écouter le trafic ? » Il existe .

Sauf erreur, quand Quad9 censure, il renvoie NXDOMAIN (No Such Domain = ce domaine n'existe pas). Donc, pas de HTTP et de JSON :-)

Je n'ai pas testé, il me faudrait un nom de domaine méchant. Quelqu'un a ça sous la main ?

Ça ne marche pas si on utilise des trucs comme Network Manager, qui réécrivent le /etc/resolv.conf. (Je ne parle même pas de systemd.)

Un bon article en anglais, avec quelques détails techniques.

Et la config' Unbound :

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

Et la question posée à 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

Et le résultat, en demandant à Stubby :

% 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

Bon, je ne sais pas ce que j'avais fait et en quoi c'est maintenant différent mais la config Stubby passe :

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"

Si les autres périphériques sont éteints, ils n'ont pas besoin de résolveur Et, s'ils sont allumés, il y a des chances qu'ils consomment plus d'électricité que le routeur OpenWRT portant le résolveur.

Alors, attention, il ne vaut mieux pas parler de "serveur DNS" tout court car ça mélange deux bêtes assez différentes, les résolveurs et les serveurs faisant autorité. Quad9 est un résolveur. Et, oui, on peut parfaitement avoir son propre résolveur et, non, cela ne ferait pas trop de trafic sur les serveurs racine, qui en voient bien d'autres (notamment en raison des dDoS). Un bon endroit pour mettre un tel résolveur est dans la box/routeur/CPE, qui est en général allumé en permanence (le Turris Omnia a un tel résolveur, par défaut).

Maintenant, du point de vue vie privée, ce n'est pas idéal car le FAI voit les requêtes DNS vers les serveurs faisant autorité, qui sont en clair. Bien sûr, c'est moins pratique pour lui de les surveiller que si elles sont envoyées à un résolveur qu'il gère, mais ce n'est quand même pas parfait.

Marrant, on en a discuté lundi à la réunion du groupe de travail DNSOP à l'IETF. Pour l'instant, ce n'est pas possible, le DNS n'offre que trop peu de codes de retour (SERVFAIL sert à un peu tout). Ce projet, adopté par le groupe de travail, permettra d'en avoir davantage. Donc, oui, après le 100 pour "DNSSEC Bogus", on pourrait avoir le 451.

Promotion, c'est un peu exagéré, je crois avoir bien indiqué les avantages et inconvénients.

Oui, c'est ce que j'ai tenté (comme pour les premières configs) mais ça échoue dans mon cas.

FUD

Mauvaise méthode. Pour comprendre pourquoi ça ne marche pas (c'est expliqué dans mon article mais je répète ici), prenons le cas d'un francophone qui parle anglais. Si le site Web a un texte original en français, traduit en anglais, il faudrait envoyer le français. Si le site Web a un texte original en englais, mal traduit en français, il faut envoyer l'anglais. Si le site Web a un texte original en chinois, mal traduit en anglais, tant pis, il faut quand même envoyer l'anglais.

Des règles naïves comme « toujours suivre Accept-Language: » ou bien « toujours envoyer la version originale » ne marchent pas. C'est pour cela que peu de sites Web se fient à Accept-Language.

Laisser un choix manuel à l'utilisateur.

Mauvaise idée que d'utiliser la langue du navigateur http://www.bortzmeyer.org/web-et-version-originale.html

Il faut le dire clairement : ce logiciel ne sert à rien. Il est donc absolument indispensable.

Et pour ceux qui, comme moi, trouvent ce terme de « design » fourre-tout et mal défini, une bonne explication :-)

Le compte-rendu de la table ronde (entre designers) qui a eu lieu à ce sujet.

Tiens, ça m'a motivé pour écrire pourquoi les résolveurs publics ne sont pas une bonne idée.