A domain name may be updated to point to a new public IP address, yet computers on a local network can continue resolving it to the old address. When this happens, applications such as SSH clients may appear to be caching the previous IP internally.
In many cases, however, the application is not responsible at all.
The real cause may be a stale DNS record cached by the local router.
This article walks through a practical troubleshooting scenario involving Linux clients, an OpenWrt router, dnsmasq, and a domain whose public IP address recently changed.
The Scenario
Assume a domain previously pointed to:
203.0.113.10
The DNS record was then updated to:
198.51.100.25
After the change, an SSH client continued attempting connections to the old IP.
At first glance, the most obvious explanation seemed to be:
The SSH client must have cached the old DNS result.
That assumption turned out to be incorrect.
The stale record was actually being returned by the network’s local DNS resolver.
Step 1: Check Normal DNS Resolution
The first test on the Linux workstation was:
dig +short example.net
The result was still the old address:
203.0.113.10
The system resolver returned the same value:
getent ahosts example.net
Example output:
203.0.113.10 STREAM example.net
203.0.113.10 DGRAM
203.0.113.10 RAW
This is already an important clue.
If both dig and getent return the old IP, the problem is probably not confined to one application.
The operating system itself is receiving the old DNS answer.
Step 2: Compare Against Public DNS Resolvers
The next step is to bypass the default DNS resolver and query several public DNS services directly:
dig @1.1.1.1 example.net A +short
dig @8.8.8.8 example.net A +short
dig @9.9.9.9 example.net A +short
Suppose all three return:
198.51.100.25
This immediately narrows down the problem.
Public DNS resolvers already know the new address, while the local machine still receives the old one.
The DNS update itself is therefore probably correct.
The stale response must be somewhere between the workstation and the public DNS infrastructure.
Step 3: Check the Authoritative DNS Record
For additional confirmation, the authoritative DNS chain can be inspected with:
dig +trace example.net A
Near the end of the trace, the authoritative nameserver should return something similar to:
example.net. 3600 IN A 198.51.100.25
At this point, three things are established:
- The authoritative DNS server has the new address.
- Public DNS resolvers return the new address.
- The local workstation still receives the old address.
The DNS provider is therefore not the source of the problem.
Step 4: Identify the Local DNS Resolver
The dig +trace output, /etc/resolv.conf, or network configuration can reveal which DNS server the workstation normally uses.
For example:
192.168.1.1
In many home or small-office networks, this address belongs to the router.
With OpenWrt, DNS requests from LAN clients are commonly handled by dnsmasq.
The effective resolution path may therefore look like this:
Application
↓
Linux resolver
↓
OpenWrt router
↓
dnsmasq cache
↓
Upstream DNS
↓
Authoritative DNS
If dnsmasq still holds the previous A record, every LAN client using the router as its DNS server may receive the stale IP.
Why the Application Looked Guilty
The SSH client appeared to be connecting to an old address, which made application-level caching seem plausible.
But the client was simply doing something ordinary:
SSH client asks system:
"What IP belongs to example.net?"
The system asks the router.
The router answers:
203.0.113.10
The SSH client then connects to that address.
From the user’s perspective, it looks as though the SSH client remembers the old IP.
In reality, it is following the DNS answer it receives.
This distinction is important because clearing application data, deleting SSH hosts, or reinstalling the client would accomplish nothing.
Step 5: Clear the OpenWrt DNS Cache
On an OpenWrt router using dnsmasq, restarting the service is a straightforward way to discard its in-memory DNS cache:
/etc/init.d/dnsmasq restart
Afterward, test from the workstation again:
dig +short example.net
The expected result should now be:
198.51.100.25
The system resolver can also be checked:
getent ahosts example.net
Once both commands return the new address, applications should normally begin using it automatically.
No application-specific cache cleanup is necessary.
A Useful Diagnostic Pattern
When a DNS record has recently changed, one of the fastest troubleshooting methods is simply to compare the default resolver against a known public resolver:
dig +short example.net
dig @1.1.1.1 example.net +short
There are several possible outcomes.
Both Return the Old Address
Example:
Default DNS: 203.0.113.10
Cloudflare: 203.0.113.10
The DNS change may not have propagated yet, or the authoritative DNS record may still contain the old value.
Check:
dig +trace example.net A
Both Return the New Address
Example:
Default DNS: 198.51.100.25
Cloudflare: 198.51.100.25
DNS resolution is working correctly.
If an application still connects to the old IP, then application-level caching or configuration becomes a more reasonable suspect.
Public DNS Returns the New Address, but Local DNS Returns the Old One
Example:
Default DNS: 203.0.113.10
Cloudflare: 198.51.100.25
This is the classic indication of a stale local or upstream DNS cache.
Possible sources include:
- an OpenWrt router
dnsmasq- another local DNS forwarder
- Pi-hole
- AdGuard Home
- a corporate DNS server
- an ISP resolver
The local DNS layer should be investigated before modifying the application.
What About systemd-resolved?
On some Linux systems, the command:
resolvectl query example.net
can be useful for inspecting DNS resolution.
But it only works when systemd-resolved is actually running.
If the command returns an error such as:
Could not activate remote peer 'org.freedesktop.resolve1'
it does not necessarily indicate a networking problem.
It may simply mean that the system is not using systemd-resolved.
Many Linux installations use another DNS configuration method instead.
In such cases, commands such as these remain useful:
dig
getent
cat /etc/resolv.conf
Do Not Confuse DNS Cache With SSH Known Hosts
Another common source of confusion is the SSH known_hosts database.
DNS caching and SSH host-key storage are different mechanisms.
DNS answers this question:
Which IP address belongs to this hostname?
SSH known_hosts answers another:
Which SSH host key was previously associated with this hostname or IP?
Changing a server’s public IP usually does not require deleting its known-host entry if the SSH host key remains unchanged.
The known-host database should only be investigated when SSH reports a host-key verification problem, such as:
REMOTE HOST IDENTIFICATION HAS CHANGED
Deleting SSH host keys to fix a stale DNS record addresses the wrong layer of the problem.
Understanding TTL
DNS records include a TTL, or Time To Live.
For example:
example.net. 3600 IN A 198.51.100.25
A TTL of 3600 means the record may normally be cached for up to 3600 seconds, or one hour.
After a DNS record changes, recursive resolvers that cached the old result are allowed to continue serving it until its TTL expires.
This is why DNS changes may appear inconsistent for a period of time.
One resolver may return:
203.0.113.10
while another already returns:
198.51.100.25
Once the old cached entry expires, the resolver requests the record again and receives the new address.
Restarting a local caching resolver such as dnsmasq effectively forces that local cache to be discarded immediately.
A More Efficient Troubleshooting Workflow
When a hostname seems stuck on an old IP address, a good diagnostic sequence is:
dig +short example.net
Then compare it with:
dig @1.1.1.1 example.net A +short
dig @8.8.8.8 example.net A +short
If the results disagree, inspect the authoritative record:
dig +trace example.net A
Then determine the machine’s normal DNS resolver:
cat /etc/resolv.conf
or inspect the network configuration.
If the router is acting as the DNS forwarder, query it explicitly:
dig @192.168.1.1 example.net A
If the router returns the old IP while public resolvers return the new one, the problem has effectively been isolated.
On OpenWrt with dnsmasq, the final corrective step may simply be:
/etc/init.d/dnsmasq restart
Then verify:
dig +short example.net
The Main Lesson
When an application continues using an old IP after a DNS change, do not immediately assume the application has cached it.
DNS resolution is layered.
A typical request may pass through:
Application
↓
Operating system
↓
Local router
↓
DNS forwarder/cache
↓
Recursive resolver
↓
Authoritative nameserver
Any caching layer can temporarily retain an older record.
The most useful diagnostic technique is therefore not indiscriminately clearing caches, but comparing answers from different points in the DNS chain.
In this scenario, the authoritative DNS infrastructure had already been updated correctly. Public resolvers also returned the new address. Only the local OpenWrt router continued serving the previous A record from its dnsmasq cache.
Restarting dnsmasq removed the stale record, after which all clients on the LAN immediately began resolving the domain to its new public IP.
The apparent application cache was never an application cache at all.
It was DNS doing exactly what DNS caches are designed to do.