I have been using desec.io dyndns service for over a year without problems from my IPv4 only residential line.
Recently, I got IPv6 support on my residential line. Since then, my dyn dns stopped working… That is: services hosted on my residential line did no longer respond… I debugged this down to the fact that dyn dns seems to now resolve to my IPv6 address and no longer my IPv4 address.
I suppose this happens because my update call (curl "https://update.dedyn.io/?hostname=${hostname}" --header "Authorization: Token ${token_usage}") seems to come from my IPv6 address because an IPv6 route to update.dedyn.io is availalbe…
Is there a way to either force the dyndns to IPv4 or alternatively to have it resolve to both somehow? (not sure how that would work? Possibly by setting both an A and an AAAA record?)
For now I have disabled IPv6 but I would really like to be able to use this…
Use two curl calls, one IPv4 only, the other IPv6 only, both with the preserve option.
Set the IPs in the update URL
The second one is a little bit nicer, since you only have to make one call and it will also delete your A or AAAA record, in case your host looses IPv4 or IPv6 for whatever reason.
If you need a simple shell script for the second option, here is a shameless plug of my script that is looking for testers besides fiwswe
Another option would be to use my script, which basically does the same as the curl above, with the difference that it checks for changes and only then issues the update curl.
If you can find the addresses locally and set them like @KapernMagIchNicht described, then that is more secure. In case someone can NAT your traffic, that attacker can make your update request appear to come from a different address and redirect your inbound traffic via your dynamic DNS that way. The encryption doesn’t prevent that kind of manipulation if the address isn’t sent with the update request and has to be derived from the client’s source address.
@LydolfSleipner you can set ipv4 only if your ipv6 setup is not working. Just include ipv6= (empty value) in the url of the curl call and include the ip parameter with your actual current ipv4 address. This would work no matter the route your request is taking.
I did not try this approach, it’s my understanding from the documentation.
Edit: Oh, and with your approach of forcing curl to using a v4 route, you could probably skip the ip parameter. So only the first of your proposed requests, but with the parameter&value ipv6=:
I just read through your script. However, it is unclear to me whether I am supposed to set these to YES or not.
PRESERVE_IPV4='NO'
PRESERVE_IPV6='NO'
I am thinking if I set them both to YES, they will not update the IP address at all. At least that is how I read it… But they should update both. It is just that IPv6 should only set the AAAA record and IPv4 should set the A record. But both records should end up being there. AND they should both be updated regularly as the dynamic IP might change…
Since you want to update them both, leave them both at no.
That is correct.
Ahh I see where you are coming from.
The default behavior is to leave them both at no. That way it updates both.
You only need to set it to yes in certain situations.
For example, you have bought a static IPv4 and only want to check IPv6, set it to preserve for IPv4. Or more realistic, you manually set a IPv6 IP in the webGUI to point to your static IPv6 host, but you are using the script on a different host or a host without IPv6, by setting it to preserve, it won’t touch and won’t override what you did in the webGUI.
Hope this makes it a little bit more clear. Maybe I should think of a better naming than “preserve”. I used that, because that is what deSEC calls it.
Maybe “disable_IPv4_check” or something like that would make it more clear. What do you think?