Service problems? split brain situation?

#1

When visiting https://dynv6.com I often get Server Errors (500) with the message

We’re sorry, but something went wrong.

If you are the application owner check the logs for more information.

When using the update api via HTTP get request I sometimes get invalid authentication token and sometimes it works. This is with the same $token and $hostname.

Yesterday I rebooted and later reconnected my router. Only the IPv4 address changed during both reconnects, my IPv6 prefix did not. The DNS record for the IPv4 address was changed via the GET api, which I verified via the web interface. Now the strange part:

  • If I query some DNS servers outside (1.1.1.1, 8.8.8.8) for the A record I sometimes get the old address and sometimes the new address. That could be propagation but
  • When querying the SOA ns1.dynv6.net for the A record I still get the old IP address.

My query is usually

dig -t SOA raumzeitfalter.dynv6.net
dig -t A @server raumzeitfalter.dynv6.net

where server is replaced with the SOA or one of the multiple DNS servers I have tried.

1 Like
#2

Similar problems here.

  • https://dynv6.com displaying errors, disabled ipv6 on my side, now loading via ipv4
  • DynDNS authentication failures on update
  • ns1.dynv6.net returning other ip addresses (seem to be outdated ones) than displayed on website
  • other dns (8.8.8.8) sporadically returning no results for A records, AAAA records not working at all
#3

We had issues with out GaleraDB cluster, that just have been solved.

AAAA record got lost
#4

I can confirm that the issue is gone. After a reconnect that gave a new v4 address

  • the record was updated by the next timer run (minutely) on the website
  • the authoritative name server picked up the change directly
  • propagation to other DNS resolvers was really fast

Thanks a lot! :+1:

#5

Thanks a lot :sunglasses:
DNS is working again here.

Thank you for this great and free service anyway.

#6

First I’d like to thank you, too. Great free service! :+1: And fitting perfectly to my needs.
I also experienced problems in resolving my zones the last day, depending on the nameserver I was using
(e.g. one.one.one.one or dns.google). But at some point in time none of them worked anymore.
So finally the impact of your “issue” had propagated everywhere, I guess.
Only fixing it on your side did solve the original problem, but didn’t resolve its impact.
Additionally I had to acquire a new ip address (here: reconnection of dsl router) and more or less immediately the things got synced again. (I think this is the fastest/ easiest way to tell your system to re-destribute all the zones?)
My question is: If you already know that it’s necessary for quite all of us to resync (resurrect) the zones, isn’t there a way for you to quickly and without effort trigger this programatically on your side?
I think of one button to press for you instead of having some headache for many?

Sorry, this was written without having too much knowledge about DNS and behind, but hopefully you got my idea. :slight_smile:

Cheers!

#7

same problems … :frowning_face:

#8

The same issue reappeared today.

From my nsupdate log, this problem may have appeared before 20 o’clock Aug 6, 2021 (UTC).

2 Likes
#9

Was the service down during the weekend? I couldn’t even log in to report it here. Everything seems to work now - thanks!

2 Likes
#10

Saw the same problem too.
The whole week-end I was getting:

We’re sorry, but something went wrong.

If you are the application owner check the logs for more information.

And any attempt at updating the addresses over the “update” https url using the token gave:

invalid authentication token

Everything seems back since yesterday.