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?
What's the problem with clearing the whole 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.
1 Like
Interesting!
I wouldn't mind conditionally forwarding a domain to it's authoritative NS..
I might have missed it, is there a UI or this a CLI task?
You have several choices.
You could add a custom line via Settings | All settings » Miscellaneous, or via CLI, e.g.:
sudo pihole-FTL --config misc.dnsmasq_lines '["server=/<your.domain>/<your.dns.ip>"]'
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.
Thanks for the input.
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:
crudely:
pi-hole --force-pull-domain-info domain.com
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).