How do I flush or delete incorrect records from my recursive server cache?
  • Updated on 06 Sep 2018
  • 2 minutes to read
  • Contributors
  • Print
  • Share
  • Dark
    Light

How do I flush or delete incorrect records from my recursive server cache?

  • Print
  • Share
  • Dark
    Light

Sometimes a recursive server may have incorrect records in its cache.  These may be as a result of an error made by a zone administrator, or as a result of a deliberately engineered cache poisoning attack.

For cache problems relating to DNSSEC validation, please refer to DNSSEC validation and BIND 9 cache.

Other issues will be simpler to address.  You may be able to identify the faulty records, by dumping and inspecting cache:

rndc dumpdb -all

The resulting file may be of significant size.  By default it is named_dump.db in the default data files directory for your installation.

Or you may be able to identify which records are incorrect by querying your server directly.

dig +norec <ip address of nameserver> <name> <type>

Typically, problems relate to incorrect NS records (for example, if the transition of a domain to new nameservers has not been carried out correctly: How to change the nameservers for a zone? ). Similar issues can arise when the addresses (A and AAAA records) for a nameserver or server are updated, or mail services are moved to a new server.

Mitigating the problem

If you know the records that are wrong, then you may be able to delete them from cache without restarting your nameserver or flushing the entire cache:

  • Flush the cache for a specific name (available since BIND 9.3)

    rndc flushname name [view]
    

    This flushes entries matching the specific name both from the main cache and from the Address Database (ADB) where named tracks the status of authoritative servers that it has queried.

    • Use the name of a domain if there are problems with the NS or MX records associated with it.
    • Use the server name, if there are problems with the addresses associated with that server name (for example a nameserver, a webserver or a mailserver).
  • Flush the cache for a specific name as well as all records below that name

    rndc flushtree name [view]
    

    This will clear the cache, but it will not clear any names out of ADB, so may not be sufficient for some needs.

If you are not sure where the problem lies, or there are too many records to delete them individually, then you might prefer to:

  • Flush the entire named cache

    rndc flush
    

    The advantage of this is that there is no need to know which entries need to be cleared - they all will be. The disadvantage is that clearing the entire cache will cause a subsequent flood of iterative queries in order to repopulate the cache with frequently-accessed records and server information. Flushing the entire cache clears all resource records (RRs), bad cache (for DNSSEC-validation failures) and also the ADB.

  • Restart the named daemon.

In versions 9.3 through 9.9 Bad Cache is not cleared by rndc flushtree
Bad Cache is where DNSSEC-validation failures are held. In these versions, the only way to clear validation failures before they expire normally is to flush the entire cache, identify the name and apply rndc flushname or to restart named.

If you suspect that your cache has been poisoned

If you suspect that the contents in the cache of your recursive server are incorrect due to a deliberate cache-poisoning attack, then we recommend that you:

  • Dump your cache (for future investigation) using

    rndc dumpdb
    
  • Restart named (or flush cache completely using

    rndc flush
    
  • Take steps to prevent a repeat attack.

Was this article helpful?