AAAA record got lost

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. :slightly_frowning_face:

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

@corny @dmke Are there any news about this issue and its solution? Thanks :slight_smile: .

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 :frowning:

Same here. Regular losses of A and AAAA records.

Same happens with my only CNAME record. Daily lost and really annoying.

Edit:
Now it’s every hour.

Are there any news? This is a really serious and annoying bug which is present for ages…

1 Like

I have the same issue.
Readded an AAAA record 2 days ago, set the Name to * and the Data the same as my IPv6 Prefix.
Today I noticed that it is gone again.

While I’m writing this it disappeared again!

Edit: Today “just” the “Name” has been purged.