Quoting Hendrik Boom (hendrik@???):

> Which brings us around full circle to the original question -- how to
> do a cache flush!

If the process that's caching is local to you, then restart the process
or (if supported) instruct it to throw away its state). If the process
doing caching isn't local to you (e.g., some outside recursive
nameserver you're using), then you're out of luck (except by ceasing to
use it).


In the (illustrative) case of the Unbound recursive nameserver
(illustrative of a process that caches DNS), the impatient-caveman way
of flushing its cache is: restart the Unbound daemon.

A less-crude and more-targeted way is:

# unbound-control flush_zone [name]
or
# unbound-control flush [RR]

There are additional flush+ directives, such as 'flush_negative', which
orders the Unbound daemon to flush all NXDOMAIN (not found), NODATA, and
SERVFAIL answers from its cache.

https://www.unbound.net/documentation/unbound-control.html

But just restarting the daemon is quick, sloppy, and effective. I've
never had to do it, because it's usually pretty easy to guess what badly
written piece of other software is doing inappropriately long or
incorrect caching. E.g., oh, Web browser screwing up, ergo restart Web
browser.

Note: One of the numerous reasons most ISP recursive nameservers suck
is that some operators are so cheap they deliberately -- just to save a
tiny amount of money on bandwidth costs -- configure their nameservers
to ignore published TTL (time to live) values on published DNS
data and cache it for artificially long periods. This of course
magnifies DNS problems' effects and make them difficult for a user to
fix -- except of course by eschewing use of said nameservice.