Reverse DNS propagation and caching

QF0

6/20/24, 10:47 AM

I set up a VPS (Ubuntu 22.04, at Contabo in Germany) yesterday. Unfortunately, I got the reverse DNS entry incorrect (I entered example.org instead of example.uk). I spotted this quickly, and corrected it, and both mxtoolbox.com and dig on my local system then showed it correctly resolving to example.uk.

This new system has to talk to a mail server, which is also Ubuntu 22.04 (at Ionos in the UK). However, postfix on the mail server rejects incoming mails, because the incoming IP address is still resolving to example.org. This has been carrying on for about 16 hours. There was a period last night when mails were being delivered, but they're not being delivered now.

On the mail server, dig +noall +answer -x ip-addr shows a 2-hour countdown in the TTL. However, it then just cycles again, but still shows example.org. If I flush the local cache with sudo resolvectl flush-caches it makes no difference, but starts the countdown again. I've tried this on another VPS in the same datacentre (Ionos, UK) and it shows the same results.

So, I'm guessing that Ionos has an rDNS cache that ignores the upstream TTL (since mxtoolbox and my own local dig have been showing the correct example.uk result for 16+ hours). Does that make sense? Can I set up the local resolver on the mail server to (temporarily) ignore any upstream caches and get an authoritative answer? How do you even get an authoritative answer on reverse DNS?

1 + 1

domain-name-system

reverse-dns

systemd-resolve

anx

6/20/24, 10:50 AM

You are asking about (by nature) public DNS records. These types of questions are *much* easier to diagnose when you mention the specific record you care about.

Score:1

Server

anx

6/20/24, 11:13 AM

Not much you can do, other than triple checking everything is correct now, and waiting. One way to check if the records look good at your providers servers would be to ask dig to iteratively query all the way from the root:

dig -x 2a02:c205:f00::1:2:3 +trace

ns1.contabo.net gives me 24 hour TTL. Though some caching resolvers might disregard that, that is how long your old records might still be visible to anyone recently interacting with you.

+ 2

QF0

6/20/24, 11:50 AM

`+trace` looks nice - working through it. Fair point on the on the public records - it's 217.76.55.194.

QF0

6/20/24, 12:25 PM

So... `+trace` gives the correct answer. Working through the trace (with some help from https://superuser.com/a/715656/1681094) I can see that Contabo has 3 name servers, all authoritative (`aa` flag) for this query, and all giving the correct result. However, as far as I can see, `trace` doesn't tell you anything about the route taken by a plain `dig` query, so I can't see where in the path an incorrect cached entry is being used. So, yes, just wait... :/

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Reverse DNS propagation and caching

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.