search

openwrt / luci

LuCI - OpenWrt Configuration Interface
Apache License 2.0
6.26k stars 2.5k forks source link

DDNS and ACME #6417

Closed stokito closed 1 year ago

stokito commented 1 year ago

The ddns-scripts calls a DNS API to update the domain's record and the acme.sh DNS API does the same too so we have a duplicated API implementation. IMHO it's better to delegate this to acme.sh. Anyway users needs for TLS when exposing to internet. So when configuring a DDNS we should show to a user a checkbox "Enable TLS" that will configure the acme.sh.

I even think that the acme.sh itself may be turned into a DDNS client. This would be a small addition but may simplify a lot of things. Because today we have few ddns clients but they ether too big for routers and written in Perl or almost unmaintained. Ideally we need a one universal package that can be used in Debian, on RapsberyPI and OpenWrt.

The acme.sh has a support of many DNS providers but only for adding a TXT record. Maybe we can extend it to support A/AAAA records

jow- commented 1 year ago

What DDNS implementations are used by other firmware projects like Tomato, Gargoyle, DDWrt or even OEM firmwares?

We do have ddns-scripts but it feels heavy and very complex. In the past we used to have yaddns but that fell out of favor.

stokito commented 1 year ago

The yaddns is written in C and outdated.

OEM firmwares that I saw supports only dyn.com (which is just one GET request e.g. DynDNS v2 API) or no-ip.com.

Today from the DDNS providers that are free to use really only DuckDNS, dynv6 and ipv64.net are working. The only one Open Source is nsupdate.info but registration is disabled. Some routers like Gl.Inet or Keenetic provides their own DDNS service. The Keenetic also installs the Letsencrypt in a configuration wizard:

le

I think that OpenWrt should just work the same: provide a free DDNS out of the box and issue a cert.

All others DDNS that I tried are either dead or just better not to use. Good news that all Real DNS APIs that needs for a custom scripts are extracted to a separate packages:

So the packages may be replaced with the acme.sh dns apis (but it needs to implement addition on A/AAAA records).

Ideally it should be implemented in other way: make all DNS providers to implement the DynDNS v2 API + TXT adding for ACME. So that different packages won't be needed.
See DNS API standard or specification

Anyway, it looks like nothing to do here from LUCI perspective. The only one thing that we can do is to add a check "Enable HTTPS/TLS" on the DDNS page for services that are supported by the acme.sh.

I'll close the ticket.