ddns-scripts: add Dynway provider - #30385
Conversation
Add a DynDNS2 provider definition for dynway.eu. Both IPv4 and IPv6 use dynupdate.wayscloud.services/nic/update with HTTP Basic authentication and standard good/nochg status responses. Bump PKG_RELEASE so existing installations receive the provider definition. Signed-off-by: Knut Michael Haugland <hostmaster@wayscloud.net>
3ed54e2 to
48323b0
Compare
openwrt-ai
left a comment
openwrt-ai
left a comment
There was a problem hiding this comment.
Reviewed 1 new commit. Nothing here blocks a merge — the single inline note is an optional question about the URL scheme.
Checks that came back clean:
PKG_RELEASE2 → 3 is correct: the new JSON changes whatddns-scripts-servicesships, andPKG_VERSIONis unchanged.- No Makefile install hunk is needed —
Package/ddns-scripts-services/installglobs./files/usr/share/ddns/default/*, anddynway.eu.jsonis not one of the "special services" that getrm'd into a dedicated subpackage. - The
listentry is correctly placed:dynway.eusorts betweendynv6.comandeasydns.com, and the file is the "service on demand" manifest fetched at runtime byddns.shfrom raw.githubusercontent — so it is right that it is not installed by the Makefile, and right that a plain (non-dedicated-package) provider appears in it. - The JSON parses, uses tabs like its neighbours, and matches the
dyndns.org.jsonDynDNS2 template exactly,"answer": "good|nochg"included (56 other definitions use that same answer string, and it is matched withgrep -i -E, so the alternation is fine). - Commit subject scope
ddns-scripts:matches the touched files, and the body accurately describes the diff. - All three FormalityCheck runs are green on
48323b0.
The identical myip=[IP] on both the ipv4 and ipv6 entries mirrors dyndns.org.json and is called out explicitly in the commit message, so I did not flag it — just confirm the endpoint really does accept an IPv6 literal in myip rather than needing a separate myipv6 parameter.
Generated by Claude Code
| { | ||
| "name": "dynway.eu", | ||
| "ipv4": { | ||
| "url": "http://[USERNAME]:[PASSWORD]@dynupdate.wayscloud.services/nic/update?hostname=[DOMAIN]&myip=[IP]", |
There was a problem hiding this comment.
Optional / non-blocking, but worth a decision: with http:// the Basic-auth credentials sit in the URL userinfo and go out in cleartext by default. The PR description notes that the HTTPS option upgrades the endpoint, but that option is opt-in — use_https=0 in dynamic_dns_updater.sh:152 — and the rewrite at dynamic_dns_functions.sh:844 only fires when the user enables it. So the out-of-the-box path for a fresh dynway.eu config sends the password unencrypted.
Both patterns exist in the tree, so this isn't a convention violation: ~29 definitions use http://[USERNAME]:[PASSWORD]@, but a dozen hardcode HTTPS — the closest sibling being now-dns.com.json, which is byte-for-byte this shape with https://. The tradeoff for hardcoding is that HTTPS needs a CA bundle (or no_cert_check) on the device, whereas http:// works on a bare install.
Since dynway.eu is a brand-new provider with no legacy HTTP-only clients to keep working: does dynupdate.wayscloud.services serve HTTPS with a publicly-trusted certificate? I couldn't reach the host from this environment to confirm, so I'm asking rather than prescribing. If it does, https:// here (and on line 8) would make the default configuration safe. Same question applies to the ipv6 URL below.
Generated by Claude Code
3 participants
Add a DynDNS2 provider definition for dynway.eu.
The service supports IPv4 and IPv6 through
dynupdate.wayscloud.services/nic/updatewith HTTP Basic authentication and uses the standardgoodandnochgresponse values. The existing HTTPS option upgrades the endpoint to HTTPS.