0

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?

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
QF0
  • 183
  • 1
  • 7
  • 1
    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. – anx Jun 20 '23 at 10:50

1 Answers1

1

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.

anx
  • 8,963
  • 5
  • 24
  • 48
  • `+trace` looks nice - working through it. Fair point on the on the public records - it's 217.76.55.194. – QF0 Jun 20 '23 at 11:50
  • 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... :/ – QF0 Jun 20 '23 at 12:25