Knowledge Base ISC Main Website Ask a Question/Contact ISC
How do I flush or delete incorrect records from my recursive server cache?
Author: Cathy Almond Reference Number: AA-01002 Views: 7511 Created: 2013-06-20 17:15 Last Updated: 2013-06-20 21:24 0 Rating/ Voters

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 BIND9 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.
Bad Cache is not cleared by rndc flushtree

Bad Cache is where DNSSEC-validation failures are held.  Currently, 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.

If you are unsure how to secure your name services, ISC offers training and consulting services in those areas via our commercial subsidiary DNSco:

© 2001-2014 Internet Systems Consortium

  • Please help us to improve the content of our knowledge base by letting us know how we can improve this article or by submitting suggestions for other articles you'd like to see created. Information on how to obtain further help on our products or services can be found on our main website.' If you have a technical question or problem on which you'd like help, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu