AAAA record got lost

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, 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"}' \

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

`curl -sS --fail \
-H “Authorization: Bearer $TOKEN” \
-H “Accept: application/json” \$ZONEID/records \
| jq ‘.[] | select (.type == “A”) | select (.name == "’$HOST’") | .name ’ \
| wc -l`

if [ “$OK” -eq “0” ]
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”: “”}’ \$ZONEID/records
---------------------------------- >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, “” becomes “”. So the respective records of both zones appear alphabetically close to each other.
Result: Each time “” disappears, its companion “” 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.


#Poll all records of a zone at dynv6, restore missing ones

TOKEN= # insert your token here
ZONEID= # insert your zoneid here
if [ X != X$1 ]
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” \$ZONEID/records \
| jq ‘.’ \

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
echo “Abort”

#Identify missing records and restore them
for HOST in “${RECORDS_A[@]}”
OK=`jq ‘.[] | select (.type == “A”) | select (.name == "’$HOST’") | .name ’ $TEMPFILE | wc -l` # must be >= 1

if [ “$OK” -eq “0” ]
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”: “”}’ \$ZONEID/records

for HOST in “${RECORDS_AAAA[@]}”
OK=`jq ‘.[] | select (.type == “AAAA”) | select (.name == "’$HOST’") | .name ’ $TEMPFILE | wc -l` # must be >= 1

if [ “$OK” -eq “0” ]
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’”}’ \$ZONEID/records

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!

for me too.

The AAAA-record disappeared yesterday.


@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.