How to flush DNS cache on Ubuntu 22?

[msbt]

Hi there! I tried manually flushing the DNS cache of one of my machines, because an A-entry of a domain got updated but the TTL was 24 hours and I wanted it asap. I tried running resolvectl flush-caches but the server reply was Failed to flush caches: Unit dbus-org.freedesktop.resolve1.service not found..

This is a Hetzner Cloud machine and other non-Cloudron Ubuntu 22 machines run that command just fine and all the Cloudron Ubuntu 22 did not. Did the setup remove or change something? If so, what's the way to flush the cache?

Best,
M

[girish]

Try systemctl restart unbound .

[msbt]

@girish thanks, but that didn't change anything, restarted the machine earlier as well

[girish]

@msbt what's the issue though ? I only answered your flush DNS question

[msbt]

@girish well the cache didn't flush and the command still doesn't work, the ping still points to the old IP

[girish]

@msbt oh, for that, you have to flush your PC's cache and not Cloudron server. The answer then depends on Linux/Windows/Mac/Android/iOS.

As for the intermediate routers, generally you cannot do anything. This is the thing with setting high TTL. Also, the issue will only be on your network and not in other people's network (they will get the latest DNS). You can test with you 4G/5G for example.

[msbt]

@girish nono, the local ping and various servers resolve the correct IP just fine, the installation of an app on Cloudron is just stuck because it doesn't resolve the correct/new IP

[girish]

@msbt Ah ok, for that it means that the DNS is stuck somewhere in the "world". You can try something like this:

• Get the name servers - host -t NS domain.com
• Then, host some.nameserver.above . This will give an IP address
• Then, host domain.com ip.of.nameserver - Does this work for all the nameservers in step 2?

The above is roughly what Cloudron does. If one or more nameservers are not in "sync", then cert generation will fail because Let's Encrypt does the same thing.

[msbt]

@girish the app installation fails with Error : DNS Error - DNS A Record is not synced yet: ETRYAGAIN

host domain.com ip.of.nameserver shows the old IP address, guess I'll have to wait it out

[msbt]

weird though, just tried the same commands on a different server (also Hetzner), the host command points to the old ip, a ping to the domain to the new one

[girish]

@msbt yeah, ping just picks the first one that responds. So, while it's a good check, it's not complete.

The app logs will tell you which DNS server is the "culprit". The issue is that LE verification will fail as the IP address is different and it will hit some other server.

[msbt]

@girish ah thx, that's what it says:

box:dns/waitfordns isChangeSynced: domain.com (A) was resolved to old.ip at NS helium.ns.hetzner.de (193.47.99.5). Expecting new.ip. Match false

So there's no way around that other than lowering the TTL before a change?

[girish]

@msbt the TTL is the cache time and hint for resolvers to cache. So, if you had a long TTL with the old IP address, it's probably going to get cached for that long. Which means changing it before making a change to new IP, doesn't help.

In general, keep long TTLs only if you are super sure IP won't change. If a customer had a long TTL to begin with, one has to wait it out, there is no other way.

That said, there's more things at play here. For LE, it has never probably seen this domain before. So, it's going to query from "scratch" and thus TTL does not come into play for LE network itself. The issue here seems to be that Hetzner's nameservers have not "synced" the change. These servers are called "authoritative servers" and will usually update asap (since they are the "authority" on this DNS entry and they know things have changed). But it looks like you are waiting for hours already... Maybe you can ask hetzner what's going on?

[girish]

@msbt Well, as a hack, you can delete the DNS entry. Wait for 5-10 mins. Then , re-add the entry. Maybe this will help hetzner servers resync . I know this trick atleast helps Cloudflare's implementation.

[msbt]

@girish thanks for the explanation! Yeah the change happened ~14 hours ago and the TTL was set to 24 hours I reckon. I'll just wait until tomorrow to continue

My plan would have been to lower the TTL a few days prior to the A record, so the caches would invalidate sooner.