Améliorer notre résolveur DNS en proposant DNS over TLS comme le fait Aquilenet ou La contre voie
https://atelier.aquilenet.fr/projects/dns-ouvert/wiki
Tu peux t’ajouter en éditant ce message wiki via le bouton 
en bas du message
@ljf
Le 13 mai a été proposé pour travailler sur la question.
Ca avait été mis en place, mais c’est à refaire car les résolveurs ont été réinstallé…
A programmer sur le prochain slash ?
Yep, je crois qu’il y a presque tout, sauf la génération Let’s Encrypt via le challenge DNS
des nouvelles là -dessus ? je configure mon nouveau IronFox (ford de Mull Browser), et il veut mettre du DNS over HTTPS par défaut
@ljf
Peut tu m’indiqué où ce situe l’accès à la vm DNS ? Je vais essayer de m’en charger pour ce WE au max
recursif.arn-fai.net et recursif-2.arn-fai.net
Il faut aussi ns0.arn-fai.net pour mettre en place le challenge ACME via nsupdate…
J’ai très certainement pas le bon port ssh 
EDIT : vu avec ced117
Config sur IronFox / Firefox :
Paramètres → Vie Privée et sécurité → DNS via HTTPS → Protection maximale → Personnalisé → https://recursif.arn-fai.net/dns-query
Config sur /e/OS :
Réseau et Internet → DNS privé → nom d’hôte du fournisseur DNS privé → n’accepte que recursif.arn-fai.net → Impossible d’accéder au serveur DNS privé → Laisser en automatique
Hello !
C’est en béta, notre petit serveur répond au DoH !
Pour la partie RFC, on respecte donc la RFC 8484 pour ce qui est du Doh, mais aussi du RFC9462 pour la découverte du DoH via une requête dns classique sur _dns.resolver.arpa en SVCB. (donc compatible avec la découverte auto du DoH par windows quand on configure manuellement le serveur DNS).
Comment on installe ça ?
En soit, c’est assez simple à mettre ne place.
Certificat SSL :
On utilisera certbot pour générer et renouveler notre certificat SSL :
apt install certbot -y
puis on génère le certificat SSL
certbot certonly -d recursif.arn-fai.net
Voila, votre certificat SSL est créer avec Let’s Encrypt.
Partie RFC8484 :
On installe doh-server du projet DNSCrypt
(https://github.com/DNSCrypt/doh-server)
On créer un service qui lui est dédiée (/etc/systemd/system/doh-server.service) :
[Unit]
Description=DNS-over-HTTPS Server (DNSCrypt)
After=network.target
[Service]
Type=simple
User=root
Group=root
ExecStart=/usr/local/bin/doh-server \
-host-name recusrif.arn-fai.net \
-listen-address 0.0.0.0:443 \
-cert /etc/letsencrypt/live/recursif.arn-fai.net/fullchain.pem \
-key /etc/letsencrypt/live/recursif.arn-fai.net/privkey.pem \
-upstream 127.0.0.1:53 \
-concurrency 32 \
-max-clients 1000
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
puis on l’active :
sudo systemctl daemon-reload
sudo systemctl enable --now doh-server
sudo systemctl status doh-server
Le serveur DoH est désormais fonctionnel.
Pour la partie discovery DoH (RFC 9462), il suffit de modifier l’unbound local pour lui faire répondre la réponse attendue :
nano /etc/unbound/unbound.conf
et ajouté ceci dans “server” :
local-zone: "_dns.resolver.arpa" redirect
local-data: '_dns.resolver.arpa. IN SVCB 1 recursif.arn-fai.net. ( alpn="h2" port=443 ipv4hint=89.234.141.66 key7="/dns-query{?dns}" )'
local-data: '_dns.resolver.arpa. IN NS ns0.arn-fai.net.'
Sauvegarder et relancé unbound et la partie discovery est configuré !
Re,
Le DoH ne répond pas, un bug survient après une journée de fonctionnement normal, faut que j’enquête sur ce problème.
(fort heureusement que la beta interne servent à ça).
Je me demande si c’est utile d’utiliser doh-server vu que unbound a un paramétrage fait pour faire du DoH ?
Un avis sur la question ?
Bonne remarque.
Si unbound sait le faire, autant le privilégier par rapport à doh-server.
Oui Unbound sait faire du DoH et du DoT. Si vous en avais déjà un vous pouvez rajouter ces quelques paramètres pour activer les fonctionnalités:
server:
interface: 0.0.0.0\@443
interface: 0.0.0.0\@853
tls-service-key: "path/to/privkey.pem"
tls-service-pem: "path/to/certificates-chain.pem"
tls-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305"
tls-ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
Il faut retirer le caratère « \ » avant le « @ » (Discourse le considère comme une adresse mail et cache le texte…).
Au sujet de DoT on a intérêt à déployer un serveur DNS spécifique ? Ou il n’y a pas de risque de dégradation du service de nos DNS actuels suite à cette mise-en-place ?
Pour moi il n’y a pas plus de risque à faire d DoT que du DoH. La différence entre tous les protocoles DNS (Do53, DoT, DoH, DoQ, DoC) ne change rien au message DNS c’est juste du transport.
Les configurations de sécurité DNS d’un point de vue fonctionnel s’appliqueront quelque soit le transport. Par contre, on peut mettre en balance les différences sur les transports, comme par exemple DoT et DoH sont plus consommateur de ressources car ils réposent sur TCP et TLS. Autrement dit, si une partie du trafic existant bascule du Do53 vers l’un des deux autres modes de transport des ressources supplémentaires seront consommées par le service.
je pensais plutôt à ce genre de risques #modèledemenace 
https://quad9.net/fr/news/blog/au-revoir-france/
Résumé : Quad9 est une fondation Suisse à but non lucratif qui fournit une résolveur DNS récursif neutre. Ils ont été astreints d’une amende de 1000€/jour dans le cas où ils ne bloqueraient pas des domaines (avant jugement). Ils ont été attaqués par BeIN via les tribunaux français. Cela fait suite à une affaire similaire où ils avaient été attaqués par Sony en Allemagne et là ils avaient gagné. C’est inquiétant car c’est un service qu’ARN propose a l’instar de plusieurs membres de la FFDN.
Leur conclusion :
Lutter contre le piratage en bloquant la résolution DNS récursive est inefficace. C’est une réponse disproportionnée, inadaptée et vaine, car les contenus sources demeurent pleinement accessibles pour réapparaître sous d’autres noms de domaine. Forcer Quad9 à se retirer nuit à la stratégie et à la souveraineté numériques de la France en matière de sécurité, de vie privée et d’intégrité des réseaux - compromettant les intérêts supérieurs de la nation au profit d’une victoire commerciale illusoire à court terme.
Nota : c’était le résolveur DNS privé éthique enregistré par défaut dans Librewolf, /e/OS, etc.
Je me demande comment la fondation QUAD9 qui est de droit suisse peut
être condamné en droit français ?
De plus, elle est suisse pourquoi elle se plierait Ă un jugement
français ?
Le problème réside dans la Convention de Lugano. La France et la Suisse (ainsi que l’Allemagne, l’Italie et d’autres pays, mais PAS les États-Unis) en sont signataires. En tant que traité intergouvernemental, elle prime sur le droit national. Ainsi, bien que ces attaques ne soient pas valables au regard du droit suisse, leurs auteurs peuvent réclamer des dommages-intérêts en Suisse.
https://www.sedlex.fr/wp-content/uploads/2014/06/convention-de-lugano.pdf
Le risque zéro n’existe pas.
Si l’on prend le problème d’un point de vue purement « technique », l’amende ne vient pas de nul part, ils ont reçu une « demande » pour mentir sur un certain nombre de domaine, ce qu’ils ont refusé de faire. L’amende vient de là , si ils s’étaient plié à la demande il n’y aurait pas eu de problème.
Maintenant d’un point de purement technique (et fonctionnel), comme je l’évoquais, DoT et DoH ne sont que des méthode de transport. Le blocage des domaines étant purement fonctionnel et ARN fournissant déjà un service de résolution DNS, le risque est déjà présent !!!
Maintenant, il faut rester pragmatique, Quad9 n’est pas un petit fournisseur comme ARN ou n’importe quel autre membre de la FFDN. En plusieurs années chez FDN je n’ai jamais vu passé de demande de blocage de site au niveau du résolveur DNS. Bien entendu, cela ne veut pas dire que cela n’arrivera jamais, mais le jour où cela arrive les choix seront les mêmes que pour Quad9:
Après, pour éviter un potentiel débat stérile, je suis entièrement d’accord avec Quad9 et personne ne peut dire « On sait pas comment ça marche… », y’a plein d’experts qui parle du fonctionnement du DNS à chaque fois qu’il y a un sujet légal en rapport que ce soit au niveau FR ou EU…