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:
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)
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.
rndc flushname name [view]
- 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
This will clear the cache, but it will not clear any names out of ADB, so may not be sufficient for some needs.
rndc flushtree name [view]
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
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 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 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
- Restart named (or flush cache completely using
- 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-2014 Internet Systems Consortium