Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved How to flush DNS cache on Ubuntu 22?

    Support
    dns cache resolvectl
    2
    15
    65
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      msbt App Dev last edited by

      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

      1 Reply Last reply Reply Quote 0
      • girish
        girish Staff last edited by

        Try systemctl restart unbound .

        M 1 Reply Last reply Reply Quote 0
        • M
          msbt App Dev @girish last edited by

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

          girish 1 Reply Last reply Reply Quote 0
          • girish
            girish Staff @msbt last edited by

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

            M 1 Reply Last reply Reply Quote 0
            • M
              msbt App Dev @girish last edited by

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

              girish 1 Reply Last reply Reply Quote 0
              • girish
                girish Staff @msbt last edited by 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.

                M 1 Reply Last reply Reply Quote 0
                • M
                  msbt App Dev @girish last edited by 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 1 Reply Last reply Reply Quote 0
                  • girish
                    girish Staff @msbt last edited by

                    @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.

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      msbt App Dev @girish last edited by

                      @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

                      M 1 Reply Last reply Reply Quote 0
                      • M
                        msbt App Dev @msbt last edited by

                        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 1 Reply Last reply Reply Quote 0
                        • girish
                          girish Staff @msbt last edited by

                          @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.

                          M 1 Reply Last reply Reply Quote 1
                          • M
                            msbt App Dev @girish last edited by

                            @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 2 Replies Last reply Reply Quote 0
                            • girish
                              girish Staff @msbt last edited by

                              @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?

                              1 Reply Last reply Reply Quote 0
                              • girish
                                girish Staff @msbt last edited by

                                @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.

                                M 1 Reply Last reply Reply Quote 1
                                • M
                                  msbt App Dev @girish last edited by 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.

                                  1 Reply Last reply Reply Quote 0
                                  • Topic has been marked as a question  M msbt 
                                  • Topic has been marked as solved  M msbt 
                                  • First post
                                    Last post
                                  Powered by NodeBB