Quoting Hendrik Boom (hend...@topoi.pooq.com): > 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng