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: 29327 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:  http://www.dns-co.com/services/consulting/


© 2001-2015 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, 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.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu