Unter macOS 26 funktionieren benutzerdefinierte DNS-Einstellungen wie `.internal` nicht

 (gist.github.com/adamamyl)
2 Punkte von GN⁺ 2026-03-21 | 3 Kommentare | Auf WhatsApp teilen
  • Unter macOS 26.3.1 werden domainbasierte DNS-Einstellungen über /etc/resolver/ für nicht standardisierte TLDs außer Kraft gesetzt, wodurch bestehende lokale Entwicklungsumgebungen ausfallen
  • mDNSResponder verarbeitet Anfragen für benutzerdefinierte TLDs nur noch per mDNS und greift überhaupt nicht auf den angegebenen Unicast-Nameserver zu
  • .internal, .test, .home.arpa, .lan und praktisch alle TLDs, die nicht in der IANA-Root-Zone stehen, schlagen fehl, während Standarddomains (google.com usw.) normal funktionieren
  • Die einzige vorläufige Umgehungslösung ist ein manueller Eintrag in /etc/hosts, doch das ist in dynamischen Umgebungen (Docker, Kubernetes usw.) unrealistisch
  • Dadurch wird der von der macOS-Entwickler-Community seit langem genutzte gesamte lokale DNS-Workflow unterbrochen, mit weitreichenden Auswirkungen auf Entwicklertools und VPN-Integrationen

DNS-Regression in macOS 26

  • In macOS 26.3.1 (Darwin 25.3.0, Build 25D771280a) ist die Funktion für domainspezifische DNS-Konfiguration über /etc/resolver/ beschädigt

    • Eine Funktion, die bis macOS 25.x normal arbeitete, ist nach dem Update auf Version 26 ausgefallen
    • Obwohl sie in Apples offizieller Dokumentation (man 5 resolver) beschrieben ist, funktioniert sie bei nicht standardisierten TLDs nicht mehr

  • mDNSResponder fängt sämtliche Anfragen an benutzerdefinierte TLDs per mDNS ab und ignoriert den angegebenen Unicast-Nameserver

    • In allen Anwendungen, die getaddrinfo() verwenden (ping, curl, python3 socket), tritt der Fehler „Unknown host“ auf
    • Laut tcpdump wird überhaupt kein Traffic an den lokalen DNS-Resolver (127.0.0.1:53) gesendet
    • Beim Befehl dns-sd -G v4 erscheint die Antwort „No Such Record“ zusammen mit einer ungewöhnlich langen TTL (ca. 108.002 Sekunden)

Tests und Reproduktionsschritte

  • Mit Homebrew installiertes dnsmasq als lokalen DNS-Resolver konfigurieren und *.internal- oder *.example-private-Domains auf 127.0.0.1 abbilden

    • In der Datei /etc/resolver/example-private wird nameserver 127.0.0.1 gesetzt
    • Im Befehl scutil --dns wird der Resolver als korrekt registriert angezeigt
    • Beim Ausführen von ping probe.example-private erscheint jedoch der Fehler „Unknown host“

  • dig @127.0.0.1 und der host-Befehl liefern normale Antworten, aber alle Apps, die den System-Resolver nutzen, schlagen fehl

    • Das liegt daran, dass mDNSResponder die Anfragen intern blockiert und kein Unicast-DNS aufruft

Liste der betroffenen TLDs

TLD Status Anmerkung
.internal Fehler TLD für spezielle Nutzung aus einem IETF-Entwurf, funktionierte unter macOS 25 normal
.test Fehler Gemäß RFC 6761 §6.2 für lokale Tests reserviert
.home.arpa Fehler Gemäß RFC 8375 für Heimnetzwerke reserviert
.lan Fehler Inoffiziell, aber weit verbreitet
Sonstige nicht registrierte TLDs Fehler Alle TLDs, die nicht in der IANA-Root-Zone stehen
  • Bei .test sollte die Domain gemäß RFC 6761 eigentlich normal per DNS aufgelöst werden, doch macOS 26 behandelt sie ausschließlich über mDNS
  • Dagegen funktionieren bei der IANA registrierte Domains wie google.com oder bbc.co.uk weiterhin normal

Auswirkungen auf Entwicklungsumgebungen und Tools

  • Der gesamte DNS-Workflow für lokale Entwicklung wird unterbrochen

    • Entwickler, die die Kombination aus dnsmasq + /etc/resolver/ mit *.test, *.internal usw. nutzen
    • Die Container-Namensauflösung von Docker Desktop und ähnlichen Tools
    • Vagrant, Tailscale und VPN-Clients, die /etc/resolver/-Dateien automatisch erzeugen
    • Lokale Kubernetes-Entwicklungstools (minikube, kind, k3d usw.) für die Auflösung von *.cluster.local

  • Da das System in scutil --dns die Resolver-Konfiguration als korrekt anzeigt, ist das Problem für Nutzer schwer zu erkennen; zudem fehlen Logs oder Fehlermeldungen

Vorläufige Umgehungslösung und Grenzen

  • Die einzige funktionierende Methode ist das manuelle Hinzufügen von Domain-Mappings in /etc/hosts
    • Dadurch wird mDNSResponder vollständig umgangen
    • In Docker- oder dynamischen DNS-Umgebungen ist das jedoch unrealistisch, und bei jeder Änderung sind sudo-Rechte erforderlich

Technische Daten und Testumgebung

  • macOS 26.3.1 (Build 25D771280a), Apple Silicon (arm64)
  • dnsmasq wurde per Homebrew installiert und lauscht auf 127.0.0.1:53
  • Die Befehle dig und host liefern normale Antworten; ping, curl und python3 socket.getaddrinfo schlagen fehl
  • Relevante Dokumentation und Standards:
    • man 5 resolver — Dokumentation des /etc/resolver/-Mechanismus unter macOS
    • RFC 6761 — Definition spezieller Domains wie .test, .localhost, .invalid, .example
    • RFC 8375 — Definition der Domain home.arpa
    • IETF draft-ietf-dnsop-interneti-mdn — Entwurf zur speziellen Domain .internal

Verwandte Beiträge

3 Kommentare

 
lidar 2026-03-22

Deshalb kann ich Tailscale MagicDNS schon seit mehreren Tagen nicht nutzen..
 
minhoryang 2026-03-21

Ich hoffe, dass tailscale dieses Problem umgeht.
 
GN⁺ 2026-03-21
Hacker-News-Kommentare

  • Wegen solcher kleinen Reibungen (papercuts) habe ich macOS verlassen
    Einen Bugreport mit einem LLM zu schreiben, ist in Ordnung, wenn er anschließend geprüft wird; wenn aber offensichtliche Fehler wie „funktionierte unter macOS 25“ einfach stehen bleiben, leidet die Glaubwürdigkeit
    Wenn solche Reports zunehmen, werden Leute wegen des Prüfaufwands von KI geschriebene Reports wohl einfach wegwerfen

    • Die Nutzung von KI ohne sie klar zu kennzeichnen halte ich für absolut inakzeptabel
      KI unter meinem Namen schreiben zu lassen, wirkt wie die unhöfliche Botschaft, dass „meine Zeit wertvoller ist als deine“
      Wenn es unangenehm wäre, den KI-Einsatz öffentlich zuzugeben, sollte man allein deshalb den Zweck dieses Einsatzes noch einmal überdenken
    • Jedes OS hat solche kleinen Reibungen
      Über Linux oder Windows ließen sich genauso schmerzhafte Beispiele schreiben. Am Ende ist es eine Frage davon, „welches Gift man wählt“
    • Solche Probleme sind seit Jahrzehnten Teil von Apples Tradition
      Microsoft war bekannt dafür, Abwärtskompatibilität zu bewahren, Apple dagegen dafür, bestehende Funktionen ohne Zögern zu brechen
      Inzwischen ist Microsoft nicht mehr so konservativ wie früher, und Apple wirkt im Vergleich zu früher sogar stabiler
    • Apple ist ohnehin seit Langem als Firma bekannt, die Reports kaum liest, daher würde sich wohl selbst dann nichts ändern, wenn sie LLM-Reports wegwerfen würden
    • Ich hatte solche kleinen Reibungen auf jedem OS, aber unter Linux ist ein Rollback einfach
      Bei NixOS kann man im Boot-Menü einfach eine frühere Version wählen und das ganze System springt zurück
      Auf dem Laptop nutze ich macOS, aber die eigentliche Arbeit läuft meist in Linux-Containern

  • macOS 26 ist bisher die Version mit den meisten Kompatibilitätsbrüchen
    Mehrere absichtliche Änderungen haben die App-Entwicklung sehr erschwert
    Zum Beispiel kann die App Lunar den SDR-Nit-Wert nicht mehr frei setzen und dadurch ist die Helligkeitssteuerung blockiert,
    und die App YellowDot kann die Helligkeit der Mikrofonanzeige nicht mehr anpassen und ist dadurch unbrauchbar geworden
    Dazu kommen mehrere Bugs, etwa Maus-Event-Probleme bei fensterlosen Titelleisten, nicht anwendbare Gamma-Tabellen
    oder dass Apps wie Clop beim Ziehen den Pfad der Originaldatei verlieren

    • Es gibt das Gerücht, dass iOS 27 eine Stabilisierungs-Version im Stil von Snow Leopard werden soll
      Hoffentlich gilt das auch für macOS 27 (Quelle)
    • Als Hobby-Musikproduzent ist die Mikrofonanzeige für mich wirklich unnötig und störend
      Die Philosophie von macOS wirkt zu stur und einseitig, das ist frustrierend
    • Beim YellowDot-Problem ließe sich vielleicht mit einem LUT arbeiten, das die Farbe des Aufnahme-Punkts auf Schwarz mappt
      Ich nutze macOS selbst nicht, aber theoretisch scheint das möglich
    • Jetzt verstehe ich also, warum es auf dem M1 bis 1600 Nit problemlos ging, auf dem M5 aber nicht über 600 Nit hinaus
      Ich werde es wohl erst einmal einfach aufgeben müssen
    • Die Begrenzung der Helligkeit des Mikrofon-Punkts dient dem Schutz der Privatsphäre
      Malware soll den Zugriff auf Kamera und Mikrofon nicht verbergen können
      Außerdem könnte die Begrenzung der SDR-Helligkeit auch dazu dienen, Akkuprobleme kommender OLED-Displays schon im Voraus zu vermeiden

  • Ich warte immer noch auf den Tag, an dem Apple in Hardware und Software getrennt wird
    Apple Silicon will ich, ihr OS aber nicht
    Wenn ich meinen eigenen Kernel und meine eigenen Module nicht ausführen kann, dann ist das nicht meine Hardware
    Der Laptop daneben bootet mit coreboot, das zeigt meine Haltung ziemlich gut

    • Kann man auf dem Mac nicht auch seinen eigenen Kernel laufen lassen? Ist das Problem nicht eher die Treiberunterstützung?
    • macOS ist nicht perfekt, aber das Ganze als „schrecklich“ zu bezeichnen, ist meiner Meinung nach übertrieben
    • Ich mag macOS auch nicht nicht. Aber pauschal zu sagen, es sei „schrecklich“, ist wenig überzeugend

  • Für lokale Webentwicklung nutze ich *.localhost
    Alle modernen Browser lösen das automatisch zu 127.0.0.1 auf, daher braucht man weder DNS-Einstellungen noch Änderungen an der hosts-Datei
    Für Programme außerhalb des Browsers (python, wget usw.) gilt das allerdings nicht

    • Auch *.*.localhost wird unterstützt, sodass sich die Produktions-Domainstruktur lokal 1:1 nachbilden lässt
      ArchiveBox nutzt das, um pro Snapshot eine Domain-Isolation umzusetzen und so Sicherheitsrisiken zu verringern
    • Unter Tahoe funktioniert das auch in python oder wget problemlos
    • Ich habe es in Chrome getestet; in Safari dürfte es genauso funktionieren
    • Ich nutze diesen Ansatz ebenfalls. Nur ist .localhost leider etwas lang
      Früher habe ich .local verwendet, aber das führte oft zu Konflikten
    • Wir verwenden dev.our-root-domain.com, das im öffentlichen DNS auf 127.0.0.1 gemappt wird

  • Auf einer alten Yosemite-Maschine habe ich lange eine Konfiguration genutzt, die mehrere lokale TLDs bereitstellt
    Die /etc/resolver-Methode war schon um 2014 herum zur Abschaffung vorgesehen, jetzt scheint sie endgültig entfernt worden zu sein
    Stattdessen ist es der richtige Weg, die Konfiguration direkt mit scutil zu speichern

    • Aber scutil allein reicht nicht aus
      Einige macOS-Lookups laufen weiterhin über mDNSResponder und ignorieren oder überschreiben diese Einstellungen
      Deshalb ist es am Ende einfacher, gleich unbound oder dnsmasq zu verwenden

  • Ich nutze ebenfalls mehrere TLDs mit der Kombination aus /etc/resolver/X und dnsmasq und habe keine Probleme
    In der Konfigurationsdatei steht immer die Direktive domain
    Tatsächlich war diese Einstellung fast immer nötig
    Vielleicht lässt sich das Problem lösen, wenn man den domain-Eintrag ergänzt

  • Ich nutze hauptsächlich Linux, verstehe aber nicht ganz, warum Leute sagen, das Design von macOS sei schlecht
    Rein vom UX her wirkte macOS auf mich ziemlich ausgereift und fein abgestimmt
    Viele beliebte Gnome-Themes ahmen schließlich den Stil von macOS nach

    • Online gibt es einen Bias zugunsten der Lautesten, die unzufrieden sind
      Besonders auf HN ist das meiner Meinung nach so
    • Auch die Tahoe-Version war größtenteils in Ordnung
      Die Größenänderung an den Fensterecken ist zwar umständlich, aber insgesamt bin ich zufrieden
      Letztlich hat jedes OS Bugs
    • Wegen Apples Feature-Creep-Kultur verändert sich die UX oft unnötig von Mal zu Mal
      Die Benachrichtigungsdialoge sind dafür ein typisches Beispiel
    • Ich finde die Ästhetik von macOS ebenfalls gut
      Was mir fehlt, ist nur mehr Anpassbarkeit
      Dass man alten UIs wie Windows 98 nachtrauert, ist vielleicht einfach eine Generationenfrage
    • Insgesamt gefällt mir die UX
      Die Art, wie in den Vollbildmodus gewechselt wird, ist eigen, aber wenn man sich daran gewöhnt hat, ist sie angenehm
      Nur das Fehlen von Window-Tiling stört mich
      Trotzdem bevorzuge ich weiterhin Linux, auch wenn Suspend und Energieverwaltung dort seit acht Jahren problematisch sind

  • Früher hatte Apple unter iOS einmal selbst signierte Zertifikate blockiert, wodurch lokale HTTPS-Entwicklung fast unmöglich wurde
    Schwer nachvollziehbar, warum sie an so etwas herumgedreht haben

  • Ich mag macOS
    Es bringt zsh standardmäßig mit, und fast alles, was ich unter Linux gemacht habe, kann ich auch auf einem persönlichen Computer damit tun

  • *.localhost funktioniert standardmäßig
    Auch ohne dnsmasq lassen sich mehrere Hostnamen auf 127.0.0.1 legen

    • Aber wenn interne private IPs auf andere Adressen gemappt werden müssen, reicht dieser Ansatz nicht aus
    • Domains wie *.example-private sind nötig, um mehrere Geräte über private IPs zu unterscheiden
      Wenn man nur localhost braucht, kann man einfach 127.0.0.1 verwenden
      Ich persönlich nutze *mDNS mit .local, um die automatische DHCP-basierte Konfiguration auszuschöpfen