De DNS-cache op de Mac legen
Om de DNS-cache op een Mac te legen, open je Terminal via Apps › Hulpprogramma's en voer je dit uit:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Voer het inlogwachtwoord van je Mac in wanneer daarom wordt gevraagd. Er wordt niets afgedrukt als het lukt. De Mac herstarten leegt de cache ook: het artikel van Apple over de DNS-cache zegt dat je je Mac kunt herstarten om de gecachte informatie bij te werken.
Dat artikel van Apple is gearchiveerd en wordt niet meer bijgewerkt. De nieuwste vermelding, voor OS X Yosemite 10.10.4 en later, is sudo killall -HUP mDNSResponder; dscacheutil -flushcache is het commando dat het noemt voor Snow Leopard. Apple heeft geen nieuwere versie gepubliceerd, dus de regel hierboven voert beide uit: het killall-deel is wat Apple noemt voor huidige releases, en dscacheutil -flushcache leegt de Directory Service-cache volgens de handleiding (man dscacheutil), die ook zegt het alleen in extreme gevallen te gebruiken. Een verouderd DNS-antwoord is zo'n geval. Mole voor Mac leegt DNS niet; dit is een taak voor Terminal.
Wat de DNS-cache is
Wanneer een app verbinding maakt met example.com, moet macOS die naam eerst omzetten in een IP-adres. Op een Mac loopt die opzoeking via mDNSResponder. De handleiding (man mDNSResponder) beschrijft het als de daemon die DNS-query's uitvoert namens andere processen en een cache van de antwoorden bijhoudt.
De cache bespaart een rondgang bij elke herhaalde opzoeking. Elk antwoord wordt bewaard voor de tijd die de DNS-records van het domein toestaan, en daarna opnieuw opgehaald. Meestal werkt dat zonder dat iemand het merkt. Het gaat mis wanneer het gecachte antwoord verouderd is voordat het verloopt: een site is naar een nieuwe server verhuisd, je hebt DNS-servers gewijzigd, of een opzoeking is één keer mislukt en die mislukking wordt nog hergebruikt.
-HUP in killall -HUP mDNSResponder kiest welk signaal killall stuurt; zonder die vlag stuurt killall TERM (man killall). Apple noemt de HUP-vorm als de manier om de DNS-cache te resetten, dus laat de vlag niet weg en vervang hem niet door -9.
Wanneer DNS legen helpt
| Situatie | Waarom legen helpt |
|---|---|
| Een website of server is verhuisd en je Mac bereikt nog het oude adres | Het gecachte antwoord is nog niet verlopen |
| Je hebt de DNS-servers gewijzigd in de netwerkinstellingen | Oude antwoorden van de vorige servers zitten nog in de cache |
Je hebt /etc/hosts bewerkt en de wijziging wordt genegeerd |
De handleiding van hosts zegt dat het bestand wordt gelezen door mDNSResponder, dat het eerdere antwoord nog kan vasthouden |
| Een site kon een minuut geleden niet worden omgezet en faalt nog steeds, terwijl andere apparaten hem wel bereiken | Een mislukte opzoeking kan gecachet zijn |
Wanneer het niet helpt
Legen wist alleen de eigen resolvercache van de Mac. Verschillende veelvoorkomende opstellingen maken het irrelevant:
- Proxy. Als verkeer via een HTTP- of SOCKS-proxy gaat, zet de proxy namen vaak zelf om. Controleer met
scutil --proxy, dat de huidige systeemproxyconfiguratie rapporteert. - VPN. Een VPN kan eigen DNS-servers installeren of alleen sommige domeinen daarheen sturen.
scutil --dnstoont elke resolver die in gebruik is; aanvullende resolvers die een domein noemen, worden alleen voor dat domein gebruikt. Als een werkdomein faalt, is de DNS van de VPN de plek om te kijken. - De eigen cache van de browser. Browsers kunnen hun eigen kortstondige DNS-resultaten bewaren en open verbindingen hergebruiken. Stop de browser na het legen helemaal en open hem opnieuw, in plaats van alleen het tabblad te herladen.
- Caches stroomopwaarts. Je router en je DNS-provider cachen antwoorden ook. De Mac legen kan hen niet dwingen eerder een nieuw record op te halen.
- De site is echt down, of geblokkeerd op je netwerk. Als andere apparaten op een ander netwerk ook falen, is DNS op je Mac niet de oorzaak.
Als pagina's traag zijn in plaats van falen, is DNS-caching zelden de bottleneck. Wifi hapert op de Mac en Welke app gebruikt mijn netwerk behandelen waarschijnlijkere oorzaken.
Controleer wat je Mac echt omzet
Gebruik de systeemresolver om het antwoord te zien dat je apps krijgen:
dscacheutil -q host -a name example.com
De handleiding van dscacheutil zegt dat -q een query uitvoert via de standaardaanroepen, en gecachte resultaten teruggeeft of live gegevens ophaalt.
Vraag daarna rechtstreeks aan een DNS-server:
dig example.com
dig gaat niet via de resolver van macOS. De handleiding zegt dat het de servers gebruikt die in /etc/resolv.conf staan, en dat bestand op macOS draagt een mededeling dat het niet wordt geraadpleegd voor de DNS-omzetting die de meeste processen op het systeem gebruiken. Als dig het nieuwe adres teruggeeft en dscacheutil het oude, is de cache van de Mac of de resolverconfiguratie het verschil, en legen zou dat moeten oplossen. Als beide het oude adres teruggeven, is het record stroomopwaarts nog niet veranderd.
Om te zien welke DNS-servers de Mac gebruikt:
scutil --dns
De servers die je met de hand hebt ingesteld, staan in Systeeminstellingen › Netwerk: selecteer een netwerkdienst, klik op Details en daarna op DNS (Apple).
Controleer /etc/hosts voordat je de cache de schuld geeft
/etc/hosts overschrijft DNS voor elke naam die erin staat. Ontwikkeltools, advertentieblokkers en oude tutorials voegen daar soms regels toe en laten ze staan. Om het te lezen:
cat /etc/hosts
Een normaal bestand heeft maar een paar regels voor localhost en commentaar dat met # begint. Als je het domein ziet dat zich misdraagt, is die regel waarom het zo wordt omgezet. Bewerk alleen die regel, met een editor die via sudo draait, bewaar een kopie van het origineel, en leeg daarna de cache. Verwijder de localhost-regels niet.
Controleer het resultaat
- Voer het commando om de cache te legen uit.
- Voer
dscacheutil -q host -a name example.comopnieuw uit met het probleemdomein en controleer het adres. - Stop de browser of app die het probleem had en open hem opnieuw.
- Als het nog steeds faalt, vergelijk je met
dig,scutil --dnsenscutil --proxyom te zien welke laag antwoordt.
Wat je beter niet doet
- Leeg DNS niet op een schema of als snelheidstruc. Een warme cache maakt opzoekingen sneller, en een lege maakt de volgende paar trager.
- Verwijder
/etc/hostsniet en wijzig de rechten niet. - Wissel DNS-servers niet op een werk- of school-Mac die een VPN of beheerprofiel gebruikt zonder te overleggen met wie het beheert; interne namen kunnen dan niet meer worden omgezet.
- Wijzig proxy- of VPN-instellingen niet om "DNS te testen". Zoek eerst uit welke laag antwoordt.
Veelgestelde vragen
Hoe leeg ik de DNS-cache op een Mac?
Voer sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder uit in Terminal en voer je wachtwoord in. De Mac herstarten leegt de cache ook.
Wat is het commando om DNS te legen op huidig macOS?
Het gearchiveerde artikel van Apple noemt sudo killall -HUP mDNSResponder voor OS X 10.10.4 en later, en Apple heeft geen nieuwer artikel gepubliceerd. Eerst ook sudo dscacheutil -flushcache uitvoeren is gebruikelijk; het wist alleen gecachte gegevens.
Wist DNS legen op een Mac de cache van de browser?
Nee. Het wist alleen de resolvercache van macOS. Stop de browser en open hem opnieuw, zodat hij zijn eigen DNS-resultaten of open verbindingen niet hergebruikt.
Waarom gaat een site na het legen nog naar het oude adres?
Controleer /etc/hosts, een proxy of VPN, en of dig het nieuwe adres toont. Als het DNS-record stroomopwaarts nog niet is veranderd, kan lokaal legen niet helpen.
Kan Mole de DNS-cache legen?
Nee. Mole voor Mac kan de DNS-cache niet legen; voer het Terminal-commando hierboven uit of herstart de Mac.