Hi!
Thank you for the script. I managed to install the other dependencies. I am stuck, however, at the point where it wants the binary “ts” to be installed. I installed Typescript but it still doesn’t work. It gives me the error: “ERROR: This script requires ts.”
Could you help me with that? (I am on Ubuntu 18.04 LTS)
Thank you very much!
You may want to install the package moreutils which contains ts.
… or just remove ‘ts’ from the for loop in line 11 and the ‘|ts’ in line 18
it doesn’t really do anything critical except format output
No answer from Digineo so far, unfortunately… 
Recent observation: Since ‘cloud’ records are disappearing nearly hourly meanwhile, it appears to happen less often at night (CET). Perhaps a load issue?
@thomas thx for sending the mail and i can confirm your observation:
I let my oneliner run in a while loop for a couple of days now…
My wiki subdomain gets deleted from 5:10 in the morning, every hour at the tenth minute until 22:10, the hours 23-4 have no problems (Germany times).
I am hesitant to spam their inbox. Somehow i got the feeling Digineo is not that big in manpower and hopefully there is not some unfortunate event involved … i mean, humankind currently lives in strange times.
Since there is a workaround, this bug does not bother me too much anymore. But without any sensible contact this looks currently a little like abandonware and it would be a shame too loose this useful convenient and free service for all those poor people with a forced disconnect and non static ips.
I am really not sure what kind of price point they could charge us ‘normal’ people (not businesses) though to make dynv6 better supported and maintained. I definitely wouldn’t pay more than a euro per month and they would immediately compete against domain hosters (since they all do have apis for dns management nowadays).
For the time being i just hope the company is still good, which would mean eventually someone will look into the problem.
Edit: Just saw @Corny 's posting in the forum on Feb 28th … not sure what to make of this situation, looked only into @dmke 's last posting. Since they should get a ping from this mentioning, is there a need for private message?
May show code in </> Preformatted Text ?
such as:
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
otherwise, the quotation marks( ’ ’ " " ) may change to other type.( ’ ’ “ ” )
Good point, sorry I missed that.
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
.