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

• 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