Notes

• Navigateurs et DNS local : Firefox et Brave sur desktop, laptop et mobile
  • 1. Les problèmes rencontrés
    • Desktop
    • Laptop
    • Mobile
  • 2. Paramétrage DNS selon le navigateur et le matériel
  • 3. Sauvegarder la configuration hors du navigateur
    • Firefox : un fichier user.js
    • La CA locale
    • Brave
    • Signets, mots de passe, extensions
  • 4. Ordre de diagnostic retenu

Navigateurs et DNS local : Firefox et Brave sur desktop, laptop et mobile

Rapport du 2 novembre 2026

Ce rapport résume ce que j’ai rencontré en faisant fonctionner Firefox et Brave avec un DNS local (Technitium, domaine home.arpa), un DoH exposé par nginx (https://dns.home.arpa/dns-query, limité au LAN et au tailnet), et une page publique (portail.rnmkcy.eu) qui teste https://cwwk.home.arpa/health avant de rediriger vers le serveur local.

1. Les problèmes rencontrés

Desktop

Une page publique qui accède au réseau local déclenche une permission dans Firefox. Les versions récentes de Firefox demandent une autorisation quand un site public contacte une adresse du réseau local. Cette protection a d’abord touché les utilisateurs en protection renforcée « Stricte » (Firefox 149), puis un déploiement à tous est prévu à partir de Firefox 151. Si le popup est manqué ou refusé, le fetch du portail échoue en silence et la redirection ne se fait pas. Brave n’a pas montré ce comportement chez moi. Solutions :

• autoriser le site dans les informations de la page (Ctrl+I, Permissions), ou dans Paramètres, Vie privée et sécurité, Permissions ;
• ou ajouter le domaine dans la préférence network.lna.skip-domains (about:config).

Désactiver complètement la fonction (network.lna.enabled) est possible, mais trop large.

Une erreur DoH propre à un profil Firefox. Avec le DoH personnalisé en mode strict (network.trr.mode = 3), la page d’accueil se redirigeait correctement, mais https://lldap.home.arpa/ affichait « Un problème est survenu avec dns.home.arpa ». Pourtant dig donnait NOERROR en A, AAAA et HTTPS, en DNS classique comme en DoH (dig +https), depuis plusieurs machines. Un profil Firefox neuf, avec la même configuration, fonctionnait. La cause exacte dans l’ancien profil n’a pas été identifiée. Ce qu’il faut retenir :

• dig valide le serveur, pas le navigateur ;
• en cas de doute, tester dans un profil vierge (firefox -P) avant de chercher du côté du serveur ;
• reconstruire le profil proprement à partir d’un fichier de configuration (voir la partie 3) plutôt que de le bricoler.

Le certificat de la CA locale. Firefox utilise son propre magasin de certificats. Après un changement de profil ou une mise à jour, la CA home.arpa peut manquer. Deux solutions : l’importer dans le profil avec certutil, ou faire lire le magasin système par une politique Firefox (ImportEnterpriseRoots).

Laptop

Le DoH local n’est joignable que depuis le LAN et le tailnet. Hors de ces réseaux, une configuration en DoH strict ne résout plus rien. Firefox en mode 2 se rabat sur le DNS du système, mais Brave avec un DNS sécurisé personnalisé n’a pas de repli : plus aucun site ne se charge.

Mullvad et Tailscale ensemble. Avec Mullvad actif en permanence, le tailnet n’est joignable que si une règle nftables exclut 100.64.0.0/10 et fd7a:115c:a1e0::/48 du kill switch. Côté DNS, systemd-resolved porte la logique : le domaine home.arpa est dirigé vers Technitium (par le LAN ou par le split DNS du tailnet), le reste suit Mullvad. Un piège rencontré : avec /etc/resolv.conf en mode « uplink », un service systemd (agent de supervision) tentait de joindre un résolveur public directement et était bloqué ; le passer en mode stub (lien vers stub-resolv.conf) a réglé le problème.

Mobile

Ces points sont des constats généraux que j’ai à vérifier sur mes appareils :

• le domaine home.arpa n’est résolu que sur le LAN ou avec Tailscale actif, donc la redirection du portail ne peut pas fonctionner hors de ces réseaux ;
• la CA locale doit être installée sur l’appareil ; Firefox sur Android ne fait pas confiance aux CA ajoutées par l’utilisateur sans réglage supplémentaire, et Brave utilise le magasin Android ;
• le « DNS privé » d’Android attend un nom d’hôte (DoT), pas une URL DoH : l’URL https://dns.home.arpa/dns-query se configure dans le navigateur, pas dans les réglages système.

2. Paramétrage DNS selon le navigateur et le matériel

Principe : ne mettre un DoH personnalisé que là où le serveur est toujours joignable. Ailleurs, laisser le système (avec son split DNS) faire le travail.

Matériel	Firefox	Brave
PC de bureau (toujours sur le LAN)	DNS via HTTPS : Personnalisé https://dns.home.arpa/dns-query ; network.trr.mode à 3 possible, 2 pour garder un repli	Paramètres, Sécurité, DNS sécurisé : Personnalisé https://dns.home.arpa/dns-query
Laptop (LAN, tailnet ou ailleurs)	Désactivé (DNS système), ou DoH vers un fournisseur externe avec network.trr.excluded-domains = home.arpa ; si DoH local, mode 2	DNS du système, sans DNS sécurisé personnalisé
Mobile	Selon l’appareil : DNS du système, ou DoH personnalisé uniquement si le LAN ou Tailscale est toujours actif	Idem

Quelques points :

• dans ma version de Firefox, le menu propose seulement Par défaut, Personnalisé et Désactivé ; la valeur réelle du mode se lit dans network.trr.mode (2 = DoH avec repli, 3 = DoH strict) ;
• les noms en home.arpa doivent exister dans Technitium (Split Horizon pour renvoyer l’adresse LAN ou l’adresse Tailscale selon le client) ;
• la page de portail publique fonctionne uniquement si le navigateur peut résoudre cwwk.home.arpa et joindre /health ; c’est justement ce test qui sert de détecteur.

3. Sauvegarder la configuration hors du navigateur

L’objectif : pouvoir recréer un profil en quelques minutes, sans dépendre d’un profil existant.

Firefox : un fichier user.js

Firefox relit user.js à chaque démarrage et applique ces valeurs. Je le garde dans un dossier de configuration versionné, puis je le lie dans le profil :

// DNS via HTTPS vers Technitium
user_pref("network.trr.mode", 2);
user_pref("network.trr.uri", "https://dns.home.arpa/dns-query");
user_pref("network.trr.custom_uri", "https://dns.home.arpa/dns-query");

// Autoriser le portail à joindre le réseau local
user_pref("network.lna.skip-domains", "portail.rnmkcy.eu");

ln -s ~/dotfiles/firefox/user.js <dossier-du-profil>/user.js

Attention : une valeur écrite dans user.js écrase à chaque démarrage ce qui est changé dans l’interface pour la même préférence.

La CA locale

Le plus simple est une politique système (le chemin exact dépend de la distribution) :

{"policies": {"Certificates": {"ImportEnterpriseRoots": true}}}

En alternative, import dans le profil :

certutil -d sql:<dossier-du-profil> -A -t "C,," -n homearpaCA -i homearpaCA.crt

Brave

Brave ne possède pas d’équivalent de user.js. Deux voies : la synchronisation de Brave, et les politiques de type Chromium (fichiers JSON dans /etc/brave/policies/managed/, par exemple DnsOverHttpsMode et DnsOverHttpsTemplates). Je n’ai pas encore testé ces politiques sur ma version.

Signets, mots de passe, extensions

Ces données ne passent pas par user.js. Options :

• Firefox Sync, ou la synchronisation Brave ;
• export des signets en HTML ;
• copie des fichiers du profil, navigateur fermé : places.sqlite (signets et historique), logins.json avec key4.db (mots de passe, les deux ensemble), extensions.json et le dossier extensions/.

Pour Brave, les mots de passe sont chiffrés avec le trousseau du système : une copie brute du fichier n’est pas portable d’un poste à l’autre, la synchronisation ou un export est préférable.

Ces dossiers peuvent ensuite entrer dans la sauvegarde habituelle du poste (BorgBackup, par exemple), avec le navigateur fermé pendant la copie.

4. Ordre de diagnostic retenu

1. dig classique vers Technitium (A, AAAA, HTTPS) : les enregistrements sont-ils bons ?
2. dig +https vers dns.home.arpa : nginx et le DoH répondent-ils ?
3. Logs nginx pendant l’échec : quels codes HTTP sur /dns-query ?
4. Console du navigateur (F12) : erreur réseau, certificat, ou permission réseau local ?
5. Profil neuf : le problème vient-il du navigateur ou de son profil ?

Ce dernier test m’aurait fait gagner du temps si je l’avais fait en premier.