ddclient: T5708: Upgrade to ddclient 3.11.1

[indrajitr]

Change Summary

• Migrate to ddclient 3.11.1 and enforce debian/control dependency
• Add dual stack support for additional protocols
• Restrict usage of porkbun protocol, VyOS configuration structure isn't compatible with porkbun yet
• Improve and cleanup error messages
• web-options is only applicable when using HTTP(S) web request to obtain the IP address, apply guard for that
• Time interval in seconds to wait between DNS updates would be a bit more intuitive as interval than timeout

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://vyos.dev/T5708

Related PR(s)

• ddclient: T5708: Upgrade to ddclient 3.11.1 vyos-build#453

Component(s) name

dns dynamic

Proposed changes

How to test

set service dns dynamic interval 600

set service dns dynamic address eth5 service cloudflare host-name 'dyn.example.com'
set service dns dynamic address eth5 service cloudflare ip-version 'both'
set service dns dynamic address eth5 service cloudflare password 'scrambled_string'
set service dns dynamic address eth5 service cloudflare protocol 'cloudflare'
set service dns dynamic address eth5 service cloudflare ttl '300'
set service dns dynamic address eth5 service cloudflare zone 'example.com'

set service dns dynamic address eth5 service namecheap host-name '@.example.com'
set service dns dynamic address eth5 service namecheap username 'example.com'
set service dns dynamic address eth5 service namecheap password 'scrambled_string'
set service dns dynamic address eth5 service namecheap protocol 'namecheap'

Smoketest result

vyos@vyos15a:~$ /usr/libexec/vyos/tests/smoke/cli/test_service_dns_dynamic.py
test_01_dyndns_service_standard (__main__.TestServiceDDNS.test_01_dyndns_service_standard) ... 
"zone" is not supported for Dynamic DNS service "freedns" on "eth0" with
protocol "freedns"


"ttl" is not supported for Dynamic DNS service "freedns" on "eth0" with
protocol "freedns"


"ttl" is not supported for Dynamic DNS service "zoneedit" on "eth0" with
protocol "zoneedit1"


"ttl" is not supported for Dynamic DNS service "zoneedit" on "eth0" with
protocol "zoneedit1"

ok
test_02_dyndns_service_ipv6 (__main__.TestServiceDDNS.test_02_dyndns_service_ipv6) ... 
"expiry-time" must be greater than "wait-time"

ok
test_03_dyndns_service_dual_stack (__main__.TestServiceDDNS.test_03_dyndns_service_dual_stack) ... 
Both IPv4 and IPv6 at the same time is not supported for Dynamic DNS
service "google" on "eth0" with protocol "googledomains"

ok
test_04_dyndns_rfc2136 (__main__.TestServiceDDNS.test_04_dyndns_rfc2136) ... ok
test_05_dyndns_hostname (__main__.TestServiceDDNS.test_05_dyndns_hostname) ... ok
test_06_dyndns_vrf (__main__.TestServiceDDNS.test_06_dyndns_vrf) ... ok

----------------------------------------------------------------------
Ran 6 tests in 1384.026s

OK

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[indrajitr]

Quick question to reviewers:

As you can see here there is now an additional guard to prevent setting up web-options when interface is used to detect IP address (because web-options aren't useful in such cases).

This would prevent users from doing something like:

set service dns dynamic address eth5 web-options url https://domains.google.com/checkip

but this would be allowed (web request to obtain the IP address):

set service dns dynamic address web web-options url https://domains.google.com/checkip

Would this be considered too intrusive a validation? I am undecided because I couldn't find a pattern or consensus in the codebase on what the 'best practice' is. (for example, set interfaces ethernet eth5 dhcpv6-options is allowed even if the interface eth5 doesn't have address dhcpv6).

Based on the feedback, I can either keep it or just remove it (and retain the present behavior with less stringent validation).

[c-po]

You have added a migrator for dns dynamic, you also need to bump the version number here: https://github.com/vyos/vyos-1x/blob/current/interface-definitions/include/version/dns-dynamic-version.xml.i

[c-po]

Please also add a PR for vyos-documentation as you updated the syntax

[c-po]

Would this be considered too intrusive a validation?

I like the idea and would like to see an implementation. There are only two questions:

• Did this ever worked in the past? Or was it only allowed by the CLI?
• If it was only allowed by the CLI and never worked out properly, please remove the nodes in your migration script, else users having this invalid configuration will get upgrade issues.

[indrajitr]

You have added a migrator for dns dynamic, you also need to bump the version number here: current/interface-definitions/include/version/dns-dynamic-version.xml.i

Sorry, missed this one. Updated now.

Please also add a PR for vyos-documentation as you updated the syntax

I'm working on a full documentation update for all the ddclient related changes in last few months. PR should be there in a couple of days.

Would this be considered too intrusive a validation?

I like the idea and would like to see an implementation. There are only two questions:

• Did this ever worked in the past? Or was it only allowed by the CLI?

Here is the implementation (commit is part of this PR). This never worked and was allowed by the CLI only - but was discarded while building the ddclient.conf

• If it was only allowed by the CLI and never worked out properly, please remove the nodes in your migration script, else users having this invalid configuration will get upgrade issues.

Yes, the migration script here will remove the vestigial path from the existing configuration.

[indrajitr]

@dmbaturin thank you for merging the PR. A related PR vyos/vyos-build#453 also needs to be applied for some of the protocols to behave correctly.