Stéphane Bortzmeyer a écrit 655 commentaires

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

C'est marrant qu'on ne se préoccupe de sécurité que quand il faut trouver une excuse pour ne pas déployer IPv6. Normalement, le réseau local de M. Michu est plein de machines Windows vérolées et de caméras membres de Mirai et tout à coup, on dit « ah non, pas IPv6, ça permettrait de pirater M. Michu »

Scanner ? En IPv6 ? Bon courage http://www.bortzmeyer.org/7707.html

Bouygues Telecom (je suis client) a IPv6 sur le réseau mobile et ça juste marche (je peux pinguer mon téléphone depuis mon PC, trop bien).

Je suis chez Bouygues Telecom et ça marche très bien en IPv6 (il faut changer manuellement l'APN, ce n'est pas par défaut).

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.

Dans ce cas, c'est une très bonne chose que DNS-LG ne le gère pas (c'est très dangereux pour la vie privée).

J'avoue ne pas comprendre « supporte l'utilisation de subnet client arbitraire ».

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.