4

I'm on OS X 10.9, according to support.apple.com I can flush the cache with

sudo killall -HUP mDNSResponder

Unfortunately this does not really refresh my DNS cache at all, also not like this:

dscacheutil -flushcache; sudo killall -HUP mDNSResponder

E.g.

$ dig www.example.com|grep CNAME
www.example.com.    83955   IN  CNAME   example.com.

If cache were cleared it would be showing a number close to 86400, 3600, 300 or 60 are the TTL values offered by my domain name provider).

If I add @dns-host to dig it works as expected:

$ dig @ns0.transip.net www.example.com|grep CNAME
www.example.com.    60  IN  CNAME   GITHUBACCOUNT.github.io.

I also tried the other commands on that page. In the meantime I work around this by ssh'ing onto one of my servers and check things there. But I'd like a proper way to really refresh all DNS cache on my Mac. How can I do that?

2
  • 3
    dig bypasses the OS resolver (and hence cache), so this isn't telling you anything about whether it's been flushed or not. What it is telling you about is caching at your DNS server, and you cannot flush that from the client. Feb 16, 2015 at 16:14
  • What about setting an entirely new DNS and then flushing? Sometimes that breaks things loose for me. Also, an upgrade to a newer OS might be wirth the effort if you haven’t done that, either.
    – bmike
    Mar 15, 2019 at 23:02

1 Answer 1

2

The effect you're seeing has absolutely nothing to do with the caches on your computer.

Instead what you're seeing is that your recursive DNS server (i.e. typically your ISPs DNS server or Google DNS or similar) has taken the original TTL value and subtracted the amount of time passed since it retrieved these records from the authoritative DNS server.

For example let's say that you own example.com and have an authoritative DNS server set up that when queried gives you that CNAME with a TTL of 86400. Then at some random point in time, your ISPs recursive DNS server is asked by someone else for www.example.com and retrieves those records. It caches that information.

Now you come along issuing the dig command without the @ parameter - this means that the request uses the server listed in /etc/resolv.conf, which is typically your ISPs recursive DNS server. Now you get the response back with TTL 83995, which means that 86400-83995=2405 seconds has passed since it originally retrieved those records.

Nowhere in this process is your standard, local macOS DNS cache involved, so mDNSResponder and dscacheutil is not going to change anything at all.

The reasoning behind this is that the authoritative DNS server has essentially stated that "this information is valid for 86400 seconds". The recursive DNS doesn't know if the authoritative DNS server has since been changed to give out new information, so it can only tell you that the information is now valid for a slightly smaller amount of time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .