AAAA record got lost

Hello all,
I update my zones yesterday evening with AAAA records. Till now they still there.
Hope they will leave there. Maybe problem is solved.

Any feedback from an admin is welcome. :wink:

Don’t count your chickens before they hatched :stuck_out_tongue:

I had to recreate my zone 6 times or so in the last two weeks.

Thanks! already tried this site, works for me now. I had to write another script to update v6 addr to both dynv6 and ddnss.

Seems like nobody cares to solve the problem anytime soon. I know dynv6 is a free service (for now), but I wish I could throw in some money to get a better service - or indeed any working service. I like the way dynv6 works and I really would like to stay. Isn’t there any representative who could give some qualified answers?

1 Like

I noticed that the update URL for IPv6 now need to contain &ipv6prefix=...

It doesn’t need to be the real Prefix but something that looks like a IPv6 Prefix. This value is show on the website but not used as far as I can tell. There is a Resource Records created for the domain with the IPv6 that is mentioned in the update URL like before. After that I can resolve the AAAA record for my dyn domain.

I use 2000:: as my hard coded bogus IPv6 Prefix ...&ipv6prefix=2000::&...
Depending on your addresses, you might want to use something else.

I’m using ddclient 3.9.1 (eagerly awaiting a version that supports IPv6), and had manually created a AAAA record for one of my zones, which seems to have disappeared as well at some point in the last few weeks. Edit: apparently my TXT record was also lost.

Hello there,

sorry to let you hang for so long, we’re just buried in work for different projects, all screaming for attention.

Given the comments here, I can identify the following issues. I’ve split them up into different threads, to keep the discussion somewhat organized. Feel free to remind/correct me if I’ve forgot/overlooked something or got something wrong!

  1. [solved] AAAA RRs for zones can't be resolved
  2. [wip] Records within a zone get deleted after some time
  3. The HTTP update API (/api/update) seems to require a bogus ipv6prefix parameter.

The last one I cannot confirm:

Whether or not I add &ipv6prefix= to https://dynv6.com/api/update?zone=...&token=...&ipv6=auto, it doesn’t change the outcome. I’ve also tested this with &ipv6=1234::1, and with existing and/or empty records in the zone.

I’ve rolled out an update fixing the first issue:

Empty zones (i.e. those without any AAAA records) will now return the IPv6 prefix as AAAA record.

For me, the AAAA record stopped disappearing.

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.

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