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.<\/p>\n\n\n\n
In many cases, however, the application is not responsible at all.<\/p>\n\n\n\n
The real cause may be a stale DNS record cached by the local router.<\/p>\n\n\n\n
This article walks through a practical troubleshooting scenario involving Linux clients, an OpenWrt router, Assume a domain previously pointed to:<\/p>\n\n\n\n The DNS record was then updated to:<\/p>\n\n\n\n After the change, an SSH client continued attempting connections to the old IP.<\/p>\n\n\n\n At first glance, the most obvious explanation seemed to be:<\/p>\n\n\n\n The SSH client must have cached the old DNS result.<\/p>\n<\/blockquote>\n\n\n\n That assumption turned out to be incorrect.<\/p>\n\n\n\n The stale record was actually being returned by the network’s local DNS resolver.<\/p>\n\n\n\n The first test on the Linux workstation was:<\/p>\n\n\n\n The result was still the old address:<\/p>\n\n\n\n The system resolver returned the same value:<\/p>\n\n\n\n Example output:<\/p>\n\n\n\n This is already an important clue.<\/p>\n\n\n\n If both The operating system itself is receiving the old DNS answer.<\/p>\n\n\n\n The next step is to bypass the default DNS resolver and query several public DNS services directly:<\/p>\n\n\n\n Suppose all three return:<\/p>\n\n\n\n This immediately narrows down the problem.<\/p>\n\n\n\n Public DNS resolvers already know the new address, while the local machine still receives the old one.<\/p>\n\n\n\n The DNS update itself is therefore probably correct.<\/p>\n\n\n\n The stale response must be somewhere between the workstation and the public DNS infrastructure.<\/p>\n\n\n\n For additional confirmation, the authoritative DNS chain can be inspected with:<\/p>\n\n\n\n Near the end of the trace, the authoritative nameserver should return something similar to:<\/p>\n\n\n\n At this point, three things are established:<\/p>\n\n\n\n The DNS provider is therefore not the source of the problem.<\/p>\n\n\n\n The For example:<\/p>\n\n\n\n In many home or small-office networks, this address belongs to the router.<\/p>\n\n\n\n With OpenWrt, DNS requests from LAN clients are commonly handled by The effective resolution path may therefore look like this:<\/p>\n\n\n\n If The SSH client appeared to be connecting to an old address, which made application-level caching seem plausible.<\/p>\n\n\n\n But the client was simply doing something ordinary:<\/p>\n\n\n\n The system asks the router.<\/p>\n\n\n\n The router answers:<\/p>\n\n\n\n The SSH client then connects to that address.<\/p>\n\n\n\n From the user’s perspective, it looks as though the SSH client remembers the old IP.<\/p>\n\n\n\n In reality, it is following the DNS answer it receives.<\/p>\n\n\n\n This distinction is important because clearing application data, deleting SSH hosts, or reinstalling the client would accomplish nothing.<\/p>\n\n\n\n On an OpenWrt router using Afterward, test from the workstation again:<\/p>\n\n\n\n The expected result should now be:<\/p>\n\n\n\n The system resolver can also be checked:<\/p>\n\n\n\n Once both commands return the new address, applications should normally begin using it automatically.<\/p>\n\n\n\n No application-specific cache cleanup is necessary.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n There are several possible outcomes.<\/p>\n\n\n\n Example:<\/p>\n\n\n\n The DNS change may not have propagated yet, or the authoritative DNS record may still contain the old value.<\/p>\n\n\n\n Check:<\/p>\n\n\n\n Example:<\/p>\n\n\n\n DNS resolution is working correctly.<\/p>\n\n\n\n If an application still connects to the old IP, then application-level caching or configuration becomes a more reasonable suspect.<\/p>\n\n\n\n Example:<\/p>\n\n\n\n This is the classic indication of a stale local or upstream DNS cache.<\/p>\n\n\n\n Possible sources include:<\/p>\n\n\n\n The local DNS layer should be investigated before modifying the application.<\/p>\n\n\n\n On some Linux systems, the command:<\/p>\n\n\n\n can be useful for inspecting DNS resolution.<\/p>\n\n\n\n But it only works when If the command returns an error such as:<\/p>\n\n\n\n it does not necessarily indicate a networking problem.<\/p>\n\n\n\n It may simply mean that the system is not using Many Linux installations use another DNS configuration method instead.<\/p>\n\n\n\n In such cases, commands such as these remain useful:<\/p>\n\n\n\n Another common source of confusion is the SSH DNS caching and SSH host-key storage are different mechanisms.<\/p>\n\n\n\n DNS answers this question:<\/p>\n\n\n\n SSH Changing a server’s public IP usually does not require deleting its known-host entry if the SSH host key remains unchanged.<\/p>\n\n\n\n The known-host database should only be investigated when SSH reports a host-key verification problem, such as:<\/p>\n\n\n\n Deleting SSH host keys to fix a stale DNS record addresses the wrong layer of the problem.<\/p>\n\n\n\n DNS records include a TTL, or Time To Live.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n A TTL of After a DNS record changes, recursive resolvers that cached the old result are allowed to continue serving it until its TTL expires.<\/p>\n\n\n\n This is why DNS changes may appear inconsistent for a period of time.<\/p>\n\n\n\n One resolver may return:<\/p>\n\n\n\n while another already returns:<\/p>\n\n\n\n Once the old cached entry expires, the resolver requests the record again and receives the new address.<\/p>\n\n\n\n Restarting a local caching resolver such as When a hostname seems stuck on an old IP address, a good diagnostic sequence is:<\/p>\n\n\n\n Then compare it with:<\/p>\n\n\n\n If the results disagree, inspect the authoritative record:<\/p>\n\n\n\n Then determine the machine’s normal DNS resolver:<\/p>\n\n\n\n or inspect the network configuration.<\/p>\n\n\n\n If the router is acting as the DNS forwarder, query it explicitly:<\/p>\n\n\n\n If the router returns the old IP while public resolvers return the new one, the problem has effectively been isolated.<\/p>\n\n\n\n On OpenWrt with Then verify:<\/p>\n\n\n\n When an application continues using an old IP after a DNS change, do not immediately assume the application has cached it.<\/p>\n\n\n\n DNS resolution is layered.<\/p>\n\n\n\n A typical request may pass through:<\/p>\n\n\n\n Any caching layer can temporarily retain an older record.<\/p>\n\n\n\n The most useful diagnostic technique is therefore not indiscriminately clearing caches, but comparing answers from different points in the DNS chain.<\/p>\n\n\n\n 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 Restarting The apparent application cache was never an application cache at all.<\/p>\n\n\n\n It was DNS doing exactly what DNS caches are designed to do.<\/p>\n","protected":false},"excerpt":{"rendered":" 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 …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[120],"tags":[243,334,264],"class_list":["post-6138","post","type-post","status-publish","format-standard","hentry","category-1s3b6h7r2zay02x","tag-dns","tag-routers","tag-troubleshooting"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6138","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/comments?post=6138"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6138\/revisions"}],"predecessor-version":[{"id":6139,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6138\/revisions\/6139"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}dnsmasq<\/code>, and a domain whose public IP address recently changed.<\/p>\n\n\n\n
\n\n\n\nThe Scenario<\/h2>\n\n\n\n
203.0.113.10\n<\/code><\/pre>\n\n\n\n198.51.100.25\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nStep 1: Check Normal DNS Resolution<\/h2>\n\n\n\n
dig +short example.net\n<\/code><\/pre>\n\n\n\n203.0.113.10\n<\/code><\/pre>\n\n\n\ngetent ahosts example.net\n<\/code><\/pre>\n\n\n\n203.0.113.10 STREAM example.net\n203.0.113.10 DGRAM\n203.0.113.10 RAW\n<\/code><\/pre>\n\n\n\ndig<\/code> and getent<\/code> return the old IP, the problem is probably not confined to one application.<\/p>\n\n\n\n
\n\n\n\nStep 2: Compare Against Public DNS Resolvers<\/h2>\n\n\n\n
dig @1.1.1.1 example.net A +short\ndig @8.8.8.8 example.net A +short\ndig @9.9.9.9 example.net A +short\n<\/code><\/pre>\n\n\n\n198.51.100.25\n<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 3: Check the Authoritative DNS Record<\/h2>\n\n\n\n
dig +trace example.net A\n<\/code><\/pre>\n\n\n\nexample.net. 3600 IN A 198.51.100.25\n<\/code><\/pre>\n\n\n\n\n
\n\n\n\nStep 4: Identify the Local DNS Resolver<\/h2>\n\n\n\n
dig +trace<\/code> output, \/etc\/resolv.conf<\/code>, or network configuration can reveal which DNS server the workstation normally uses.<\/p>\n\n\n\n192.168.1.1\n<\/code><\/pre>\n\n\n\ndnsmasq<\/code>.<\/p>\n\n\n\nApplication\n \u2193\nLinux resolver\n \u2193\nOpenWrt router\n \u2193\ndnsmasq cache\n \u2193\nUpstream DNS\n \u2193\nAuthoritative DNS\n<\/code><\/pre>\n\n\n\ndnsmasq<\/code> still holds the previous A record, every LAN client using the router as its DNS server may receive the stale IP.<\/p>\n\n\n\n
\n\n\n\nWhy the Application Looked Guilty<\/h2>\n\n\n\n
SSH client asks system:\n\"What IP belongs to example.net?\"\n<\/code><\/pre>\n\n\n\n203.0.113.10\n<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 5: Clear the OpenWrt DNS Cache<\/h2>\n\n\n\n
dnsmasq<\/code>, restarting the service is a straightforward way to discard its in-memory DNS cache:<\/p>\n\n\n\n\/etc\/init.d\/dnsmasq restart\n<\/code><\/pre>\n\n\n\ndig +short example.net\n<\/code><\/pre>\n\n\n\n198.51.100.25\n<\/code><\/pre>\n\n\n\ngetent ahosts example.net\n<\/code><\/pre>\n\n\n\n
\n\n\n\nA Useful Diagnostic Pattern<\/h2>\n\n\n\n
dig +short example.net\ndig @1.1.1.1 example.net +short\n<\/code><\/pre>\n\n\n\nBoth Return the Old Address<\/h3>\n\n\n\n
Default DNS: 203.0.113.10\nCloudflare: 203.0.113.10\n<\/code><\/pre>\n\n\n\ndig +trace example.net A\n<\/code><\/pre>\n\n\n\n
\n\n\n\nBoth Return the New Address<\/h3>\n\n\n\n
Default DNS: 198.51.100.25\nCloudflare: 198.51.100.25\n<\/code><\/pre>\n\n\n\n
\n\n\n\nPublic DNS Returns the New Address, but Local DNS Returns the Old One<\/h3>\n\n\n\n
Default DNS: 203.0.113.10\nCloudflare: 198.51.100.25\n<\/code><\/pre>\n\n\n\n\n
dnsmasq<\/code><\/li>\n\n\n\n
\n\n\n\nWhat About
systemd-resolved<\/code>?<\/h2>\n\n\n\nresolvectl query example.net\n<\/code><\/pre>\n\n\n\nsystemd-resolved<\/code> is actually running.<\/p>\n\n\n\nCould not activate remote peer 'org.freedesktop.resolve1'\n<\/code><\/pre>\n\n\n\nsystemd-resolved<\/code>.<\/p>\n\n\n\ndig\ngetent\ncat \/etc\/resolv.conf\n<\/code><\/pre>\n\n\n\n
\n\n\n\nDo Not Confuse DNS Cache With SSH Known Hosts<\/h2>\n\n\n\n
known_hosts<\/code> database.<\/p>\n\n\n\nWhich IP address belongs to this hostname?\n<\/code><\/pre>\n\n\n\nknown_hosts<\/code> answers another:<\/p>\n\n\n\nWhich SSH host key was previously associated with this hostname or IP?\n<\/code><\/pre>\n\n\n\nREMOTE HOST IDENTIFICATION HAS CHANGED\n<\/code><\/pre>\n\n\n\n
\n\n\n\nUnderstanding TTL<\/h2>\n\n\n\n
example.net. 3600 IN A 198.51.100.25\n<\/code><\/pre>\n\n\n\n3600<\/code> means the record may normally be cached for up to 3600 seconds, or one hour.<\/p>\n\n\n\n203.0.113.10\n<\/code><\/pre>\n\n\n\n198.51.100.25\n<\/code><\/pre>\n\n\n\ndnsmasq<\/code> effectively forces that local cache to be discarded immediately.<\/p>\n\n\n\n
\n\n\n\nA More Efficient Troubleshooting Workflow<\/h2>\n\n\n\n
dig +short example.net\n<\/code><\/pre>\n\n\n\ndig @1.1.1.1 example.net A +short\ndig @8.8.8.8 example.net A +short\n<\/code><\/pre>\n\n\n\ndig +trace example.net A\n<\/code><\/pre>\n\n\n\ncat \/etc\/resolv.conf\n<\/code><\/pre>\n\n\n\ndig @192.168.1.1 example.net A\n<\/code><\/pre>\n\n\n\ndnsmasq<\/code>, the final corrective step may simply be:<\/p>\n\n\n\n\/etc\/init.d\/dnsmasq restart\n<\/code><\/pre>\n\n\n\ndig +short example.net\n<\/code><\/pre>\n\n\n\n
\n\n\n\nThe Main Lesson<\/h2>\n\n\n\n
Application\n \u2193\nOperating system\n \u2193\nLocal router\n \u2193\nDNS forwarder\/cache\n \u2193\nRecursive resolver\n \u2193\nAuthoritative nameserver\n<\/code><\/pre>\n\n\n\ndnsmasq<\/code> cache.<\/p>\n\n\n\ndnsmasq<\/code> removed the stale record, after which all clients on the LAN immediately began resolving the domain to its new public IP.<\/p>\n\n\n\n