os-ddclient

[depc80]

Please note that 23.7 will kill dyndns (apparently ddclient will be the successor).

23.7 seems like a long way no? We're at 23.1.7 so I guess I can chill for now.

[Patrick M. Hausen]

23.7 seems like a long way no? We're at 23.1.7 so I guess I can chill for now.

23.1 in January 2023, 23.7 in July 2023, ... there won't be 23.[2-6].

[franco]

Yeah, but the experience for many users is: This functionallity has been up and running for YEARS and problems started by "solving problem" that were non-existent to most users of dynDNS.... ;-)

If only we had not bothered to keep it alive at all perhaps you'd be more favourable towards how we would end up here sooner. Personally, I don't want this thankless job of fiddling with DynDNS getting complained at either way. It has to stop.


Cheers,
Franco

[chemlud]

Yeah, but the experience for many users is: This functionallity has been up and running for YEARS and problems started by "solving problem" that were non-existent to most users of dynDNS.... ;-)

If only we had not bothered to keep it alive at all perhaps you'd be more favourable towards how we would end up here sooner. Personally, I don't want this thankless job of fiddling with DynDNS getting complained at either way. It has to stop.


Cheers,
Franco

Hi franco, I asked for an amount of money to fix this once and for ever (one of the various threads we had on this topic over the last year(s?) ), but iirc I never got an answer. For me this would  be the only professional way forward, if the dynDNS functionality is not considered an integral part of a router/firewall for those many, many users without a fixed public IP on WAN... ;-)

I'm looking for solutions, not problems.

[whatever]

Hey, just something that might be helpful for those who use a dynamic dns service that isn't supported/working properly with ddclient.

I use namecheap, which is only supported using 'ddclient' as the backend. But I have a particular setup in which my "default" gateway is a gateway group comprised of three wireguard gateways. Using 'Interface' as the IP check method and selecting WAN, ddclient always detects my wireguard IP, despite WAN being selected as the interface. It would probably work just fine with a more "vanilla" setup.

Anyway, what I ended up doing and which may be helpful to others, is using dns-o-matic. It's more of a "meta" dynamic dns service in that it can update your IP at your dynamic dns service without you having to switch your dynamic dns provider. I created an account with dns-o-matic. And using dns-o-matic (and configuring ddclient to use dns-o-matic rather than namecheap) detects the correct IP and everything works properly and my IP is updated in my namecheap dashboard. It's not the ideal solution but it works.

Maybe everyone already knows this and I just stated the obvious. But I didn't know and it helped me out.

Cheers

[depc80]

23.7 seems like a long way no? We're at 23.1.7 so I guess I can chill for now.

23.1 in January 2023, 23.7 in July 2023, ... there won't be 23.[2-6].

Damn.

Anyway, I got both IPv4 and IPv6 update by changing backend to OPNsense and use ip4only.me, nsupdate-info.ipv6 for Check IP method instead of interfacev4 & v6.

Btw @franco ip6only.me is a dead site, it is ip6.me i think.

[franco]

Btw @franco ip6only.me is a dead site, it is ip6.me i think.

Both seem to work from here.


Cheers,
Franco

[depc80]

You're right. My bad, I didn't notice at first. ZA put it in dead site category and block it.

[TarteTatin]

Hi,

I tried to move from a Cloudflare-ddns Docker container to os-ddclient, but I can't make it work at the moment.

I have several domain names to update, on the same Cloudflare account, and my Cloudflare API token includes all zones of this account.

So each of my domain names is configured as such:
- Service: Cloudflare
- Username: <empty>
- Password: <cloudflare_account_api_token>
- Wildcard: unchecked (I only want to update my domain names, because I use CNAMES for subdomains)
- Zone: <example.com>
- Hostname(s): <example.com> (exactly like Zone)
- Check ip method: Interface
- Interface to monitor: WAN_832 (device: vlan0.832, like this configuration https://docs.opnsense.org/manual/how-tos/orange_fr_fttp.html)
- Force SSL: checked

I tried at first to update all my domain names in the same Cloudflare service, like what I was doing in a cloudflare-ddns Doker container, but I get a lot of errors. So I have separated the domain names like the configuration above, one entry for each, but I see no "Current IP", nor "Updated" in the Dynamic DNS service.

In the logs, I get the same Notice every five minutes:

Code: [Select]

2023-05-22T23:21:31 Notice ddclient[33961] 94731 - [meta sequenceId="3"] FAILED: Unable to obtain information for 'vlan0.83' -- missing ip or ifconfig command
2023-05-22T23:21:31 Notice ddclient[33961] 93072 - [meta sequenceId="2"] FAILED: Unable to obtain information for 'vlan0.83' -- missing ip or ifconfig command
2023-05-22T23:21:31 Notice ddclient[33961] 92075 - [meta sequenceId="1"] FAILED: Unable to obtain information for 'vlan0.83' -- missing ip or ifconfig command
Two things:
- the device is "vlan0.832", but the logs specified "vlan0.83", like if it is truncated
- my WAN_832 as an IPv4, but no IPv6. Only an IPv6 delegated prefix which is tracked by my LAN interfaces.

In the Cloudflare interface, the API-token is refreshed all fives minutes, so there is a communication.

Thanks for your help.

[bringha]

Hi,

As a preparation for 23.7 and migrating from legacy dyndns to ddclient, I experimented today a bit around with both ddclient backends (ddclient and the new opnsense) and dyndns2 protocol. I am with desec and I brought it up and running with the ddclient backend and the config as described here

https://forum.opnsense.org/index.php?topic=26446.msg134975#msg134975

Basically it works, however every second update cycle, an update is said to be performed successfully which does not take place according to the desec DNS logs. ddclient logs look like this:

Code: [Select]

<29>1 2023-06-08T00:53:49+02:00 OPNsense.zuhause.xx ddclient[61106] 34054 - [meta sequenceId="3"] WARNING:  Wait at least 5 minutes between update attempts.
<29>1 2023-06-08T00:58:49+02:00 OPNsense.zuhause.xx ddclient[61106] 29212 - [meta sequenceId="1"] SUCCESS:  updating crandale.dedyn.io: good: IP address set to 87.XXX.XXX.140
<29>1 2023-06-08T01:03:49+02:00 OPNsense.zuhause.xx ddclient[61106] 50446 - [meta sequenceId="1"] WARNING:  skipping update of crandale.dedyn.io from <nothing> to 87.XXX.XXX.140.
<29>1 2023-06-08T01:03:49+02:00 OPNsense.zuhause.xx ddclient[61106] 50446 - [meta sequenceId="2"] WARNING:  last updated Thu Jun  8 00:58:49 2023 but last attempt on Thu Jun  8 00:58:49 2023 failed.
Could not yet find out why a SUCCESS for an update is noted in the logs which desec is not confirming.

I then tried the new python opnsense backend of ddclient and the result looks very encouraging:

I added simply two new lines into /usr/local/opnsense/scripts/ddclient/lib/account/dyndns2.py (line 37/38)

Code: [Select]

     35     _services = {
     36         'dyndns2': 'members.dyndns.org',
     37         'desec(v4)': 'update.dedyn.io',
     38         'desec(v6)': 'update6.dedyn.io',
     39         'dns-o-matic': 'updates.dnsomatic.com',

The configuration for desec and the opnsense backend look then like this:

- Services: Dynamic DNS: Settings: General Settings
Enabled [X]
Verbose [X]
Allow Ipv6 [X]
Interval [300]
Backend [OPNsense]

I added 2 services under the same desec account:

- Services: Dynamic DNS: Settings: Edit Account
Enabled [X]
Service [desec (v6)]
Protocol  [DynDNS2]
Username [Your Domain]
Password [Your DeSec Token]
Hostname(s) [Your Domain]
Check ip method [Interface [IPv6]]
Force SSL [X]
Interface to monitor [Your WAN Interface]

- Services: Dynamic DNS: Settings: Edit Account
Enabled [X]
Service [desec (v4)]
Protocol  [DynDNS2]
Username [Your Domain]
Password [Your DeSec Token]
Hostname(s) [Your Domain]
Check ip method [Interface [IPv4]]
Force SSL [X]
Interface to monitor [Your WAN Interface]

After activating, the ddclient logs look like

Code: [Select]

<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="4"] Account yyyyyyyyyy-18d2-47a7-b45a-4468975dc2e7 [desecv6 - dedyn]  set new ip 2003:XXXX:XXXX:XXXX:XXXX:efff:fe57:21ce [good]
<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="5"] Account yyyyyyyyy-18d2-47a7-b45a-4468975dc2e7 [desecv6 - dedyn]  changed
<165>1 2023-06-08T16:45:53+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="6"] Account zzzzzzzzzz-f19d-4b4e-98a8-1bf71b62ee24 [desecv4 - dedyn]  execute
<163>1 2023-06-08T16:45:59+02:00 OPNsense.zuhause.xx ddclient 60835 - [meta sequenceId="7"] Account zzzzzzzzzz-f19d-4b4e-98a8-1bf71b62ee24 [desecv4 - dedyn]  failed to set new ip 87.XXX.XXX.236 [429 -
Request was throttled. Expected available in 55 seconds.]

After the mentioned 55sec, also the ipv4 address is visible at desec as an A record.

Means desec is bacically working on the new OPNsense backend for ipv4 AND ipv6 with some very simple and straight extensions to the dyndns.py code; only oddity is the throttling of the sequential request to the same desec account for v4 and v6 which allows obviously only one update per minute. Perhaps there is a possibility to add an additional throttling config item into the new opnsense backend code.

Several reboots and reconnects leading to different ipv4 and ipv6 addresses confirmed that it is working.

I think that this example could open potentially a pretty fast integration path for some more dyndns2 based service providers into the new opnsense backend python code and facilitate therewith at least in parts a catch up to the legacy dyndns solution as far as support of providers is concerned. Indeed there are many non dyndns2 providers for which more code needs to be written.

If this report is perceived positive perhaps it could be taken into the mainstream code base or you let me know how I could do this.

Br br

[franco]

@br let's discuss in your separate thread https://forum.opnsense.org/index.php?topic=34388.0