DNS-Cache unter macOS löschen

Der DNS-Cache am Mac ist eine gute Sache, bis er im Weg steht. Normalerweise merkt sich das System die Antworten auf DNS-Anfragen für eine Weile, statt jedes Mal neu nachzufragen. Das spart bei jedem Seitenaufruf einen Umweg. Nach einem Server-Umzug will man aber genau das Gegenteil: die neue Adresse sofort sehen und nicht die alte, die noch im Cache liegt. Dann hilft ein Befehl im Terminal.

Das Terminal liegt unter Programme, Dienstprogramme, Terminal.

Der Befehl für aktuelle macOS-Versionen

Für macOS Tahoe (26), Sequoia (15), Sonoma (14), Ventura (13) und alles zurück bis El Capitan gilt derselbe Befehl. Beide Teile gehören zusammen in eine Zeile:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Nach der Eingabe fragt das System nach dem Administrator-Passwort. Bei der Eingabe passiert im Terminal sichtbar nichts, keine Sternchen, kein Cursor-Sprung. Das ist so gewollt, einfach tippen und Enter drücken.

Danach meldet der Befehl nichts zurück. Auch das ist richtig so: keine Ausgabe heißt, dass es funktioniert hat. Eine Erfolgsmeldung gibt es nicht.

Warum es zwei Befehle sein müssen

Viele Anleitungen im Netz nennen nur einen der beiden Teile, und das ist der häufigste Grund, warum das Löschen scheinbar nicht wirkt. Die beiden Befehle sprechen nämlich zwei verschiedene Dinge an.

dscacheutil -flushcache leert den Cache des Directory-Service. Dort landen Namensauflösungen aller Art, nicht nur DNS. Der eigentliche DNS-Cache liegt aber woanders.

killall -HUP mDNSResponder schickt dem Prozess mDNSResponder ein Signal, sich neu zu sortieren. Dieser Dienst ist am Mac der zentrale Resolver, er beantwortet die DNS-Anfragen aller Programme und hält dafür den Cache, um den es geht. Wer nur dscacheutil ausführt, lässt genau den Cache stehen, den er löschen wollte.

Dass der Dienst läuft, lässt sich nachsehen:

pgrep -l mDNSResponder

Auf einem aktuellen System antwortet das mit zwei Zeilen, mDNSResponder und mDNSResponderHelper. Der Helper ist nur ein Hilfsprozess für Rechte, angesprochen wird immer der erste.

Prüfen, ob es gewirkt hat

Hier steckt der zweite verbreitete Fehler. Die naheliegende Prüfung ist dig, und dig ist für diese Frage das falsche Werkzeug. Es umgeht den Systemresolver und fragt den Nameserver direkt. Was es anzeigt, sagt also nichts darüber aus, was der Mac gerade im Cache hat.

Wer wissen will, was das System selbst auflöst, fragt über denselben Weg wie jedes Programm:

dscacheutil -q host -a name siepker.com

Die Antwort nennt Name und IP-Adresse und kommt aus dem Systemresolver. Wenn dort nach dem Löschen die neue Adresse steht, ist die Sache erledigt.

dig bleibt trotzdem nützlich, nur für eine andere Frage: Damit lässt sich prüfen, was der zuständige Nameserver überhaupt ausliefert. Das ist die Gegenprobe, ob der neue Wert draußen schon angekommen ist.

dig +short siepker.com
dig @1.1.1.1 +short siepker.com

Kommen aus beiden Abfragen unterschiedliche Adressen, liegt es nicht am Mac.

Wenn trotzdem die alte Adresse kommt

Der Cache, der im Weg steht, sitzt in den meisten Fällen gar nicht auf dem eigenen Rechner. Zwischen Mac und autoritativem Nameserver liegen mehrere Stationen, die alle zwischenspeichern: der Router im Haus, der Resolver des Providers, dazu je nach Aufbau ein VPN oder ein eigener DNS-Dienst.

Wie sichtbar das ist, zeigt ein kleiner Test. Zweimal dieselbe Abfrage, drei Sekunden Pause dazwischen, und dabei auf die Zahl vor IN A geschaut:

dig siepker.com | grep -A1 "ANSWER SECTION"

siepker.com.		94	IN	A	176.9.37.246
siepker.com.		91	IN	A	176.9.37.246

Die 94 ist die verbleibende Gültigkeit in Sekunden, und sie zählt herunter. Der Wert kommt hier vom Router, der die Antwort noch knapp anderthalb Minuten aufbewahrt und in dieser Zeit keinen Nameserver mehr fragt. Am Mac kann man löschen, so oft man will, dieser Zähler läuft davon unbeeindruckt weiter. Wer es eilig hat, startet den Router neu oder trägt vorübergehend einen öffentlichen Resolver in den Netzwerkeinstellungen ein, etwa 1.1.1.1 von Cloudflare oder 8.8.8.8 von Google.

Welcher Resolver überhaupt zuständig ist, verrät:

scutil --dns | grep "nameserver\[0\]"

Steht dort die Adresse des eigenen Routers, ist klar, wer die Antwort zwischenspeichert.

Und schließlich gibt die TTL des Eintrags die Untergrenze vor. Sie wird beim Nameserver gesetzt, und niemand kann sie von außen abkürzen. Wer einen Umzug plant, setzt sie deshalb ein paar Tage vorher herunter. Bei Server-Umzügen für Kunden, wie sie in meiner Arbeit als Shopware Freelancer regelmäßig anfallen, ist das der Schritt, der über einen ruhigen oder einen unruhigen Umschalttag entscheidet.

Browser haben ihren eigenen Cache

Selbst wenn das System längst die neue Adresse kennt, kann der Browser noch bei der alten bleiben. Chrome und Firefox pflegen einen eigenen DNS-Cache, unabhängig vom Betriebssystem.

In Chrome führt der Weg über chrome://net-internals/#dns und dort den Knopf zum Leeren des Host-Cache. In Firefox liegt dieselbe Funktion unter about:networking#dns. Safari hat keinen eigenen DNS-Cache und verlässt sich auf den Systemresolver, ist mit dem Terminal-Befehl also schon erledigt.

Hält sich eine Seite danach immer noch hartnäckig, liegt es meist an einer offenen Verbindung, die der Browser weiterbenutzt, statt neu aufzubauen. Ein vollständiges Beenden des Programms mit Command und Q löst das, ein bloßes Schließen des Fensters nicht.

Die Befehle älterer Systeme

Apple hat den zuständigen Befehl über die Jahre mehrfach gewechselt. Eine eigene Support-Anleitung dazu gibt es weiterhin, sie ist aber, wie schon ihr Titel verrät, auf dem Stand von OS X stehen geblieben. Der Vollständigkeit halber, und weil auf manchem Gerät noch ein altes System läuft.

OS X El Capitan (10.11) und neuer

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

OS X Yosemite (10.10)

sudo discoveryutil mdnsflushcache
sudo discoveryutil udnsflushcaches

Auch hier reicht ein Befehl allein nicht. Der erste leert den Multicast-Cache, der zweite den Unicast-Cache, und für eine umgezogene Website ist der zweite der entscheidende. Das galt ohnehin nur bis 10.10.3, ab 10.10.4 gilt wieder der Befehl von El Capitan.

OS X Mavericks (10.9)

dscacheutil -flushcache; sudo killall -HUP mDNSResponder

OS X Lion (10.7) und Mountain Lion (10.8)

sudo killall -HUP mDNSResponder

Mac OS X Snow Leopard (10.6)

sudo dscacheutil -flushcache

Yosemite ist dabei der Sonderfall, der bis heute für falsche Anleitungen sorgt. Apple hatte mDNSResponder dort durch discoveryutil ersetzt, die Umstellung machte Ärger und wurde mit 10.10.4 zurückgenommen. Seitdem gilt wieder der Befehl von oben, und daran hat sich seither nichts geändert.

Aktualisiert am 15. August 2026: auf aktuelle macOS-Versionen gebracht, Prüfung und Fehlersuche ergänzt. Die Befehle wurden unter macOS 26.5.2 nachvollzogen.