Why do sometimes I want to clear ONE DNS cache entry you ask?
Great question!
There are times we need to clear just one DNS cache entry, in Pi-hole, after we change a domain's name servers, or make a zone record change, at the registrar. Google and CF will report the change, but pi-hole will still serve a now outdated record even after restarting the pi-hole resolver.
I've seen where folks reported they've had to restart pi-hole three or four times, however with 130 users on the network with avg q/s of 30, restarting it three time successively three or four times a day for zone or domain NS changes is not good solution.
API call or command line option to remove one entry from pi-hole cache?
The cache will be empty upon Pi-hole restart, but Pi-hole's caching isn't your issue.
Public DNS servers will cache your domain until its TTL expires, and that's where Pi-hole and anyone else gets its replies from.
Commonly, you would handle this by reducing your domain's TTL before you change the record, wait for the former longer TTL to expire, and set it back to normal once the change has happened.
This way, public DNS servers would cache your older record for only a short time.
Alternatively or in addition, you could consider configuring Pi-hole to conditionally forward your domain to your domain's authoritative DNS servers.
where you substitute <your.domain> and <your.dns.ip> as required.
All settings is available in Expert mode only.
This will cover regular lookups for the domain.
Note that reverse lookups may still lag behind, i.e. the old IP may still resolve to your domain, while the new one may not yet resolve, or resolve to a different domain.
If you would be able to define an exact, stable subnet for your domain's IP, you could also consider to add a full Conditional Forwarding line via Settings | DNS, also in Expert mode. Refer to the on-screen description for details.
The corresponding CLI option is dns.revServers.
Note that either choice would affect your local network exclusively, and you'd still may have to flush Pi-hole's cache (edit: and potentially those of your network's clients as well) if you don't adjust your domain's TTL.
If you'd also require public users to get aware of your recent DNS changes, then adjusting your domain's TTL in the aforementioned manner would be advisable, especially if you'd normally use TTLs longer than just a few minutes.
Some domain registrars do not have the option to adjust the TTL for the SOA, but I'm sure there is magic done with a domains NS is updated at the registrar.
Had a domain this morning whom registered with GoDaddy, did a domain NS update.
on a Debian box:
dig a domain.com @8.8.8.8
result was google DNS was updated.
did the same on the debian box that uses the local network pi-hole for resolving:
dig a domain.com
and this gave the outdated info from either cache cache-optimizer
So, I am curious.
BIND (older, mind you) has a command to flush a domain:
rndc flushname domain.com
-> Granted, BIND and DNSmasq are two totally separate creatures.
that said: our pi-hole is on a Debian box.
Could there be a way to: force pi-hole to pull new domain info:
pihole-FTL/dnsmasq only allows to flush the entire cache.
But even if you could flush a single domain, that wouldn't affect client side DNS caches:
Most OSs employ a DNS cache and won't request resolution for a cached record again until the record's TTL has expired.
So e.g. a Windows client would continue to use the unexpired record until its TTL has expired.
As already mentioned, the most reliable way to tackle this would be to adjust your domain's TTL.
It's probably worth noting that dig and nslookup ignore OS DNS caches, sending DNS requests to the system configured DNS server (or to the one explicitly provided).
Yesterday we launched a website and just before that we updated the domain NS from Godaddy to Cloudflare. After we google dig to confirm the changes have propagated, Pi-hole had to be restarted four times to deliver the correct A and AAAA records.
we had to do a bunch of times to ensure I made the right changes:
nslookup domain.com 8.8.8.8
and for grins .... nslookup domain.com 1.1.1.1
18 hours later, pi-hole is delivering again, outdated records!
No zone records were changed. The name servers did not change.
The upstream on-site DNS was "rndc flushname domain.com several times to ensure pi-hole pulled/served the correct zone records.
Zone records were compared with Google dig webUI.
-> all upstreams NS were serving the correct records.
So again, how do I either remove one or two specific entries in the cache?
Or, better stated, how do I force the cache to update entries?
That's simply not how it works. Every time you restart pi-hole it will clear the DNS cache. If you are seeing the wrong DNS records after more than a day since the migration, you've made a mistake with the public DNS records, or there are issues within your DNS system. There are other factors of course, such as how many forwarders are in your DNS lookup chain, and record TTL (time-to-live).
DNS is hierarchical, pi-hole will not override DNS queries by itself. It only modifies the DNS entries that you tell it to.
No mistakes were made on the domain NS as the website host platform obtained SSL certs yesterday, minutes after google DNS and Cloudflare DNS reflected the domain NS and zone record changes.
looking into the logs this morning, the pi-hole was still serving inaccurate replies from cache.. after pi-hole was restarted, six times now.
For grins, I did a test.
I added espn.com to the local DNS as some random IP.
nslookup espn.com pi-hole
the reply it served was the random IP I gave it, plus actual A and AAAA records..
well anyway, I just found the issue as I was typing this, and looking a pi-hole.log.
I found the robot I was looking for!
Moving along.
This indicates that your Pi-hole's upstream DNS servers are responsible for your observation.
Since Pi-hole's cache isn't persistent, your observation would imply that Pi-hole's upstream DNS server's returned the DNS records that you consider as outdated.
Again, this would be expected, as your domain's TTL would encourage DNS resolvers to keep its DNS replies cached until that TTL expires.
In addition, your observation would also suggest that your domain's TTL is longer than 18 hours.
You should check your Pi-hole's upstreams.
Try changing them to the ones you've used to successfully confirm your authoritative changes have already propagated. That should at least ensure that Pi-hole will receive the expected upstream results.