`HTTPS`-RR-only mode

[chrysn]

With HTTPS RRs (RFC9460) now supported at least in Firefox-when-DoH-is-used, using DynDNS might become viable in NAT and firewall scenarios without manual firewall rules: A host can run PCP to ask its firewall(s)/NAT(s) to allow inbound connections or packets to a particular port, and the firewall tells it the public address and port (not necessarily the same -- esp. port 443 is easily overbooked) used for the host.

If the DynDNS service supports it (at least nsupdate can), it ddclient could:

• be configured in extension with ports and their service names (typically https:443, but maybe also SSH once spec'd there)
• run PCP (eg. through portcontrolcd) to obtain forward addresses
• if there is a consistent forward address for all requested ports, and the ports are all unmodified, set the A/AAAA records
• if not, set HTTPS and other SVCB records.

For example, if PCP for SSH gave 13.14.15.16:9022 and [2001:db8::9]:22, and for HTTPS gave 13.14.15.17:9743 and [2001:db8::9]:443 (i.e., PCP gave consistent addressess for IPv6 and arbitrary ones for IPv4), the records to be created would be:

myhost.dyndns.example.com IN AAAA 2001:db8::9
_ssh.myhost.dyndns.example.com IN SVCB 10 tmpssh.myhost.dyndns.example.com port=9022
tmpssh.myhost.dyndns.example.com IN A 13.14.15.16
myhost.dyndns.example.com IN HTTPS 10 tmphttps.myhost.dyndns.example.com port=9743
tmphttps.myhost.dyndns.example.com IN A 13.14.15.17

... and browsers both from v4-only and from IPv6 networks could both connect to a host just by going to https://myhost.dyndns.example.com, even though the host is behind CGNAT and did no configuration on the firewall.

(I don't know the operational considerations for RFC9460 well enough to answer whether there should also be records _ssh.myhost.dyndns.example.com IN SVCB 9 myhost.dyndns.example.com to not force an IPv4 downgrade, or whether that's redundant when the presence of the AAAA record on the main name)

[edit: The example doesn't look like the HTTPS-RR-only mode mentioned in the title -- but if there were no IPv6 connectivity, or the v6 ports were scrambled as well, then there would be no A/AAAA records for the proper name at all, and just HTTPS/SVCB records pointing to the auxiliary records.]

---

Is this something the ddclient project would be interested in adding, or is that better left for a special-purpose tool?

To my understanding there are arguments for both sides:

• It's a large chunk of new stuff, so a dedicated tool would be better.
• That tool would duplicate a lot of configuration and code from ddclient, as there is already a good roster of supported back-ends here.

[Lenard Hess]

Hey there!

on first glance this looks like something that could be added. The exact workings of it would still require me to look deeper into it. I also have no idea how to fit this into the config format or implementation.

From what I understand ddclient would need to:

• Have a configuration of service -> PCP tool/arguments mappings
• From the PCP result:
  • Grab the IP for the A/AAAA record
  • Grab the port for the SVCB record

Where a service consists of (using your example values here):

• A subdomain (e.g. _ssh.myhost.dyndns.example.com)
• The port number where that service runs on (e.g. 22)

And the PCP tool/arguments consist of:

• PCP server info
  • Address
  • Login/Password/Token

The PCP tool then returns for each service requested:

• Remote IP (e.g. 13.14.15.16)
• Remote Port (e.g. 9022)

Then ddclient sets:

• A/AAAA record with:
  • The remote IP (e.g. 13.14.15.16)
  • The service's target domain (e.g. tmpssh.myhost.dyndns.example.com)
• SVCB records with:
  • The service subdomain (e.g. _ssh.myhost.dyndns.example.com)
  • The remote port (e.g. 9022)
  • The target domain (e.g. tmpssh.myhost.dyndns.example.com)