Sous macOS 26, les configurations DNS personnalisées comme `.internal` ne fonctionnent plus

 (gist.github.com/adamamyl)
2 points par GN⁺ 2026-03-21 | 3 commentaires | Partager sur WhatsApp
  • Sous macOS 26.3.1, les configurations DNS par domaine basées sur /etc/resolver/ sont neutralisées pour les TLD non standard, ce qui interrompt les environnements de développement locaux existants
  • mDNSResponder traite toutes les requêtes vers des TLD personnalisés uniquement via mDNS et ne consulte jamais les serveurs de noms unicast configurés
  • .internal, .test, .home.arpa, .lan et, plus largement, l’ensemble des TLD absents de la zone racine de l’IANA échouent, alors que les domaines standard (google.com, etc.) continuent de fonctionner
  • La seule solution temporaire consiste à enregistrer manuellement les entrées dans /etc/hosts, mais cela reste peu réaliste dans des environnements dynamiques (Docker, Kubernetes, etc.)
  • C’est tout le workflow DNS local utilisé de longue date par la communauté des développeurs macOS qui se retrouve cassé, avec un impact étendu sur les outils de développement et les intégrations VPN

Régression DNS apparue dans macOS 26

  • Sous macOS 26.3.1 (Darwin 25.3.0, Build 25D771280a), la fonctionnalité de configuration DNS par domaine via /etc/resolver/ est cassée

    • Elle fonctionnait normalement jusqu’à macOS 25.x, puis a cessé de marcher après la mise à jour vers la version 26
    • Bien qu’il s’agisse d’une fonctionnalité documentée officiellement par Apple (man 5 resolver), elle ne fonctionne plus avec les TLD non standard

  • mDNSResponder intercepte toutes les requêtes vers les TLD personnalisés via mDNS et ignore les serveurs de noms unicast configurés

    • Toutes les applications utilisant getaddrinfo() (ping, curl, python3 socket) renvoient une erreur « Unknown host »
    • D’après tcpdump, aucun trafic n’est émis vers le DNS local (127.0.0.1:53)
    • La commande dns-sd -G v4 affiche une réponse « No Such Record » avec un TTL anormalement long (environ 108 002 secondes)

Tests et procédure de reproduction

  • Configuration de dnsmasq installé via Homebrew comme résolveur DNS local, avec mappage des domaines *.internal ou *.example-private vers 127.0.0.1

    • Le fichier /etc/resolver/example-private contient nameserver 127.0.0.1
    • La commande scutil --dns montre bien que ce résolveur est enregistré
    • Pourtant, ping probe.example-private renvoie l’erreur « Unknown host »

  • dig @127.0.0.1 et la commande host répondent correctement, mais toutes les applications qui utilisent le résolveur système échouent

    • Cela montre que mDNSResponder bloque les requêtes en interne et n’appelle pas le DNS unicast

Liste des TLD affectés

TLD État Remarque
.internal Échec TLD à usage spécial d’un draft IETF, fonctionnait sous macOS 25
.test Échec Réservé aux tests locaux selon la RFC 6761 §6.2
.home.arpa Échec Réservé aux réseaux domestiques selon la RFC 8375
.lan Échec Non officiel mais largement utilisé
Autres TLD non enregistrés Échec Tous les TLD absents de la zone racine de l’IANA
  • Dans le cas de .test, alors qu’il devrait être résolu via le DNS normal conformément à la RFC 6761, macOS 26 le traite comme du mDNS uniquement
  • En revanche, les domaines enregistrés auprès de l’IANA comme google.com ou bbc.co.uk continuent de fonctionner normalement

Impact sur les environnements et outils de développement

  • L’ensemble du workflow DNS de développement local est cassé

    • Les développeurs qui utilisent dnsmasq + /etc/resolver/ avec *.test, *.internal, etc.
    • La résolution des noms de conteneurs dans Docker Desktop et autres outils similaires
    • Vagrant, Tailscale et les clients VPN qui génèrent automatiquement des fichiers /etc/resolver/
    • Les outils de développement local Kubernetes (minikube, kind, k3d, etc.) pour la résolution de *.cluster.local

  • Comme le système affiche une configuration de résolveur correcte dans scutil --dns, les utilisateurs ont du mal à identifier le problème et il n’y a ni logs ni messages d’erreur explicites

Solution temporaire et limites

  • La seule méthode qui fonctionne consiste à ajouter manuellement les correspondances de domaines dans /etc/hosts
    • Cette méthode contourne complètement mDNSResponder
    • Mais elle reste peu réaliste avec Docker ou dans des environnements DNS dynamiques, et nécessite des droits sudo à chaque modification

Caractéristiques techniques et environnement de validation

  • macOS 26.3.1 (Build 25D771280a), Apple Silicon (arm64)
  • dnsmasq est installé via Homebrew et écoute sur 127.0.0.1:53
  • Les commandes dig et host répondent correctement, tandis que ping, curl et python3 socket.getaddrinfo échouent
  • Documentation et standards associés :
    • man 5 resolver — documentation du mécanisme /etc/resolver/ sur macOS
    • RFC 6761 — définition des domaines à usage spécial comme .test, .localhost, .invalid, .example
    • RFC 8375 — définition du domaine home.arpa
    • IETF draft-ietf-dnsop-interneti-mdn — draft sur le domaine à usage spécial .internal

À lire aussi

3 commentaires

 
lidar 2026-03-22

À cause de ça, je ne peux plus utiliser Tailscale MagicDNS depuis plusieurs jours..
 
minhoryang 2026-03-21

J’espère que Tailscale contournera ce problème.
 
GN⁺ 2026-03-21
Réactions sur Hacker News

  • C’est à cause de ce genre de petites irritations (papercuts) que j’ai quitté macOS
    Rédiger un bug report avec un LLM, pourquoi pas si c’est relu, mais laisser passer tel quel une erreur évidente comme « ça marchait sur macOS 25 » fait perdre en crédibilité
    Si ce type de rapports se multiplie, j’ai l’impression que les gens finiront par jeter les rapports écrits par l’IA à cause de la charge de vérification

    • À mon avis, utiliser de l’IA sans le signaler explicitement est totalement inacceptable
      Faire écrire un texte par une IA à mon nom donne l’impression que mon temps vaut plus que le tien, ce qui est impoli
      Si déclarer publiquement l’usage de l’IA pose problème, alors il faut sans doute reconsidérer l’objectif de cet usage
    • Tous les OS ont ce genre de petits problèmes
      On peut écrire des exemples tout aussi pénibles sur Linux ou Windows. Au fond, c’est une question de « choisir son poison »
    • Ce genre de problème fait partie de la tradition Apple depuis des décennies
      Microsoft était connu pour préserver la rétrocompatibilité, Apple pour casser sans hésiter les fonctionnalités existantes
      Aujourd’hui, Microsoft semble moins conservateur qu’avant, et Apple paraît au contraire plus stable qu’autrefois
    • De toute façon, Apple a depuis longtemps la réputation d’être une entreprise qui ne lit pas vraiment les rapports, donc même s’ils jettent les rapports générés par LLM, ça ne changera sans doute pas grand-chose
    • J’ai connu ce genre de petits soucis sur tous les OS, mais sur Linux, revenir en arrière est facile
      Avec NixOS, il suffit de choisir la version précédente au démarrage pour restaurer tout le système
      J’utilise macOS sur mon portable, mais dans la pratique je travaille surtout dans des conteneurs Linux

  • macOS 26 est jusqu’ici la version la plus cassante côté compatibilité
    Plusieurs changements intentionnels ont rendu le développement d’apps très difficile
    Par exemple, l’app Lunar ne peut plus définir arbitrairement la valeur SDR en nits, ce qui bloque le contrôle de luminosité,
    et l’app YellowDot ne peut plus ajuster la luminosité de l’indicateur micro, ce qui la rend inutilisable
    Il y a aussi plusieurs bugs, comme les événements souris sur les fenêtres sans titre, l’impossibilité d’appliquer des tables gamma,
    ou la perte du chemin du fichier source lors d’un glisser-déposer dans des apps comme Clop

    • Une rumeur dit qu’iOS 27 sera une version de stabilisation façon Snow Leopard
      J’espère que macOS 27 suivra la même voie (source)
    • Comme amateur de production musicale, je trouve l’indicateur micro vraiment inutile et agaçant
      La philosophie de macOS est trop rigide et unilatérale, c’est frustrant
    • Pour le problème de YellowDot, je me demande s’il n’y aurait pas un contournement en utilisant une LUT pour mapper la couleur du point d’enregistrement en noir
      Je n’utilise pas macOS directement, mais en théorie ça semble possible
    • Donc c’est pour ça que ça montait bien jusqu’à 1600 nits sur M1, alors que sur M5 ça ne dépasse pas 600 nits
      Je vais sans doute laisser tomber pour le moment
    • La limitation de luminosité du point micro vise la protection de la vie privée
      L’idée est d’empêcher les malwares de masquer l’accès à la caméra ou au micro
      Et la limite sur la luminosité SDR pourrait aussi servir à anticiper les problèmes de batterie des futurs écrans OLED

  • J’attends toujours le jour où Apple séparera le matériel et le logiciel
    Je veux l’Apple Silicon, mais pas leur OS
    Si je ne peux pas exécuter mon propre noyau et mes propres modules, alors ce n’est pas mon matériel
    Le portable à côté démarre avec coreboot, et ça résume bien ma philosophie

    • On peut pourtant lancer son propre noyau sur Mac, non ? Le vrai problème, ce n’est pas plutôt le support des pilotes ?
    • macOS n’est pas parfait, mais le qualifier globalement d’« horrible » me paraît exagéré
    • Je n’ai pas non plus de haine contre macOS. Mais affirmer d’emblée que c’est « horrible » n’est pas très convaincant

  • Pour le développement web local, j’utilise *.localhost
    Tous les navigateurs modernes le résolvent automatiquement vers 127.0.0.1, donc pas besoin de configurer le DNS ni de modifier le fichier hosts
    En revanche, cela ne s’applique pas aux programmes hors navigateur (python, wget, etc.)

    • *.*.localhost est aussi pris en charge, ce qui permet désormais de reproduire en local la structure de domaine de production
      ArchiveBox utilise cette fonction pour isoler les domaines par snapshot et réduire les risques de sécurité
    • Sur Tahoe, ça fonctionne aussi très bien avec python ou wget
    • J’ai testé dans Chrome, et j’imagine que Safari se comporte pareil
    • J’utilise aussi cette méthode. Je trouve juste .localhost un peu long
      Avant, j’utilisais .local, mais il y avait trop de conflits
    • Chez nous, on utilise dev.our-root-domain.com, mappé vers 127.0.0.1 dans le DNS public

  • Sur une vieille machine Yosemite, j’utilisais depuis longtemps une configuration fournissant plusieurs TLD locaux
    La méthode /etc/resolver était déjà annoncée comme obsolète vers 2014, et elle semble cette fois avoir été complètement supprimée
    La voie correcte consiste désormais à enregistrer la configuration directement avec scutil

    • Mais scutil seul ne suffit pas
      Certaines résolutions sous macOS passent encore par mDNSResponder, qui ignore ou écrase ces réglages
      Au final, utiliser unbound ou dnsmasq reste plus simple

  • J’utilise moi aussi plusieurs TLD avec la combinaison /etc/resolver/X + dnsmasq, et je n’ai aucun problème
    J’inclus toujours la directive domain dans le fichier de configuration
    En pratique, cette option m’a presque toujours été nécessaire
    Ajouter l’entrée domain pourrait peut-être résoudre le problème

  • J’utilise surtout Linux, mais je comprends mal pourquoi certains disent que le design de macOS est mauvais
    Côté UX, macOS m’a toujours semblé assez soigné
    Même parmi les thèmes Gnome populaires, beaucoup imitent le style macOS

    • En ligne, il y a un biais de visibilité en faveur des plus mécontents
      J’ai l’impression que c’est encore plus vrai sur HN
    • La version Tahoe m’a semblé globalement correcte aussi
      Le redimensionnement par les coins de fenêtre est pénible, mais dans l’ensemble j’en suis satisfait
      Au final, tous les OS ont des bugs
    • La culture Apple du feature creep fait souvent évoluer l’UX de manière inutile d’une version à l’autre
      Les boîtes de dialogue de notification en sont un bon exemple
    • J’apprécie moi aussi l’esthétique de macOS
      C’est surtout le manque de personnalisation qui me gêne
      Regretter les anciennes interfaces comme Windows 98 relève peut-être aussi d’une question de génération
    • Globalement, l’UX me plaît
      La façon de passer en plein écran est particulière, mais une fois qu’on s’y habitue, c’est pratique
      En revanche, l’absence de tiling des fenêtres est gênante
      Malgré ça, je préfère toujours Linux, même si la mise en veille et la gestion de l’alimentation y posent problème depuis 8 ans

  • Apple avait déjà, à une époque, bloqué les certificats auto-signés sur iOS, ce qui rendait le développement HTTPS local presque impossible
    Difficile de comprendre pourquoi ils ont touché à ça

  • J’aime bien macOS
    zsh est fourni par défaut, et je peux faire sur mon ordinateur personnel presque tout ce que je faisais sous Linux

  • *.localhost fonctionne par défaut
    Même sans dnsmasq, on peut faire pointer plusieurs noms d’hôte vers 127.0.0.1

    • Mais dès qu’il faut mapper des IP privées internes vers d’autres adresses, cette méthode ne suffit plus
    • Des domaines comme *.example-private sont utiles pour distinguer plusieurs appareils via des IP privées
      Si c’est juste pour localhost, autant utiliser directement 127.0.0.1
      Personnellement, j’utilise plutôt *.local via mDNS pour profiter de la configuration automatique basée sur DHCP