Updating multiple domains not working

Hi.

I recently registered with dyden.io

I have an nginx proxy manager running and redirecting to various services on my NAS/homelab determined by the subdomain such as .machara.dedyn.io

Since I have multiple subdomains I configured a wildcard (*) subdomain beside the main one. Unfortunately it seems like the update service of dedyn.io is very finecky.

I tried updating multiple domains with one call in the hostname parameter, or providing two hostname parameters, both is official standard http behaviour:

curl -v -u machara.dedyn.io: \
https://update.dedyn.io/?hostname=machara.dedyn.io&hostname=*.machara.dedyn.io&myipv4=$(curl -s https://api4.ipify.org)”

Something like this works, but only the last parameter is used, the first is ignored.
Using
curl -v -u machara.dedyn.io: \
https://update.dedyn.io/?hostname=machara.dedyn.io,*.machara.dedyn.io&myipv4=$(curl -s https://api4.ipify.org)”

returns nohost.
The only way is to send two different requests.

I use the linux package ddclient (on debian 12 in an LXC) to update.
Unfortunately when two domains are in the config file it does not send two requests but sends them as two values in the hostname parameter.

Has anyone else stumbled across this issue?
Does anyone know if it is somehow possible to do multiple domain updates in one request, or tell ddclient to send individual requests?

Btw: I already tried using a CNAME entry instead of another A entry with subdomain.
This does not work properly together with the certificates of my nginx proxy manager.

Thanks, Machara

Hi Machara,

Thanks for your message, and welcome to deSEC! :slight_smile:

This feature is being worked on, see: https://github.com/desec-io/desec-stack/pull/1112 It’s expected to land in the next few weeks. To stay up to date, you can subscribe to that PR on GitHub.

Stay secure,
Peter

1 Like

Thank you very much.
It’s good to know this should be resolved hopefully soonish.
I’ll keep checking in on the status.

This just got deployed.

Note, however, that in cases where authentication involves the domain name, one domain name must be provided. For example, when making a GET request without an Authorization: header, you’d need to provide a username parameter with your domain name, a password parameter with your token, and then specify the actual list of (sub)domains to update in the hostname parameter.

We’ll consider relaxing the authentication requirement based on feedback we receive – so if you have any, that would be appreciated.

Stay secure,
Peter

1 Like

This great, thanks!

One question though: Given a typical dual-stack Internet connection where the router gets public IPv4 and IPv6 addresses and a second different public IPv6 prefix is provided for the LAN, is there a way to update both the public IPs of the router as well as those of IPv6 LAN clients in a single API call? If so how?
Note: In my case (FRITZ!OS) the DDNS client in the router provides placeholders for the IPv4 address, the IPv6 address of the router, and for the IPv6 LAN prefix.

(This question may be even more relevant for people on a DS-Lite Internet connection, as they don’t have the option of using an IPv4 address to access their router from the Internet.)

fiwswe

2 Likes

Good point! It is my understanding that the contributor of the above feature is also planning to contribute what you’re asking, in a follow-up pull request. I expect we can land this in October or something.

Stay secure,
Peter

1 Like

That would be awesome! :grinning_face::+1:

fiwswe

1 Like

Would that not simply mean that you have two different domains to update anyway?
Which would require two update requests anyway?
Something like fritz.mydomain.com and nextcloud.mydomain.com ?

Most DS-Lite connections should hand you out a static /56 prefix.
If you combine that with a static suffix for your client, you have something similar to a static IPv4, where you no longer need dyndns.

The whole point of wanting to update everything with one API call is to avoid running into rate limits when doing multiple calls. The second reason is, that the DDNS client of the router has all of the information and at exactly the right time — when the IPs have changed. So it makes a lot of sense to let it update everything in one go instead of clients using complicated methods to figure out when there was a change and to do multiple uncoordinated updates (router, client1, client2, …) which will very likely trigger the rate limts.

The syntax implemented in PR #1112 allows updating multiple hostnames (provided they belong to the same domain/zone). But all of them get updated with the same IPs (or subnets). There is no way to specify different IPs for different hostnames. Thus when two different IPv6 prefixes are in play, one for the router and the second for the LAN, There is no way to update both router hostname and LAN client hostnames with a single API call.

Why would you want to do that? Because some people would like to be able to access their router from the Internet for various reasons. And they may also want to access LAN hosts as well.

Actually I know of at least one DS-Lite connection where the router gets an IPv6 address (/128) with prefix A and a second prefix B (/64) is allocated for the LAN clients.

fiwswe

2 Likes

Got it.

I struggled because I wasn’t or still aren’t aware on how the router has all the information at the right time. Unless are we only talking about the assigned prefix + the IPv6 of the router.
Fritzbox seems to be able to do that with the oddly named variable <ip6lanprefix>

The router is connected to the Internet provider from which it gets its dynamic IPs. So it can actively trigger when they change.

I agree that in theory getting the public IPv4 address (if applicable) using DHCP and getting the 2 IPv6 prefixes using DHCPv6 or some other mechanism does not happen in the same exact moment. There are different protocols/transactions involved. But in practice the log entries of the routers I’ve seen are pretty close together. And I never saw any issue with multiple DDNS Updates with partial information being triggered on any router. My guess is that they wait until the connection is fully UP with all relevant IPs before triggering the DDNS client.

3 Likes