Glad to hear!
Does not seem to work for me: A newly created AAAA record in my zone keeps disappearing after 1-2 days; older records (that I did not modify) seem to stay.
I’m investigating this issue. I wrote a script to create a AAAA record automatically. It is called via a systemd timer every 15 minutes:
curl -sS --fail \
-H "Authorization: Bearer ****" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
--data '{"type": "AAAA", "name": "'$(date +"%F_%H%M")'", "data": "::1"}' \
https://dynv6.com/api/v2/zones/12345/records
I’m sure we can find the reason and solve this issue soon.
1 Like
Hi there,
has this issue been resolved in the meantime? If yes, then it is back now.
Since two days (perhaps longer) some of my A and AAAA records disappear randomly, and I have to recreate them manually. There is one particular A record being affected most (more than once a day), but others get lost, too.
I am thinking about writing a cron job to nslookup all my sites, and if it reports “unknown host” to restore the missing records automatically. This could run every 5 min or so, but it can’t be a solution.
Could someone of the dynv6 team please take a look on that.
Thanks, Tom
I have the same problem with my A record. It gets lost nearly once a day.
A few days ago it was almost impossible to recreate it.
I added the record and when I refreshed the page a few seconds later it was gone again.
I had to repeat adding the record for more than 20 times until I had success.
But one day later it was lost again.
If I can support analysis by providing additional information please let me know.
I’ve done some further investigation:
Only one of my records is affected. I can re-insert one or more copies of it, and they will remain for a certain time. If more than one, they disappear all at the same time. On the other hand, the record survived two IP address changes.
@dynv6-Team:
Could it be a corrupt index in the database? This typically leads to the effect that records can’t be retrieved anymore although they are still present. If there is a background job that wipes out duplicate entries, this would even explain why re-inserted entries disappear again: This process would see both records and delete the newer one, the duplicate. So only the entry with the broken index entry would remain, but unfortunately invisible. This is just my personal theory, but if it is correct, re-indexing the database would help.
@other affected users:
For the time being, I run the script below on a regular base as a work-around. It needs the jq package to be installed.
You can find your token in the web interface if you click on your username and then “keys”. The zone ID can be seen in the browser’s address bar when you open the records page.
Replace ‘myhost’ with your own host name.
8< ----------------------------------
#!/bin/bash
TOKEN=abcdefghijklmnopqrstuvwxyzABCD
ZONEID=1234567
HOST=myhost
OK=\
`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 == "’$HOST’") | .name ’ \
| wc -l`
if [ “$OK” -eq “0” ]
then
echo “Inserting missing record ‘$HOST’:”
curl -sS --fail \
-H “Authorization: Bearer $TOKEN” \
-H “Content-Type: application/json” \
-H “Accept: application/json” \
–data ‘{“type”: “A”, “name”: "’$HOST’", “data”: “”}’ \
https://dynv6.com/api/v2/zones/$ZONEID/records
fi
---------------------------------- >8
Cheers, Thomas
Same here. Usually the latest entry disappears, the older ones are kept just fine. In the past one or two months it was much better, with the entry disappearing only once every 2 weeks. But now it’s again almost daily. Really frustrating.
Meanwhile I’ve created a new zone for testing with a name quite similar to my existing one, and cloned all of my records to this zone. Say, “foo.example.com” becomes “foo.example.dynv6.net”. So the respective records of both zones appear alphabetically close to each other.
Result: Each time “foo.example.com” disappears, its companion “foo.example.dynv6.net” gets lost, too. All other entries remain stable in both zones. Right now this appears to happen three times a day, around 10 am and 9pm, plus 1am (all times in UTC+1).
Draw your own conclusion, but my personal guess is still a broken index in the database.
FYI, here is the script I am using for monitoring my records (you would need to replace the typographic double and single quotes with “simple” ones). It needs the jq package to be installed.
#!/bin/bash
#Poll all records of a zone at dynv6, restore missing ones
#Settings
TOKEN= # insert your token here
ZONEID= # insert your zoneid here
if [ X != X$1 ]
then
ZONEID=$1
fi
TEMPFILE=/tmp/dynv6_$ZONEID.tmp
RECORDS_A=(‘foo’ ‘bar’ ‘huey’ ‘dewey’ ‘louie’) # replace with your actual entries
RECORDS_AAAA=(‘foo’ ‘bar’ ‘huey’ ‘dewey’ ‘louie’ ‘’)
V6_SUFFIX1=’::1’ # local part of your host’s v6 address here
#Get current status
curl -sS --fail \
-H “Authorization: Bearer $TOKEN” \
-H “Accept: application/json” \
https://dynv6.com/api/v2/zones/$ZONEID/records \
| jq ‘.’ \
> $TEMPFILE
LINES_READ=`cat $TEMPFILE | wc -l`
if [ “$LINES_READ” -eq “0” ] # if the result is empty, then curl has failed and if we continue we potentially create duplicates
then
echo “Abort”
exit
fi
#Identify missing records and restore them
for HOST in “${RECORDS_A[@]}”
do
OK=`jq ‘.[] | select (.type == “A”) | select (.name == "’$HOST’") | .name ’ $TEMPFILE | wc -l` # must be >= 1
if [ “$OK” -eq “0” ]
then
echo “Restore missing entry ‘$HOST’:”
curl -sS --fail \
-H “Authorization: Bearer $TOKEN” \
-H “Content-Type: application/json” \
-H “Accept: application/json” \
–data ‘{“type”: “A”, “name”: "’$HOST’", “data”: “”}’ \
https://dynv6.com/api/v2/zones/$ZONEID/records
fi
done
for HOST in “${RECORDS_AAAA[@]}”
do
OK=`jq ‘.[] | select (.type == “AAAA”) | select (.name == "’$HOST’") | .name ’ $TEMPFILE | wc -l` # must be >= 1
if [ “$OK” -eq “0” ]
then
echo “Restore missing entry ‘$HOST’:”
curl -sS --fail \
-H “Authorization: Bearer $TOKEN” \
-H “Content-Type: application/json” \
-H “Accept: application/json” \
–data ‘{“type”: “AAAA”, “name”: "’$HOST’", “data”: “’$V6_SUFFIX1’”}’ \
https://dynv6.com/api/v2/zones/$ZONEID/records
fi10
done
I can confirm this keeps happening every few days for an A record of mine
Happening to me as well, but only for one record about once a day
Just a short resume of the current status, and what happened so far:
I got aware of the issue on Jan 4th due to a user complaint (site not reachable). Both A and AAAA records had disappeared for that host. It turned out that other A, AAAA, and MX records had disappeared, too.
After restoring the lost records everything remained fine except of one A record that kept disappearing several times a day.
At present it occurs once a day, typically between 21:08 and 21:16 CET.
A test zone with a very similar name revealed exactly the same behavior simultaneously. (I meanwhile removed it).
The behavior seems to be very regular now. Perhaps it is not the same issue as other users reported about records vanishing randomly, or even after a few seconds.
I hope this helps to locate and fix the issue!
Thomas
for me too.
The AAAA-record disappeared yesterday.
AugustQ
@corny What is your progress, could you locate the reason for these disappearing records?
After the problem seemed to have gone for the last months, it is back for me since a few days. My AAAA or CNAME records keep disappearing.
A name service must be reliable, or it is better not to use it. If this isn’t resolved, I’m afraid I will be looking for another service provider soon.
Latest status: One specific A-record disappears reliably at 21:08 CET every day, and then once more between 21:09 and 21:30. In-between it happened once that two other records disappeared, too, at a random time but simultaneously.
I tried to confirm my hypothesis mentioned above about a database index issue by deleting a recently disappeared record manually via the REST API. In this case the record should be found by ID, not by name, so it’s not the same index. It returned 404 - not found, so meanwhile I believe these records are really gone and not only “invisible”.
I am ready to answer any question to support the maintainers, but I’m not certain whether anybody takes care of this issue at present.
1 Like
My TXT record for google site verification got lost again somewhere in the past couple of days.
Same here 
Loosing AAAA-Records with MAC-address-data. Can anybody help, or ist this free service dead?
I also loose my only A-Record every few days.
Also lost my AAAA records except one
Hi, I also regularly loose an A record.
However, I only loose my nextcloud A record. All others persist, regardless of length (tried both longer and shorter and exactly same length) or whether they were created earlier or later.
Any ideas of how to solve the issue?
As a workaround, does any one know how to update an A record via ssh in an automated manner? I only know how to login and do it by hand.
This is interesting because for me its also only my “nextcloud” A record.
You can scroll up in this thread and check the script thomas has posted, maybe you can get it to work to fix your record.
I gave up on this matter completely and I’m in the process of migrating all my services off dynv6. It seems to me nobody is working on this issue and I’m taking my business elsewhere, maybe it is true when someone says you get what you pay for.