IP in account does not match IP in DNS?

Hi all,
twice now - once a few weeks ago, once yesterday, I’ve encountered the strange problem that the IPv4 update of my dynamic DNS name (kepha.dynv6.net) pointed to the wrong IPv4 address even though the nightly update went through fine.

I would sign into my dynv6 account, where I could see that the correct IPv4 address was listed under “Current status”, and that the last update happened around 5a.m. that morning.

But if if tried the same over DNS - for example by using the “host” or “dig” commands on linux machines, or using “nslookup” on windows - I got a different IP address, presumably the one from the previous update. This false IP reply was consistent over multiple DNS inquiries, done from different machines on different networks over the course of an hour, and more than 15 hours after the IP update via the API. Repeating the IP update via "“http://ipv4.dynv6.com/api/update?hostname=$hostname&ipv4=auto&token=$token” (with the appropriate variables set) did not change anything, either.

The only way to get this working again was to klick on “Edit Zone” on the dynv6 website and then just confirming the data already listed without any change. After that, the DNS replies showed the correct IP address. But fixing this manually each time it happens is obviously not a viable solution, especially as this error it doesn’t occur every night.

Does anybody have any idea what is happening there and why? For those with access to dynv6’s DNS logs (if any), the problem last occured yesterday morning between 5 and 6 a.m. and was manually fixed by be yesterday evening between 8 and 9 p.m. (all times CEST).

Any help is appreaciated.

Best regards
Kaz

Thanks for your bug report. I was able to reproduce your problem. It seems to happen in few cases and is probably a timing issue with the update of the SQL database and the zone refresh. I’ll come back soon with an update.

1 Like

Thanks for the info; I’m looking forward to the fix. The same error happened again this morning, so the problem seems to occur about once every two-and-a-half weeks for me at the moment. This is a really annoying bug because you can only fix it by logging into the web interface and re-applying the same data already listed there - something which I cannot easily automate.