Episode #18 - Clearing The System DNS Lookup Cache

Paul Says:

In an effort to provide some quick command like tips (we lovingly call them "quickies") I wanted to share the OS X command to clear the local client's lookup cache:

# dscacheutil -flushcache

This is especially useful if you are doing some DNS changes and don't want the local client's cache to obscure your results.

Hal Says:

Repeat after me: "Client side caches are a lousy idea that can only lead to confusion and suffering. If your naming services are so unreliable that you can't live without a client cache, then it's time to get a new naming service."

The Name Services Caching Daemon ("nscd") is the client-side cache for Solaris and Linux systems. Generally I just turn it off on all of my machines, but if you leave it running you can flush the cache with a command like:

# nscd -i hosts

"passwd" and "group" are also valid arguments instead of "hosts", but it's the local DNS cache that generally gets you into the most trouble.

Ed Cleans Up:

Per Hal's request to repeat after him: "Client side caches are a lousy idea that can only lead to confusion and suffering. If your naming services are so unreliable that you can't live without a client cache, then it's time to get a new naming service."

So, if it's got confusion and suffering, you better believe its an integral component of the architecture of Windows. :)

In all seriousness, while Hal might not like it, I find the DNS cache in Windows hugely useful when conducting investigations, so I can see what has been recently resolved on the box. You can dump the DNS cache of a Windows machine with:

C:\> ipconfig /displaydns

The output will include all cached records, showing their remaining TTL in seconds. Run it every one second, and you can see the times decrement. If you happen to know the original TTL, you can get a feel for how long the record has been in the cache (realize, however, that the original TTL may not have been the value set by the authoritative server, because the machine may have gotten it from some intermediate server where it was cached for a while). Anyway, that's some useful information in an investigation, so you can piece together a timeline of when certain actions were taken.

But, the challenge at hand deals with clearing the DNS cache, which we can do with:

C:\> ipconfig /flushdns

My buddy Lara Corcoran refers to some things as "easy peasy". When I first heard her use this phrase, I found it annoying. But, it's addictive, and saying it reminds me of Lara, which always makes me smile.

Hal Puts in the Last Word:

Actually, Ed, instead of using the local DNS cache as a proxy to figure out what hosts the local machine has been communicating with recently, in Linux we can actually dump out the kernel's internal routing cache:

$ netstat -rCn
Kernel IP routing cache
Source          Destination     Gateway         Flags   MSS Window  irtt Iface
68.238.96.36    67.18.149.10    67.18.149.10    l         0 0          0 lo
212.118.133.101 67.18.149.10    67.18.149.10    l         0 0          0 lo
72.95.246.206   67.18.149.10    67.18.149.10    l         0 0          0 lo
69.158.249.37   67.18.149.10    67.18.149.10    l         0 0          0 lo
67.18.149.10    68.105.28.76    67.18.149.9            1500 0          0 eth0
67.18.149.10    200.149.55.136  67.18.149.9            1500 0          0 eth0
67.18.149.10    93.190.136.10   67.18.149.9            1500 0          0 eth0
67.18.149.10    62.253.181.25   67.18.149.9            1500 0          0 eth0
[...]

What you see are a bunch of host routes corresponding to the machines that this host has been communicating with recently. This is incredibly useful information in a forensic investigation.

Paul Chiming In One More Time:

To view the DNS cache table in OS X, you can use the following command:

# dscacheutil -cachedump -entries Host

Which will output something like:

DirectoryService Cache Overview:
  AAAA Queries  - Enabled
  Buckets Used  - 40
  Cache Size    - 10

  Entry count by category:
      Host  - 8
      User  - 2

Cache entries (ordered as stored in the cache):

    Category         Best Before         Last Access      Hits    Refs       TTL    Neg  DS Node
  ----------  ------------------  ------------------  --------  ------  --------  -----  ---------
        Host   03/30/09 16:39:19   03/30/09 16:39:12         3       4         9       
                   Key: h_name:twitter.com ipv4:1 ipv6:1
                   Key: h_name:twitter.com ipv6:1
                   Key: h_name:twitter.com ipv4:1

This allows you to see which hosts are in the cache when the command was run. I could not find a way to do the equivalent of a "netstat -C" in OS X.