You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 AAAA2001:db8::9_ssh.myhost.dyndns.example.com IN SVCB10 tmpssh.myhost.dyndns.example.com port=9022tmpssh.myhost.dyndns.example.com IN A13.14.15.16myhost.dyndns.example.com IN HTTPS10 tmphttps.myhost.dyndns.example.com port=9743tmphttps.myhost.dyndns.example.com IN A13.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.
The text was updated successfully, but these errors were encountered:
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)
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:
https:443
, but maybe also SSH once spec'd there)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:
... 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:
The text was updated successfully, but these errors were encountered: