And once again my AAAA and TXT records have vanished.
Same to me. AAAA record get lost.
The ‘cloud’ record got lost hourly in twenty days ago. However, it lost 3-4 times per hour now.
Tue Mar 23 12:10:39 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 13:11:11 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 14:10:55 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 15:11:07 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 16:11:38 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 17:11:06 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 18:10:50 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 18:15:29 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 19:11:32 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 20:17:37 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 21:25:00 UTC+8 2021, Record "cloud" disappeared
Tue Mar 23 22:11:12 UTC+8 2021, Record "cloud" disappeared
...
Sat Mar 27 17:01:21 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 17:16:05 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 17:32:57 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 17:45:39 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 18:00:30 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 18:15:29 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 18:31:41 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 18:35:36 UTC+8 2021, Record "cloud" disappeared
Sat Mar 27 18:46:13 UTC+8 2021, Record "cloud" disappeared
...
Wed Apr 14 17:00:55 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 17:24:24 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 17:45:46 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 18:16:50 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 18:31:38 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 18:45:44 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 19:00:58 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 19:16:11 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 19:30:49 UTC+8 2021, Record "cloud" disappeared
Wed Apr 14 19:46:11 UTC+8 2021, Record "cloud" disappearedLooks pretty much the same as here. Are there any times during the day when it happens less often? Perhaps in the morning? I am under the impression that it’s better when it’s night in Europe. At Easter there was a “good” period, too, my “cloud” records survived for more than 12 hours. So it could be related to the server load.
Also, how do you check your records? Via the API, or by ‘dig’-ing at their nameservers?
YES, it less happens from 5:00 to 11:00 (UTC+8), ie, 21:00 - 3:00 (UTC).
And it happens 3-4 times in the every hours from 11:00 (UTC+8) to 4:30 (UTC+8 next day), ie, from 3:00 (UTC) to 20:30 (UTC).
Tue Apr 6 04:17:20 UTC+8 2021, Record "cloud" disappeared
Tue Apr 6 04:31:25 UTC+8 2021, Record "cloud" disappeared
Tue Apr 6 11:16:03 UTC+8 2021, Record "cloud" disappeared
Tue Apr 6 11:31:22 UTC+8 2021, Record "cloud" disappeared
I check it every 30-150 seconds by API as you posted.
sleep $(($RANDOM%120+30 )) # random sleep 30-150 s
TOKEN=4qwetyuiuioppasdfghjk # your TOKEN
ZONEID=12345 # your ZONEID
NAME=cloud
N_find=`curl -sS --fail -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" https://dynv6.com/api/v2/zones/$ZONEID/records | jq '.[] | select (.type == "A") | select (.name == "'$NAME'") | .name ' |wc -l`
if [ "$N_find" -eq "0" ] ;
then
echo Record \"$NAME\" disappeared, `date` >> logfile.log
fi
By the way, I‘m wondering about whether there is a virus or autoclean-script on the dynv6 server. 
Thanks for your answer! Yes, that is the same pattern as here. Even the approx. 15 minutes grid is the same.
For checking I switched to using dig as I believe overall it causes less load than the API. So I don’t care whether or not my records are accessible in the API but whether they are still present for the rest of the world. This doesn’t change anything, though: Usually the records disappear from the API first and a few minutes later from Dynv6’s nameservers. Randomly it creates duplicate records which is not a real issue. For cleaning them up I wrote another script (see Existing records not returned in REST API).
Whatever the root cause may be, we won’t solve it here. It’s all about work-arounds…
Wise decision to minimize server load. I now wait for 1-2 minutes to check once. If we abtain the time interval bettween disappearing in API and ‘dig’ nameservers, we could incease the wait time of API checking.
I am using the nsupdate to update DNS instead of http API, ‘duplicate records’ never appeared in this way.
Only the administrator of Dynv6 servers may be helpful to solve this problem. Although I suspect that this problem stems from their autoclean scripts.
Like many others, i got somtimes AAAA records lost.
I also lose some AAAA Records randomly. But they normally restore within a couple of minutes.
I lose the same AAAA- and A-records every day. Usually in the morning. But other AAAA- and A-records stay stable. Any idea about the reason?
renaming a record away from “*cloud” solves my problem of daily loosing … until now
.This issue seems to have been solved since September 4/5. We thank those who worked on it.
Any announcement about it ?
I can confirm this observation. It seems to be stable now. One of my affected records is resolved correctly, but still missing in the web GUI. I would probably need to re-create it in order to fix that.
I am still experiencing this issue with some of my A records.
I have lost my “cloud.” record over 10 times and my “nextcloud.” 1 time.
I can confirm that issue with some A Records, too. My v4. entry gets removed constantly, really annoying!
My problem is that the part of the server host adress i set in the AAAA Record is changed to the router host adress wen the renewed Prefix was send.
I deleted the record entry and created it new but it doesn’t solve my Problem.
If I understand you correctly you issue is not about records disappearing randomly? Then this is not the right thread for your question.
Anyway: In your case it would probably be enough to change the update string your router sends to dynv6 on IP address renewal.
If you are using a Fritzbox then try and edit the update URL in the Fritzbox DynDNS settings. Replace <ip6addr> with <ip6lanprefix>. (Otherwise you might find an analogue setting for your specific router in its documentation).
Also make sure that your IPv6 record(s) in Dynv6 contain only the host part(s) of the respective IPv6 address(es), starting with “::” (two colons). The resulting IPv6 addresses are composed of the prefix and the host part. On the “Records” page, you can toggle the view by clicking on the double arrow icon in the right of “Data”.
Note that the records are not updated on renewal but only the prefix.
If this is not enough to help you please open a new thread as this issue is off-topic here.
Ah yes i am sorry i havent seen that in the update URL both parameters were implemented. So now it should work but without the ip6addr part the prefix isn’t renewed.
Sorry for that. I 'm very frustrated that I can’t find the bug.
I have the same problem with both an A and an AAAA record. They are updated daily and lost daily. It affects always the same records. Other records using the same ip seem to be stable.
Is this being investigated/worked on? It is quite annoying 