troglobit
Desec fails to update IPv4 and IPv6 simultaneously and returns error
I am using the desec.io plugin. This is my inadyn.conf:
period = 300
forced-update = 86400
allow-ipv6 = true
provider [email protected] {
username = "xxx.dedyn.io"
password = "xxx"
hostname = {"xxx.dedyn.io"}
ssl = true
}
provider [email protected] {
username = "xxx.dedyn.io"
password = "xxx"
hostname = {"xxx.dedyn.io"}
ssl = true
}
If I comment out [email protected] or [email protected] everything works fine. Using both entrys results in "Error code 48: DDNS server response not OK" for the second update (ipv6). Looks like a rate limit.
What could be the problem?
It's version v2.12.0 on docker (image: troglobit/inadyn:latest) , network_mode: host. Both public ips are correctly detected and displayed.
I suspect you are right, at least the API seem to indicate this.
Unfortunately In-a-Dyn is quite limited when it comes to the IPv6 support, for most DDNS providers you currently have to keep separate configs, like you have. In the case of your provider this hits the rate limiting. There's no workaround.
The way to solve it in In-a-dyn is a big refactor of the plugin to be able to use the provider's syntax: https://update6.dedyn.io/?hostname=<your domain>&myipv4=1.2.3.4&myipv6=fd08::1234
Thank you so much for your time and answering my question. I have now tried ddclient with docker. If you specify the cache file ddclient works. Too bad that dedyn is so strict with the rate limit, would have liked to keep inadyn :(
Glad to hear you got it working!
I'm reopening this since it's still an issue in inadyn.
I can take care of this maybe @troglobit , but i cannot test it since i don't have an IPV6 address. My (rather ugly solution) would be to simply add a section for IPV4 & IPV6 that update at the same time for IPV4 + IPV6 users.
Appreciated, but I'm not sure we should make the situation worse by adding another level of complexity.
I'm not really happy about the new ipv6@ sections that are basically just a copy of the default@. While I understand any custom IP check command would, in the current state of things, warrant a separate section, for this current issue (which I believe is the common one) we would have benefited from an ipv6 = true setting, or similar in default@.
the rate limit is not a big thing. the code may just update one of the both entries. ipv4 for instance, but it repeats the unsuccessfull ipv6 10 minutes later. so both gets updated
The code may just as easily not update any entry, which from my limited testing seems to be the case.
The code may just as easily not update any entry, which from my limited testing seems to be the case.
for me it does. but only if return code signals a rate limit. it simply retries outstanding updates
example
- updates ipv6 address first
- updates ipv4 address, but returns retry limit error
- waits 600 sec.
- updates ipv4 again. succeeds
here a log from a ddns attempt
Update forced for alias shellfast.d.dd-wrt.ch, new IP# xxxx:xx:xxxx:xxxx:xxxx:xxx:xxxx:xxxx Update forced for alias shellfast.d.dd-wrt.ch, new IP# xx.xx.xx.xx Updating IPv6 cache for shellfast.d.dd-wrt.ch Temporary error in DDNS server response: DDNS warning, your update interval is set too low. Will retry again in 600 sec ... Update forced for alias shellfast.d.dd-wrt.ch, new IP# xx.xx.xx.xx Updating IPv4 cache for shellfast.d.dd-wrt.ch
this is done using the following config
period = 900 forced-update = 864000 allow-ipv6 = true provider [email protected] { username = "" password = "****************" hostname = {"shellfast.d.dd-wrt.ch"} ssl = true checkip-command = "/sbin/service checkwanip main" } provider [email protected] { username = "" password = "************" hostname = {"shellfast.d.dd-wrt.ch"} ssl = true checkip-command = "/sbin/service checkwanip main" }