Sommaire
Salut les moule·e·s,
Introduction
Ce journal est plus ou moins une réponse à chaque discussion où il est question de contournement de la "censure" du gouvernement demandant aux FAI principaux de ne plus résoudre certains noms. Il est notamment amplement inspiré d'une discussion que j'ai eu avec Stéphane Bortzmeyer lors d'un précédant Capitole du Libre où on a passé en revue les différentes manières de résoudre ses requêtes DNS. Je le remercie chaleureusement pour cet entretien ainsi que pour sa relecture du présent journal.
Le DNS, quelques rappels sur son fonctionnement
Rôle du DNS
Internet est architecturé autour du protocole TCP/IP, dans lequel les machines communiquent par l'intermédiaire de leur adresse IP (ce qu'on peut comparer à des humains qui ne communiqueraient que par leur numéro de téléphone). Le DNS (Domain Name System) permet d'associer un nom à ces adresses IP, ce qui a plusieurs avantages :
- ça permet de s'en souvenir plus facilement (www.linuxfr.org est plus facile à retenir que 213.36.253.103)
- ça offre une indirection (le jour où LinuxFR.org change d'hébergeur et donc d'adresse IP les utilisateurs n'auront pas à changer leurs marque-page)
- ça permet à un détenteur de nom de domaine de donner différentes informations selon les services offerts (signature, IP du serveur officiel en charge des emails… )
La hiérarchie dans les noms de domaines
Rappelons également le principe de la lecture de droite à gauche des noms de domaine : www.linuxfr.org est un nom complet de domaine (on dit "pleinement qualifié", FQDN en Anglais) dont le premier niveau (TLD en Anglais) est .org, le nom de domaine principal est linuxfr (qui techniquement est un sous-domaine de .org), et www un sous-domaine de linuxfr. En fin de comptes tout le monde est un sous-domaine du parent, puisque même .org est un sous-domaine de root. On a bien à faire à une organisation en arbre.
Pour connaître son adresse IP il faut donc s'adresser respectivement :
- aux serveurs racine du DNS pour leur demander qui est en charge (on dit plutôt "a autorité") du
.org - aux serveurs du
.orgon va leur demander a leur tour qui a autorité surlinuxfr.org - en enfin au serveur qui a autorité sur
linuxfr.orgon lui demandera quelle est l'adresse de la machine servant le sous-domainewww.
C'est l'heure du TP !
Une des commandes dédiées à l'exploration des DNS est dig. Vous pouvez taper dig www.linuxfr.org par exemple pour voir son IP:
;; ANSWER SECTION:
www.linuxfr.org. 900 IN CNAME prod.linuxfr.org.
prod.linuxfr.org. 900 IN CNAME oups.linuxfr.org.
oups.linuxfr.org. 900 IN A 213.36.253.103
www est un alias sur prod qui est un alias sur oups, mais au final on a bien notre adresse IP : 213.36.253.103
Tapez cette adresse dans votre butineur préféré, vous retomberez sur … oups !. Bon c'est normal, pour diverses raisons (certificats HTTPS, reverse-proxy…) on ne peut quasiment plus browser le web directement en IP. Mais c'est pas grave, vous avez compris le concept.
Super mais d'où sort cette adresse ? Qui nous l'a donnée ?
Demandons alors à dig d'enquêter pour nous : dig +trace +additional www.linuxfr.org. Là dig va remonter à la sources des serveurs DNS racine, et nous montrer la redescente :
- serveur DNS racine
- serveur .org
- serveur linuxfr.org
La sortie est verbeuse mais on peut trouver tout le cheminement via ces extraits.
On va donc attaquer les root servers, et pour ça il nous faut leur adresse IP. C'est facile, elles sont fixes, connues et présentes en dur dans le code dans tous les logiciels de résolution DNS.
. 86396 IN NS l.root-servers.net.
. 86396 IN NS m.root-servers.net.
. 86396 IN NS a.root-servers.net.
. 86396 IN NS b.root-servers.net.
. 86396 IN NS c.root-servers.net.
. 86396 IN NS d.root-servers.net.
. 86396 IN NS e.root-servers.net.
. 86396 IN NS f.root-servers.net.
. 86396 IN NS g.root-servers.net.
. 86396 IN NS h.root-servers.net.
. 86396 IN NS i.root-servers.net.
. 86396 IN NS j.root-servers.net.
. 86396 IN NS k.root-servers.net.
Ensuite on va demander à ces serveurs qui est en charge du .org
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
;; Received 809 bytes from 192.112.36.4#53(g.root-servers.net) in 32 ms
On voit au passage le nom et l'IP du root serveur utilisé (g dans mon cas, mais si vous refaîtes la manip par vous même il y a des chances que ce soit un autre qui soit utilisé dans votre cas). On peut leur demander qui a autorité sur linuxfr.org:
linuxfr.org. 3600 IN NS x.ns.joker.com.
linuxfr.org. 3600 IN NS y.ns.joker.com.
linuxfr.org. 3600 IN NS z.ns.joker.com.
;; Received 605 bytes from 199.249.112.1#53(a2.org.afilias-nst.info) in 27 ms
Et maintenant on peut demander le www:
www.linuxfr.org. 900 IN CNAME prod.linuxfr.org.
prod.linuxfr.org. 900 IN CNAME oups.linuxfr.org.
oups.linuxfr.org. 900 IN A 213.36.253.103
;; Received 98 bytes from 194.245.103.13#53(x.ns.joker.com) in 27 ms
Ça y est, on a bien l'IP qu'on cherche : 213.36.253.103. Le résultat est le même, sauf que là on a bien vu les étapes nécessaires à la résolution du DNS www.linuxfr.org
DNSSEC / DoT-DoH
La résolution DNS est un sujet technique assez complexe avec notamment, comme à peu près tout ce qui touche aux échanges sur Internet, des soucis d' authenticité et de fiabilité. Les technologie DNSSEC utilise la cryptographie à clé publiques et privées pour assurer l'authenticité de la réponse. De leur côté DoT et DoH sont deux technologies (respectivement basées sur TLS et HTTPS) qui assurent la confidentialité en chiffrant les échanges.
Mensonge
On parle souvent de DNS "menteur" et afin de reprendre cette expression dans ce journal, on va le définir simplement : un résolveur DNS est dit "menteur" quand il ne donne pas l'IP réelle associé au domaine suite à l'application d'une politique des mainteneurs. On peut citer par exemple l'envie de bloquer les publicités, de bloquer certaines catégories de sites. Dans ces cas, le resolveur donnera une réponse autre qu'un autre resolveur aurait donné simplement en suivant l'algorithme de résolution vu précédemment.
Conclusion
Pour résoudre une adresse DNS il nous faut utiliser ce qui s'appelle un résolveur récursif, c'est à dire un programme qui est capable de faire ce cheminement, tout en respectant la politique mise en place localement.
Résolveur et cache DNS
Utilités
La manipulation faite avec le TP pourrait très bien être embarquée dans n'importe quel outil ayant besoin du DNS (comme le browser web par exemple), mais il y aurait plusieurs inconvénients à ça :
- ce serait lent (on a vu qu'une seule requête prend plusieurs centaines de milli secondes)
- ce serait redondant (on passerait notre temps à re-résoudre encore et toujours les mêmes DNS)
- ce ne serait pas centralisé (par exemple il serait compliqué d'ajouter notre propre DNS "maison", ni d'appliquer une politique globale)
- on ne profiterait pas de la mise en cache commune à tous les utilisateurs. En effet le protocole DNS intègre la notion de TTL (Time To Live) qui explicite le temps qu'on peut retenir l'information sans avoir à la redemander. Avec un service centralisé, le premier utilisateur qui fait la reqête "offre" aux autres le temps de réponse, ainsi que quelquepart une charge moindre sur le réseau global.
Pour cela on centralise en général la résolution DNS d'un réseau via un logiciel spécialisé. Dans le monde du logiciel libre, on peut citer bind9 et unbound, knot resolver ou Power DNS Toute la question réside ensuite sur "Qui fait tourner ce logiciel ? Qui a la main dessus ?".
Les différentes possibilités techniques
Pour cela il existe différentes solutions qu'on utilise tous sans forcément en être au courant.
Le résolveur DNS de son FAI
C'est le cas le plus banal. À la connexion, votre FAI vous fourni l'adresse de son propre résolveur, il n'y a plus qu'à l'utiliser. Bien évidemment toutes les box font ça par défaut.
- Avantages : c'est fiable, performant, sans aucune maintenance à faire de notre côté
- Inconvénients : il n'y a pas ou peu de confidentialité, et surtout aucune maîtrise sur les politiques appliquées. Selon le FAI, il sera même sommé par l'État de mentir sur certains sites ("piratage", pédopornographie, harcèlement, terrorisme…)
Résolveur externe : services commerciaux
Une autre solution est d'utiliser un résolveur externe, payant ou pas. Les fameux 8.8.8.8 de Google ou 1.1.1.1 de CloudFlare en sont les exemples les plus connus.
- Avantages : toujours aucun entretien à faire, on utilise l'IP donnée et c'est tout. Ces serveurs sont en général très rapides et tout aussi fiables que ceux du FAI.
- Inconvénients : de la même manière que ceux du FAI, on n'a pas vraiment accès à la politique interne de ces résolveurs. Depuis peu ils obéissent aux injonctions du gouvernement français, en plus d'autre gouvernements (états-unien pour la plupart d'entre eux). De même la confidentialité n'est assurée en rien.
Résolveurs externes : services associatifs
Il existe des résolveurs externes maintenus par des associations tels que 80.67.169.12 et 80.67.169.40 qui sont les résolveur publics de la FDN.
Il existe également une liste de résolveurs sur les chatons.org.
- Avantages : toujours aussi facile à utiliser, ils assurent généralement une bien meilleure transparence sur la politique utilisée. Les personnes en charge sont joignables, on peut imaginer que les politiques appliquées sont votées etc. Idem pour la confidentialité, il est en général aisé de poser des questions, de savoir exactement ce qui est gardé etc. Par exemple les résolveurs de la FDN affichant qu'ils utilise DNSSEC et DoT-DoH, on sait que la confidentialité est maximale.
- Inconvénient : la performance et la fiabilité seront peut-être un peu en deça des services commerciaux, notamment à cause de moyens limités. De même, le fait qu'il y ait moins d'utilisateurs fera le cache sera moins fourni.
Résolveur interne
Dernière solution… se démerder tout seul ! Oui, c'est tout à fait possible, parfaitement autorisé. C'est le comportement par défaut de pfSense par exemple. Pi-Hole ne le fait pas par défaut mais propose une documentation pour ajouter unbound et donc profiter de la résolution récursive en interne.
De manière générale ça consistera à mettre unbound ou bind9 sur son réseau local et d'y faire pointer l'ensemble des clients.
- Avantage : on a enfin la main sur la politique. On peut "mentir" ou pas selon ses propres critères (contrôle parental, politique interne entreprise…). Il peut également avoir un certain plaisir à résoudre soi-même ses requêts en dépendant le moins possible de services externes. Ce n'est pas non plus la panacée, le chaînage DNSSEC entre les différents serveur DNS n'étant jamais garanti, ou le FAI voyant de toutes façons passer les échanges non chiffrés (absence de DoT-DoH), mais aussi de toutes façons l'accès à l'IP finale.
- Inconvénients : niveau performances et fiabilité on est sûrement dans les pires dispositions. Cela dit je le fais personnellement depuis des années via l'utilisation de pfSense et je n'ai pas souvenir de soucis particuliers. À l'échelle domestique le temps de résolution n'est pas vraiment un soucis, et la fiabilité n'est ni plus ni moins que celle de votre fournisseur d'électricité ou de votre FAI.
Résolveur interne + résolveur externe
Enfin il existe une solution intermédiaire entre les deux dernières propositions : un résolveur local (dont on contrôle la politique) mais qui fait suivre les questions dont il n'a pas la réponse à un résolveur public (sympa de préférence). On profite alors de sa mémoire et de ses performances, tout en gardant le contrôle local. Tous les logiciels libres de résolveurs DNS savent faire cela.
Conclusion
La résolution DNS est un sujet technique autant que politique. Les différents façons de résoudre une requête DNS offrent toute la palette de saveurs entre fiabilité, performance, confidentialités et maîtrise de la politique appliquée.
Pour l'hygiène de sa vie numérique (ainsi que celle des siens, la moule LinuxFR.org étant souvent en charge du maintient du réseau local domestique) il est important de connaître, et éventuellement de choisir sa propre politique de résolution des noms, et donc de choisir la technique adaptée.
Et toi ? Tu résous comment tes requêtes DNS ?
# et moi
Posté par jtremesay (site web personnel) . Évalué à 4 (+2/-0).
J'utilise DNS4EU (opérateur commercial européen) + systemd-resolved pour la mise en cache locale.
[^] # Re: et moi
Posté par lann . Évalué à 1 (+0/-0).
Pour moi, Adguard sur mon serveur à la maison
[^] # Re: et moi
Posté par Calaad . Évalué à 5 (+5/-0).
Je crains d'être un fossile : Bind9 sur un serveur local.
[^] # Re: et moi
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 8 (+7/-1).
C'est même pas écrit en Rust, ce truc.
[^] # Re: et moi
Posté par Calaad . Évalué à 9 (+9/-0). Dernière modification le 19 octobre 2026 à 20:25.
On se demande comment ça peut fonctionner.
[^] # Re: et moi
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
C'est assez fou de voir qu'il existe encore des projets qui ne sont pas écrits en Rust en fait.
Je n’ai aucun avis sur systemd
[^] # Re: et moi
Posté par Colin Pitrat (site web personnel) . Évalué à 5 (+4/-1).
Rust c'est dépassé, j'ai vibe-codé mon propre langage en demandant qu'il soit meilleur que Rust sur tous les tableaux. Je l'ai appelé rouille.
Mais même rouille est déjà dépassé car je travaille sur la version 2 qui va faire tout pareil mais en Très mieux, du coup je vais l'appeler t-rouille.
[^] # Re: et moi
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0).
Tu passes encore par un langage de programmation ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et moi
Posté par octane . Évalué à 5 (+4/-1).
J'ai vibe-codé un prompteur qui va appeler un agent qui va développer un nouveau langage de programmation permettant d'écrire un resolver lorsqu'il y a besoin de faire une resolution de nom.
Je réfléchis à utiliser une IA dans le cloud qui irait améliorer mon prompteur.
[^] # Re: et moi
Posté par Benoit Sibaud (site web personnel) . Évalué à 4 (+2/-1). Dernière modification le 20 octobre 2026 à 14:57.
J'ai vibe-codé les spécs d'une imprimante 3D qui me sortira l'ADN du type qui fera l'invention du langage qui servira à mettre en place le concept de réseau computationnel quantique qui donnera la réponse à la question de l'Univers et la vie. Et l'IA me juste tient compagnie en attendant qu'il ait fini.
[^] # Re: et moi
Posté par jtremesay (site web personnel) . Évalué à 4 (+5/-3).
grave. Imagine, t'es en 2026 et tu n'utilises pas un projet rust vibecodé par une trans catgirl en chausettes de programmeur. Non mais allo quoi.
[^] # Re: et moi
Posté par dr191 . Évalué à 1 (+0/-0).
Vous n'etes pas le seul. La meme chose ici.
# DoH système vers Adguard
Posté par Dafyd . Évalué à 3 (+3/-1).
DoH configuré directement sur le système qui pointe vers les DNS publics d'Adguard.
J'échappe à la censure du FAI + je bloque une bonne partie des pubs au passage.
# et le DHCP dans tout ça ?
Posté par guiv42 . Évalué à 3 (+2/-0).
Merci pour ce journal très intéressant.
De mon côté j'utilise le résolveur de mon FAI parce que… euh non, cherchez pas y'a pas de bonne raison. Et ça ne me satisfait pas du tout, ce journal explique très bien pourquoi.
Je suis très intéressé par la configuration "Résolveur interne + résolveur externe", si quelqu'un a des ressources à partager sur ce sujet (tuto, etc) je serais très intéressé. J'ai un vieux raspberry pi 2 qui pourrait héberger des trucs.
Une raison pour laquelle je n'ai pas encore franchi le pas, c'est que le lien avec le DHCP me fait un peu peur (problème de compétence) :
ping imprimantec'est plus facile queping 192.168.1.jsaispluspour tester si l'imprimante est alluméeEn clair, il faudrait que je bascule et le DNS et le DHCP sur mon raspberry pi, à qui je filerais alors une IP fixe.
Et je me connais. Basculer tout ça, et que ça marche du premier coup… ? Nan nan, ça j'sais pas faire. Et une fois que ça se sera planté, est-ce que je saurais revenir en arrière ? (et puis ça va râler copieusement autour de moi !)
[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 7 (+4/-0). Dernière modification le 20 octobre 2026 à 10:15.
Alors on va être simple et direct : le simple fait que tu parles DHCP montre que t'as compris 80% du merdier :)
Tu peux expérimenter
dnsmasqpar exemple qui fait les deux à la fois (et je parie ma selle et mes bottes que c'est ce qui tourne dans ta box) donc tu pourras toujours pingerimprimante.Pour l'expérimentation, encore une fois, vu les problèmes que tu vois venir à l'avance, c'est que tu as tout compris :) Oui, tu vas casser Internet dans ta maison le temps de tout mettre en branle.
Mais tu peux ruser. Perso je tenterais de préparer un dnsmasq compatible avec la box.
Par exemple si ta box file du DHCP entre 192.168.1.50 et 19.168.1.150, tu dis à dnsmasq de donner entre 192.168.1.200 et 192.168.1.250.
Comme ça tu peux couper le DHCP de la box, allumer le tien, et forcer un client de test à se reconnecter. Il est censé avoir accès à Internet. Et pendant ce temps, les autres machines sur le réseau n'y verront que du feu car elles sont déjà leur propre réglages (hormis le pas de chance où elles redemandent la bail DHCP pendant ton expérimentation).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par guiv42 . Évalué à 2 (+1/-0).
super, je vais donc lire la doc de dnsmasq. Merci bcp !
[^] # Re: et le DHCP dans tout ça ?
Posté par jch . Évalué à 3 (+2/-0).
Je confirme, dnsmasq simplifie énormément les choses quand on a besoin d'un resolver récursif, même quand on n'a pas besoin d'un serveur DHCP. (Il peut aussi se comporter comme un serveur autoritatif, mais il n'est pas vraiment fait pour ça.)
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 4 (+2/-0). Dernière modification le 20 octobre 2026 à 11:18.
La plupart (toutes?) des box permettent de renseigner les adresses IP des résolveurs DNS. Tu peux très bien y mettre une adresse locale : celle de ton Raspberry par exemple sur lequel tu auras installé Bind ou Ubound.
Exemple, une Freebox avec cette configuration :
- en IPv4 : 192.168.100.100 (résolveur cache récursif Bind9 local); 86.54.11.100 (DNS4EU sans filtrage)
- en IPv6 : les mêmes avec leurs adresses IPv6
Le DHCP est assuré uniquement par la Freebox. C'est plus simple et on évite les conflits DHCP ;)
Une commande
resolvectlsur une machine du réseau permet de voir quels sont les résolveurs utilisés.[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 3 (+0/-0).
Oui mais il me semble que si il fait ça, il ne résoudra pas par leur petit nom les machines arrivées sur le réseau. Style mon ordi perso qui se connecte et qui s'appelle
coyoteet tout le monde peutping coyoteimmédiatement.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 5 (+3/-0). Dernière modification le 20 octobre 2026 à 11:36.
Sans doute, même si a priori un résolveur récursif et un résolveur faisant autorité pour les noms des machines du réseau local doivent être des choses indépendantes (on peut cependant très bien configurer Bind pour qu'il fasse les deux à la fois).
Personnellement j'utilise mDNS (avahi) pour résoudre les noms de machines qui proposent des service sur le TLD .local : rpi.local; imprimante.local; squeezebox-radio.local, etc. mais cela demande quelques réglages supplémentaires.
[^] # Re: et le DHCP dans tout ça ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
La Freebox, oui mais, à ma connaissance, la Livebox d'Orange et sans doute d'autres ne permettent pas de changer de résolveur (« c'est pour la sécuritay ! »).
[^] # Re: et le DHCP dans tout ça ?
Posté par aiolos . Évalué à 3 (+1/-0).
Pire, cette saloperie relance de temps en temps le serveur DHCP embarqué, j'imagine à la suite de certaines mises à jour…
[^] # Re: et le DHCP dans tout ça ?
Posté par guiv42 . Évalué à 2 (+1/-0).
Merci pour toutes vos réponses.
Je dois reconnaître que la solution
dnsmasqest assez séduisante. Certes, déplacer DNS et DHCP c'est peut-être un peu casse-gueule (pour moi au moins), mais ça aurait l'avantage d'avoir une bonne indépendance vis-à-vis de la box, sur laquelle je n'ai aucun contrôle. Celle-là ne resterait que pour faire passerelle avec internet, ben en fait c'est pour ça que je la paie. Le reste, si c'est chez moi c'est mieux.[^] # Re: et le DHCP dans tout ça ?
Posté par tkr (Mastodon) . Évalué à 5 (+3/-0).
Celle ci, franchement : je l'encadre.
Combien de fois voit-on des geeks se plaindre du DNS non personnalisable sur les box de presque tous les opérateurs? y'a eu un sujet sur lafibre.info
Pour moi, à l'exception de free qui le rend encore possible (pour le moment), aucun autre FAI ne prend définitivement le risque de personnaliser le DNS, l'avenir sera à la personnalisation réduite contre un meilleur débit. Les fonctionnalités satellites s'éteignent lentement, l'idée est de garder le client "consommateur" et non "administrateur", et de tout rebasculer vers la nomad-digital-applis, sans ordi.
Donc à part free, j'ai vu z-é-r-o opérateur, dont la box fournie, permet de personnaliser ses DNS. "c'est une fonctionnalité de pro, pas pour la michu !" répondront les vendeurs en boutique. Tenez le vous pour dit.
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 3 (+1/-0).
Effectivement c'était une connerie. :)
Bouygues permet de rajouter des adresses de résolveurs mais de modifier ceux par défaut et apparemment Orange ne le permet tout simplement pas.
Donc seul un des trois opérateurs grand public le permet pour l'instant.
[^] # Re: et le DHCP dans tout ça ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 21 octobre 2026 à 17:10.
Mon fournisseur me permet de changer plein de paramètres dont le résolveur dns mais le mieux c'est d'acheter et configurer son propre routeur fibre plutôt que celui du fournisseur qui est une backdoor.
[^] # Re: et le DHCP dans tout ça ?
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
ah, t'as déjà enterré SFR o_O (je ne dis pas que tu n'as pas raison :D)
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 3 (+1/-0).
La vente de SFR et son démantèlement entre les trois autres opérateurs est actée depuis un moment. Il ne manque que l'accord formel de l'Arcep.
https://www.arcep.fr/mes-demarches-et-services/consommateurs/fiches-pratiques/rachat-de-sfr-quel-impact-sur-mon-abonnement-mobile-ou-internet-si-je-suis-client-de-sfr.html
[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 21 octobre 2026 à 07:36.
En tous cas j'ai une liveboxpro et un abonnement pro, et je peux modifier le DNS. J'ai le mode "automatique" (je suppose ceux de Orange) et le mode "manuel" où je préciser le DNS primaire et secondaire.
Si d'autres sont chez Orange "amateur" (ça m'a toujours énervé cette appellation "pro", ça sous-entend quoi pour les autres ?) vous pouvez dire si c'est possible aussi ? C'est un peu caché, faut aller dans Paramètres (roue crantée), Réseau, DHCP (et pas DNS).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par flavien75 . Évalué à 3 (+2/-0). Dernière modification le 21 octobre 2026 à 09:30.
Chez Orange "grand public", j'ai justement jeté un œil hier soir aux onglets DHCP et DNS, il n'y a rien pour les paramétrer:
Il me semble qu'en contrat "pro" on pouvait demander une IP fixe, ce qui n'est pas possible sur une offre "grand public".
Les vrais naviguent en -42
[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 4 (+1/-0).
Oui et on peut toujours, c'est d'ailleurs ce que j'ai. Au passage pour l'anecdote, les IP fixes sont dans un range très différent des IP variables. Donc quand on demande une IP fixe, on nous la change (en théorie une dernière fois). Faut pas se faire avoir :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par Psychofox (Mastodon) . Évalué à -1 (+0/-4).
Le problème de l'ip fixe c'est qu'après tu dois être 24x7 sur un VPN et tu passes ta vie à résoudre des captchas.
[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Hein ?
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par Psychofox (Mastodon) . Évalué à -1 (+0/-4).
Ben si tu as un gramme d'intérêt pour ta vie privée, tu commences par éviter de naviguer tout le temps avec la même ip.
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 6 (+4/-0). Dernière modification le 21 octobre 2026 à 20:49.
Personne ne se base sur l'adresse IP pour identifier et pister les internautes. C'est inutile et ce n'est pas une donnée fiable : IP dynamiques, CGNAT, VPN servant de proxy, etc.
https://fingerprint.com/
et la partie libre : https://github.com/fingerprintjs/fingerprintjs/
[^] # Re: et le DHCP dans tout ça ?
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Moi aussi je peux être condescendant : Si tu as un gramme de connaissances techniques…
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: et le DHCP dans tout ça ?
Posté par Voltairine . Évalué à 4 (+2/-0).
C'est quoi cette manie ? Il n'y a rien de vraiment condescendant dans son commentaire. Rappel de la définition :
# unbound
Posté par flavien75 . Évalué à 3 (+2/-0).
Merci pour l'article, ça ne fait pas de mal de revoir ces concepts (je me demandais d'ailleurs si unbound avait hard-codé la liste des serveurs de .org, .net et autres, en oubliant les serveurs racines).
Pour ma part, ça fait un mois je suis passé sur un résolveur interne (unbound). J'envisage d'installer un Pi-Hole avec unbound pour gérer pouvoir aussi filtrer ce qui va sur les autres appareils.
Est-ce que tu sais comment sont priorisés les DNS sous Linux ?
Plus clairement, dans la config de la carte réseau, on peut indiquer plusieurs serveurs DNS. Est-ce que ça marcherait d'indiquer l'adresse du Pi-Hole en premier puis celui du fournisseur d'accès en second au cas où le premier est hors-service ?
Ce qui m'intéresse étant d'éviter les censures et les pubs.
Les vrais naviguent en -42
[^] # Re: unbound
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Alors j'ai jamais trop joué à ça, mais il me semble que oui, ça sert exactement à ça. Dans tous les cas on demande toujours au premier et si ça répond, on touche pas au second.
Par contre, si ton Pi-Hole est en rade, ça va devenir pénible d'attendre un timeout sur chaque requête pour passer au second… Cela dit je crois que systemd (resolvectl plus précisément) quand il passe au second il y reste (justement pour éviter les timeouts insupportables). Mais ça veut aussi dire que si tu remets ton Pi-Hole à flot, il ne le détectera pas et restera sur le second. Faut le rebooter en gros.
Bref, tu vois pourquoi un serveur DNS se doit avant tout d'être disponible :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: unbound
Posté par flavien75 . Évalué à 2 (+1/-0).
Merci,
En bref ça vaut le coup de faire des essais.
Les vrais naviguent en -42
[^] # Re: unbound
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Non (et ce serait une drôle d'idée, ce ne sont pas ces TLD qui sont menacés par une éventuelle redélégation hostile).
Résolveurs (il faut éviter de dire « serveur DNS » tout court, les résolveurs et les serveurs faisant autorité sont deux bêtes très différentes).
Non. Le timeout de la glibc est beaucoup trop long. Il faudrait plutôt un relais local, avec répartition des requêtes (par exemple dnsdist) qui est justement conçu pour cela.
[^] # Re: unbound
Posté par Voltairine . Évalué à 4 (+2/-0).
Un lien vers ton article « RFC 8499: DNS Terminology » est toujours utile ;-)
[^] # Re: unbound
Posté par flavien75 . Évalué à 1 (+0/-0).
En effet, d'ailleurs cela aurait compliqué l'ajout de nouveaux TLD au cous du temps.
Il faudra que je me penche là-dessus, parce qu'à ce niveau je ne maitrise plus rien.
Dommage, vu que mon but était d'assurer un fallback automatique au cas où ma machine tombe en panne.
Les vrais naviguent en -42
# config perso
Posté par tkr (Mastodon) . Évalué à 10 (+9/-0).
truc simple :
routeur openwrt,
dns personnalisé pointant sur dnsforge (clean)
fonctionne niquel depuis 1+ an.
je suis incapable de retourner à des DNS neutres depuis..
[^] # Re: config perso
Posté par gUI (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 21 octobre 2026 à 07:47.
Ah tiens c'est vrai que j'ai pas parlé de ce type de résolveur : externe avec une politique filtrante sur certains sujets. Merci du rappel, je vais le rajouter (le temps de trouver comment/où).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.