AAAA record got lost

Same here. AAAA records get lost multiple times a day and recover after a while. During the failure, resolving a host does just return an A record even though the IPv6 prefix is configured.

Same behavior here w/ AAAA record.
Changes to the IPv6 address manually in the web interface are ignored. Only solution is to delete and recreate the zone.
Name resolution of AAAA records fails multiple times each day. Tested w/ ns[123].dynv6.com.

And just a day later, it was gone again for me :frowning:

Anybody know of a good alternative service to dynv6?

At this point it happens to me on a daily basis.
Instead of just comparing my old and current IP and only then call the update-API, I now check DNS entries also. There´s still blind spots but at this point it´s better than nothing.

I´d really appreciate a reply by someone working on it.

got the same issue here… may be it’s a bug?

A free alternative to dynv6 is https://www.ddnss.de/index.php. A simple API is available to allow automatic updates via commandline.
I don’t know yet how reliable the service is but it worth a try.

1 Like

Same problem here. Using the provided CLI-script. Zone is updated, AAAA is there and after random time AAAA disappears

right now dynv6 is useless for me

1 Like

Same problem here. I’ve got four zones, all updated via API. All AAAA records get lost after a few seconds, even after manually update.

Is any admin of dynv6 in this thread - nothing official to hear about this massive issue …

Same problem here! It worked pretty well until now.

Same issue here, hope it can be fixed soon!

+1
The same issue.
any workaround?

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?

2 Likes

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.