DynamicDNS cannot update "Failed to connect"

Hi there, my public IPv6 address is changing from time to time (at least after every reboot). I'm trying to keep it updated using the DynamicDNS package, but with wget and curl I get the following errors:

 211507       : #> /usr/bin/curl -RsS -o /var/run/ddns/myddns_ipv6.dat --stderr /var/run/ddns/myddns_ipv6.err --interface br-lan --noproxy '*' 'https://<USERNAME>:<PASSWORD>@www.ovh.com/nic/update?system=dyndns&hostname=<DOMAIN>&myip=<IPv6>'
 211510 ERROR : cURL Error: '7'
 211510       : curl: (7) Failed to connect to www.ovh.com port 443 after 3093 ms: Error
[...]
 213201       : #> /usr/bin/wget --hsts-file=/tmp/.wget-hsts -nv -t 1 -O /var/run/ddns/myddns_ipv6.dat -o /var/run/ddns/myddns_ipv6.err --bind-address=<IPv6> --no-proxy 'https://<USERNAME>:<PASSWORD>@www.ovh.com/nic/update?system=dyndns&hostname=<DOMAIN>&myip=<IPv6>'
 213202 ERROR : GNU Wget Error: '4'
 213202       : failed: Address family not supported by protocol.

Interestingly running curl manually works, as long as I don't use --interface br-lan. The same applies to wget as long as --bind-address is not specified or the IPv4 address of br-lan.

<> root@OpenWrt:/var/run/ddns# url="https://${username}:${password}@www.ovh.com/nic/update?system=dyndns&hostname=${domain}&myip=${ip}"
<> root@OpenWrt:~# curl "$url"
good <IP>
<> root@OpenWrt:~# curl --interface br-lan "$url"
curl: (7) Failed to connect to www.ovh.com port 443 after 2955 ms: Error
<> root@OpenWrt:~# wget --bind-address=192.168.175.254 "$url" -o result-good.log -O result-good
<> root@OpenWrt:~# wget --bind-address=$ip "$url" -o result-bad.log -O result-bad
<> root@OpenWrt:~# cat result-good.log
--2024-05-09 21:49:04--  https://<USERNAME>:<PASSWORD>@www.ovh.com/nic/update?system=dyndns&hostname=<DOMAIN>&myip=<IPv6>
Resolving www.ovh.com... 198.27.92.1
Connecting to www.ovh.com|198.27.92.1|:443... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authentication selected: Basic realm="Authenticated Users Only"
Reusing existing connection to www.ovh.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 27 [text/plain]
Saving to: 'result-good'

     0K                                                       100% 2.54M=0s

2024-05-09 21:49:05 (2.54 MB/s) - 'result-good' saved [27/27]

<> root@OpenWrt:~# cat result-good
nochg <IP>
<> root@OpenWrt:~# cat result-bad.log
--2024-05-09 21:48:44--  https://<USERNAME>:<PASSWORD>@www.ovh.com/nic/update?system=dyndns&hostname=<DOMAIN>&myip=<IPv6>
Resolving www.ovh.com... 198.27.92.1
Connecting to www.ovh.com|198.27.92.1|:443... failed: Address family not supported by protocol.

Is there some reason it tries to use --interface and IPv6 address specifically? Is there an option I overlooked, where I can modify the command doing the webrequest? There is no AAAA result for www.ovh.com unfortunately.

For completeness is here my current configuration:

config ddns 'global'
        option ddns_dateformat '%F %R'
        option ddns_loglines '250'
        option ddns_rundir '/var/run/ddns'
        option ddns_logdir '/var/log/ddns'
        option use_curl '1'

config service 'myddns_ipv6'
        option update_url 'https://[USERNAME]:[PASSWORD]@www.ovh.com/nic/update?system=dyndns&hostname=[DOMAIN]&myip=[IP]'
        option lookup_host <HOSTNAME>
        option domain <DOMAIN>
        option username <USERNAME>
        option password <PASSWORD>
        option use_ipv6 '1'
        option interface 'lan'
        option ip_source 'network'
        option ip_network 'lan'
        option enabled '1'
        option use_syslog '2'
        option check_unit 'minutes'
        option force_unit 'minutes'
        option retry_unit 'seconds'

Also fun fact, selecting OVH as service provider reports that IPv6 is not supported. I don't know why this is the case (I assume because there is only an URL configured for IPv4) and whether this can be updated.

Have you tried setting this to '0' ?

1 Like

Is it possible that the IPv6 connection isn't established at the point ddns-scripts tries to determine the IPv6 address?

My ISP has a rather buggy interpretation of the standards and only sends RAs ~15 minutes after the IPv4 connection has been established, which makes me experience multiple failures until (~15 minutes in) it succeeds. But in my case I know why/ who's at fault.

If you are using LAN for DDNS, does that mean that this router is connected to the internet through the LAN interface? Could it be using another interface, when you do not force LAN?

DDNS provider is simply not reachable over v6, they don't have AAAA record themselves.

1 Like

This option determines whether it checks the IPv6 or IPv4 address. As I want to update the IPv6 it needs to be set accordingly.

My examples from above were hours after my router booted and had a working network connection. As mentioned in the OP, I can manually issue the update through wget and curl as long as I don't bind it to an IPv6 address.

It is connected through a DSL modem and PPPoE connection. Running ip -6 a does only yield IPv6 addresses in fe80::/64 except for the br-lan interface. This is why I'm using that interface/network in the configuration.`

Yes, I was thinking from a debug perspective, it may be worth seeing whether ddns would work with IPv4 at the same point relative to your connection going up and down. T

I think you did not answer my question: does this device have a WAN interface, or is it connected to the internet through the LAN interface?

So I got it to work: Previously it the IP address source was set to network with the ip_network set to lan. To change the interface I had the ip_source set to interface with the interface now set to br-lan. Interestingly this seems to have fixed it. The wget call does not contain --bind-address anymore.

To answer the remaining questions: Setting use_ipv6 to 0 did not work, because it wouldn't update the private IPv4 address the network uses. I wanted to change the network to wan but while doing that I discovered the current solution.

And also yes there is a dedicated wan interface/network through which it is connected. I just didn't selected it, as there were no public IPv6 addresses bound to it.