Allow overwriting IP address for specific (sub)domain in dyndns request

[molikuner]

What does this PR do?

This PR introduces the possibility to set different IP addresses and/or networks for each updated (sub)domain in the dyndns update. It does so by allowing to overwrite request parameters for specific (sub)domains using a new <domain>.<parameter> syntax.

Given the following request:

https://update.dedyn.io/
  ?hostname=host1.example.com,host2.example.com
  &myip=1.2.3.4
  &host2.example.com.myipv6=2001:db8::1

The following IP addresses would be set after:

domain	IPv4 address	IPv6 address
host1.example.com	1.2.3.4	none / discovered by client IP address
host2.example.com	1.2.3.4	2001:db8::1

Why is it needed?

This PR addresses most remaining concerns from #13, as it allows specifying specific addresses for specific (sub)domains. For example in Germany some ISPs provide an IPv6 network and an IPv6 address for the router that is outside of the given network (see for example this comment in my previous PR).

How is it implemented?

While retrieving the IP address from the request parameters, additional request parameters are considered before falling back to the previous parameters or client IP address:

For IPv4:

• <domain>.myip
• <domain>.myipv4
• <domain>.ip

For IPv6:

• <domain>.myipv6
• <domain>.ipv6
• <domain>.myip
• <domain>.ip

[fiwswe]

Very welcome PR! Thanks for your work on this :-)

The syntax you chose seems to assume that there will never be TLDs with the names ip, ipv6, myip, myipv4 or myipv6?

Or is that mitigated by the constraint, that all hostnames must belong to the same domain/zone? Or that <hostname>=<ip> parameters only make sense when one of the suffixes is added to the hostname?

Would a different separator make more sense here?
For example: <domain>:ipv6=2001:db8::1

fiwswe

[peterthomassen]

Do we need a discriminator suffix at all? (The address family is evident from the value .)

[fiwswe]

@peterthomassen Thinking about it, I agree that the suffix is unnecessary. That would also help to keep down the length of the URL.

Even the scenario where one would want to set both IPv4 and IPv6 addresses for a hostname independently could be handled like this:
<domain>=<ipv4>,<ipv6> or <domain>=<ipv6>,<ipv4>
Where <ipv4> and <ipv6> could be actual IPs, with or without a subnet specifier, or keywords like preserve or none.

Extrapolating this syntax further, I don't see any practical value in allowing more than one IP value for each address family. But I could be missing some use case?

[molikuner]

Hi @fiwswe and @peterthomassen,

Thank you both for your input. My design was guided by the principle of keeping the API explicit and consistent to avoid ambiguity. Here are my detailed thoughts on the points you raised.

The syntax you chose seems to assume that there will never be TLDs with the names ip, ipv6, myip, myipv4 or myipv6?

This is mitigated by the suffix requirement. The suffix acts as a namespace, creating a clear distinction and preventing collisions. For example:

• A request for example.berlin.ip updates the domain example.berlin.
• A request for example.berlin.ip.ip would update the domain example.berlin.ip.

Even if ip became a TLD, the parameters would remain distinguishable.

Do we need a discriminator suffix at all? (The address family is evident from the value.)

While inferring the address family from the value is possible, I believe it introduces significant inconsistencies and implementation complexity. Let's explore the two main alternatives that I'm seeing to using a suffix:

1. Multiple Parameters with the Same Name (e.g., ?example.com=1.2.3.4&example.com=2001:db8::1)

This approach would either introduce a major inconsistency to the API or be a breaking change.

While Django's QueryDict allows accessing all values for a parameter (e.g., with getlist), our current implementation consistently uses only the last-specified value. For example, a request with ?ip=1.2.3.4&ip=5.6.7.8 results in
5.6.7.8 being used.

If we were to process multiple values for domain-based parameters, we would face a dilemma:

• Option A: Create an Inconsistent API. We could implement the multi-value logic only for new domain-based parameters. This would mean ?ip=...&ip=... behaves differently from ?example.com=...&example.com=..., which is
  confusing and could surprise users.

• Option B: Introduce a Breaking Change. We could change the behavior for all parameters, including ip and myip, to handle multiple values. This would be a breaking change. For example, a request like
  ?ip=1.2.3.4&ip=preserve is currently handled by taking the last value (preserve), which preserves both A and AAAA records. The new logic might interpret this as "set the A record to 1.2.3.4 and preserve the AAAA record," leading
  to a different outcome for existing users.

Either of these don't sound great to me. So I would personally prefer keeping the suffix, but let's first explore the other option that I see and @fiwswe already proposed.

2. Comma-Separated Values (e.g., ?example.com=1.2.3.4,2001:db8::1)

The complexity here lies in defining the semantic rules for the resulting values, which would lead to either API inconsistencies or ambiguous behavior.

• Handling Mixed Values (like preserve): Consider ?example.com=1.2.3.4,preserve. Currently, a similar request like ?ip=1.2.3.4,preserve is invalid. To support this for the new parameter, we would have to invent new rules
  (e.g., "preserve applies to the unspecified IP version"). This would make the new parameter behave fundamentally differently from the existing ip and myip parameters, creating an inconsistent API, or we would need to also allow this for the ip and myip parameters. Should we still prevent this new style for myipv6? Here it clearly doesn't make sense to have both.

• Handling Empty Values: A similar problem exists with the "empty value". Currently, ?ip=1.2.3.4, is an error. However, the separate-parameter request ?myipv6=&ip=1.2.3.4 is valid and removes the IPv6 address. So, how
  should ?example.com=1.2.3.4, be interpreted? Should it be an error (like the current comma-separated behavior), or should it mean "set IPv4 and remove IPv6" (like the empty parameter behavior)? Defining this would again require
  creating special, inconsistent rules or redefining the ip and myip parameter.

Both cases shows that supporting a comma-separated format would create either an inconsistent API comparing domain parameters with ip and myip or between domain parameters, ip, myip and ipv6, myipv4, myipv6.

Given these points, the current suffix-based approach seems to me to be the most consistent approach with the current API. It avoids ambiguity, differences parameter handling, and prevents breaking changes. I'm open to changing the implementation though, should you still think no suffix should be used.

---

Finally, with both suffix-less options, there is a minor risk of ambiguity if a name like ip were to become a TLD that deSEC manages. While ICANN rules make this unlikely, it's not technically impossible to define records for TLDs (see
https://uz./ for example). In such a scenario, a user would be unable to update records for that TLD itself using this feature.

[fiwswe]

@molikuner Thanks for your work!

Any API where the same parameter can be used multiple times (possibly relying on the order of parameters) is probably not a good idea. That eliminates your section 1.

The syntax <domain>=<ip1>[,<ip2>] should be fairly easy to parse. The list of IPs should have some constraints:

• Minimum of one list item (IP).
• Maximum of 2 list items (IPs).
• Only 0-1 of each address family.
• If keywords (preserve, none) are used, either the specified IP defines which address family the keyword applies to or in the case of preserve,preserve (this combination could be flagged as an error because there is no use-case, I can see) or none,none it does not matter. So <ipv4>,preserve equals preserve,<ipv4> and <ipv6>,preserve equals preserve,<ipv6>. Same for none respectively. Only preserve,none would actually be ambiguous. But is there a use-case for that? This is a static setting, no need for dynamic updates. In this case the order could define which is which, if it is not flagged as an error. So a constraint could be specified that at least one list item must be an IP. That solves all of these issues.
• Empty list elements are not allowed (no ,<ip> or <ip>,). The keyword none (or maybe the shorter no) designates that the respective IP should be deleted, avoiding the problem you described with empty list elements.

As for having different rules for <domain>= and ip=, either ignore he slight inconsistency or adjust ip= to work the same.

Having deSEC manage a potential future TLD ip. and creating an ambiguity is more a theoretical concern, I'd say. I'd file this under very unlikely.

My Python skills are not sufficient to help with coding, sorry. But the design of the API should not be influenced by what happens to be convenient in code I think. Keeping URLs short and having a syntax that is able to express all use cases is more important IMHO.

fiwswe

[fiwswe]

About the potential ambiguity with the potential future TLD ip.: This could be resolved by optionally allowing FQDNs instead of hostnames without the trailing .. The parameter name ip= is different from the domain ip.=.

[molikuner]

Thanks @fiwswe for your response. There are a few points that I don't necessarily agree with, or at least want to explain some of my thoughts:

Any API where the same parameter can be used multiple times (possibly relying on the order of parameters) is probably not a good idea.

This is already how the existing query parameters work. If you specify them multiple times, only the last one will be considered. I don't want to say that I disagree with you, but we have to live with the existing API (and must not break it, as existing clients might rely on this behavior).

Please also note, that I wasn't suggesting to rely on the order. Just that the domain could be specified twice one time for the IPv4 address and one time for the IPv6 address. But I see how there is little benefit over the other solution with comma separated values.

Minimum of one list item (IP).

IMHO a request like this should be allowed: ?hostname=one.a.io,two.a.io&ip=1.2.3.4&two.a.io=. I would interpret it as "set IPv4 1.2.3.4 for one.a.io, infer the IPv6 for one.a.io and remove both IPv4 and IPv6 for two.a.io. Or do you see a specific reason this shouldn't be allowed? Sure, maybe it doesn't make sense to have this in a static script, run daily to renew a dynamic IP address, but maybe someone has a use-case where the IPv4 address and IPv6 address should be removed every now and then.

Maximum of 2 list items (IPs).
Only 0-1 of each address family.

We can already do requests like this: ?ip=1.2.3.4,5.6.7.8,9.10.11.12. It sets three A records for the updated domain. Why should we prevent this in the new domain based parameters?

Only preserve,none would actually be ambiguous.

That's actually a good point. With my current proposal this would be possible: ?a.io.myipv4=&a.io.myipv6=preserve. The result would be that the IPv4 address would be preserved while the IPv4 address is deleted. It wouldn't be really possible to represent that with a ?a.io=,preserve since it would be impossible to know what applies where.

Empty list elements are not allowed (no ,<ip> or <ip>,). The keyword none (or maybe the shorter no) designates that the respective IP should be deleted, avoiding the problem you described with empty list elements.

Why create yet another keyword? Your proposal of none behaves exactly the same way as an empty string. I would personally not like to have even more differences between this domain parameter and the existing parameters. My point wasn't that the empty value is a problem, the point is just that we have to consider how the new parameter compares to the old ones and whether they should be adjusted as well.

either ignore he slight inconsistency or adjust ip= to work the same.

From my experience, ignoring inconsistencies increases support burden, as people don't understand these slight differences. Keeping things simple is usually the better approach. So even if it might seem negligible I would prefer consistency. Adjusting the way the existing parameters are handled is also weird since we have the parameters that specify the IP version in their name already.

---

I also want to highlight another point: "scriptability". This API is intended to be used by some script and having both IPv4 and IPv6 address in the same parameter creates certain edge-cases that need to be handled:

Given someone tries to create a simple script that updates updater.example.com with the IP address of the execution host and has two inputs, the expected IPv4 and IPv6 address of server.example.com:

curl \
  "https://update.dedyn.io/?hostname=updater.example.com,server.example.com&server.example.com=$IPV4,$IPV6" \
  --header ...

Now this would fail, if the expected IPv4 address as well as the expected IPv6 address are none, i.e. there shouldn't be any A or AAAA record. It would fail as the value of the server.example.com would be just ,. The edge-case that neither a IPv4 nor a IPv6 address are given would need to be handled explicitly be removing the comma between the empty values.
With separate parameters this problem wouldn't happen, as it's okay to have both parameters as an empty value.

[fiwswe]

This is already how the existing query parameters work. If you specify them multiple times, only the last one will be considered.

Are you referring to URL parameters in general or the deSEC IP Update API specifically? For the general case it would depend on the application interpreting the URL parameters I think. But you are probably correct for the deSEC case.

Please also note, that I wasn't suggesting to rely on the order.

No you weren't. I had some alternative specifications in the back of my mind, akin to hostname=<host1>&ip=1.2.3.4&hostname=<host2>&ip=5.6.7.8 But forget those, as they are confusing and waste URL length.

We can already do requests like this: ?ip=1.2.3.4,5.6.7.8,9.10.11.12. It sets three A records for the updated domain. Why should we prevent this in the new domain based parameters?

We can? I didn't know that. In that case I withdraw that constraint. OTOH in that case determining to which address family the preserve or empty / none list items apply gets harder.

From my experience, ignoring inconsistencies increases support burden, as people don't understand these slight differences. Keeping things simple is usually the better approach. So even if it might seem negligible I would prefer consistency.

ok.

Adjusting the way the existing parameters are handled is also weird since we have the parameters that specify the IP version in their name already.

But they don't need to change and the ip parameter is already documented to hold either IPv4 or IPv6 address(es), which to me is mildly confusing. But I think that has its origins in other DDNS APIs (probably from a time when IPv6 was not in general use)?

So with this adjusted, instead of …&myip=<ipv4>&ipv6=<ipv6> this syntax would be equivalent and shorter: …&ip=<ipv4>,<ipv6>

Regarding scriptability, I agree that is a valid concern. Maybe that was why I discarded empty list elements and suggested the more explicit none / no. However with arbitrary length lists that doesn't work anymore. Unless the keywords are qualified with the address family they apply to, e.g. <domain>=6:preserve,1.2.3.4,5.6.7.8, <domain>=2001:db8::/56,4:no or something similar.

It would need to be specified what happens in cases like: <domain>=4:preserve,1.2.3.4,5.6.7.8? Would the keyword override the explicit IPs for the same address family? Or the other way around?

[nils-wisiol]

Thanks for this PR and the interesting discussion!

deSEC's API already supports bulk operations. Is there a kind of change that is supported in this PR but not through bulk operations?

[fiwswe]

@nils-wisiol No, I don't think anything we are trying to change in this PR is a feature not supported by the general API. (Let's turn that statement around: I think the general API supports everything we need for this PR. No issues there.)

Apparently the IP Update API also allows specifying multiple IPs for an address family. I was not aware of that fact before and I must have missed it in the documentation as well. But it is in fact documented. So that was my mistake. Sorry for the confusion.

[molikuner]

Hey @nils-wisiol,

The bulk operations API indeed supports the updates that we're talking here about already (and even more as it seems). I would love to use it, but unfortunately some of my devices aren't too flexible on the request being send. Thus also supporting bulk operations via the "dyndns API" would be appreciated as I can influence the requests parameters a bit on these devices.

In my previous PR (#1112) the support to update more than one subdomains was already introduced. But so far it's not possible to set different IP addresses for specific domains that are updated. E.g. it's not possible to set one subdomain to 1.2.3.4 and another subdomain to 5.6.7.8 in the same request (though it's already possible to update the network of all subdomains by sending e.g. 10.0.0.0/24 as the IP address which would preserve the host part of the existing IP address).

This current PR would improve on the previous PR by allowing to specify different IP addresses for the updated subdomains in the "dyndns API".

[molikuner]

I just found one use-case that I wouldn't be able to replicate easily when using non-suffixed domain parameters. Given I want to update the A and AAAA records for the following domains (no means there shouldn't be a record at all):

domain	A record	AAAA record
example.com	yes	yes
ipv4.example.com	yes	no
ipv6.example.com	no	yes

With non-suffixed domain parameters one would have to create the following request:

?hostname=example.com,ipv4.example.com,ipv6.example.com
  &myipv4=1.2.3.4
  &myipv6=2001:db8::1
  &ipv6.example.com=2001:db8::1,
  &ipv4.example.com=1.2.3.4,

Please note the extra , after the IPv4 and IPv6 addresses for the domain specific parameters, which cause "the other IP version" to be unset. As seen, the IPv4 and IPv6 address need to be duplicated for the specific domains, as it would otherwise be impossible to know which IP version should be set and which should be unset.

Using the initially proposed domain parameters with suffixes it would look like this:

?hostname=example.com,ipv4.example.com,ipv6.example.com
  &myipv4=1.2.3.4
  &myipv6=2001:db8::1
  &ipv6.example.com.myipv4=
  &ipv4.example.com.myipv6=

Maybe it's just me, but I think the second option is a bit more readable and easier to understand as it explicitly states "set IPv4 for ipv6.example.com to none".

This approach would also have the benefit that either IPv4 or IPv6 could still be inferred by the client IP address, which so far I've not found an option to do with the non-suffixed approach, i.e. the following would do the same, if the request comes from 2001:db8::1:

?hostname=example.com,ipv4.example.com,ipv6.example.com
  &myipv4=1.2.3.4
  &ipv6.example.com.myipv4=
  &ipv4.example.com.myipv6=

---

That being said, @peterthomassen and @nils-wisiol please let me know which API format you prefer or if you have any other concerns. I would be happy to adjust the code accordingly.

[fiwswe]

With non-suffixed domain parameters one would have to create the following request:

?hostname=example.com,ipv4.example.com,ipv6.example.com
  &myipv4=1.2.3.4
  &myipv6=2001:db8::1
  &ipv6.example.com=2001:db8::1,
  &ipv4.example.com=1.2.3.4,

I disagree. This could be achieved like this (shorter and without repetitions of any IPs):

?hostname=example.com,ipv4.example.com
  &ip=1.2.3.4,
  &example.com,ipv6.example.com=2001:db8::1

Or in the more practical and slightly expanded example:

• Public IPv4 of the router (example.com): 1.2.3.4
• Public IPv6 of the router (example.com): 2001:db8:42::1
• Public IPv6 LAN prefix: 2001:db8:beef::/56
• One additional LAN host both.example.com with IPv4 address + IPv6 LAN prefix

?hostname=example.com,ipv4.example.com,both.example.com
  &ip=1.2.3.4,
  &example.com=2001:db8:42::1
  &ipv6.example.com,both.example.com=2001:db8:beef::/56

[fiwswe]

Oops sorry, I just noticed (after sending of course) that my alternatives do not handle removing the A RRset for ipv6.example.com. They keep it unchanged (if it exists). Correcting that would indeed require repetition of the prefix.

[fiwswe]

So is avoiding the need to use an IP/prefix more than once a required goal here?

For DDNS clients the only one I know, where using a placeholder more than once is at least unspecified, is FRITZ!OS. Has anyone tested this with FRITZ!OS (or with other DDNS clients)?

Scripts that manually construct the URL should not be an issue here, I think.

[renne]

Hi,

I lost track what is implemented in #1112 and what is open for this PR.
My application is a Fritz!Box with port-forwarding at a full dual-stack internet socket of Deutsche Telekom:

Subdomain	RR-Type	Fritz!OS variable
example.com	A	<ipaddr>
*.example.com	A	<ipaddr>
fritz.example.com	AAAA	<ip6addr>
example.com	AAAA	<ip6lanprefix>
*.example.com	AAAA	<ip6lanprefix>
a.example.com	AAAA	<ip6lanprefix>
b.example.com	AAAA	<ip6lanprefix>
c.example.com	AAAA	<ip6lanprefix>

Do I understand correctly it is possible since the merge of #1112 to use multiple subdomains in a comma-separated list but not to overwrite IPv6 addresses with the LAN prefix?

[fiwswe]

@renne

Do I understand correctly it is possible since the merge of #1112 to use multiple subdomains in a comma-separated list but not to overwrite IPv6 addresses with the LAN prefix?

#1112 implements the following:

• You can use comma-separated lists of hostnames where previously only a single name was allowed.
• You can pass in a subnet prefix where an IP is allowed.

What you can't do yet, is assign different IPs/prefixes to different hostnames. That is what this PR is about.

Thus your use-case is only partially implemented. You can get all but the fritz.example.com, a.example.com, b.example.com and c.example.com AAAA records set in a single API call: https://update.dedyn.io?hostname=example.com,*.example.com&myipv4=<ipaddr>&myipv6=<ip6lanprefix>
Effectively you can use either <ip6lanprefix> or <ip6addr> in the URL, but not both right now.

All of the currently implemented functionality is documented btw. Go ahead and try it out.

[molikuner]

Hi @renne,

Sorry for the late reply, I was quite busy last week. Thanks @fiwswe for the quick response, but I think with the current feature set implemented by #1112 it's possible to already do the following:

Subdomain	RR-Type	Fritz!OS variable
example.com	A	<ipaddr>
*.example.com	A	<ipaddr>
a.example.com	A	<ipaddr>
b.example.com	A	<ipaddr>
c.example.com	A	<ipaddr>
example.com	AAAA	<ip6lanprefix>
*.example.com	AAAA	<ip6lanprefix>
a.example.com	AAAA	<ip6lanprefix>
b.example.com	AAAA	<ip6lanprefix>
c.example.com	AAAA	<ip6lanprefix>

This would be virtually the same behavior (even if there are some additional A records for a.example.com, b.example.com and c.example.com now, but they have the same value as *.example.com). Just fritz.example.com isn't possible, since we can't overwrite the AAAA record for a specific hostname yet (which is what this PR tries to implement).

The update request in the Fritz!Box should be something like this:

https://update.dedyn.io?
  hostname=example.com,*.example.com,a.example.com,b.example.com,c.example.com
  &myipv4=<ipaddr>
  &myipv6=<ip6lanprefix>

As it seems you already have a host handling *.example.com in your network, maybe as a workaround you can forward the traffic for fritz.example.com to the Fritz!Box as it's intended?

[molikuner]

@renne now that I think about it even more, if you don't care about the AAAA record for fritz.example.com (i.e. accept that you can reach your Fritz!Box only via IPv4), you can also do the following request:

https://update.dedyn.io?
  hostname=example.com,*.example.com,a.example.com,b.example.com,c.example.com,fritz.example.com
  &myipv4=<ipaddr>
  &myipv6=<ip6lanprefix>

As long as you don't define an AAAA record for fritz.example.com, there will be no AAAA record created / updated by this request for this hostname. But still the A record of the hostname fritz.example.com will be updated correctly.

The result is something like this:

Subdomain	RR-Type	Fritz!OS variable
example.com	A	<ipaddr>
*.example.com	A	<ipaddr>
fritz.example.com	A	<ipaddr>
a.example.com	A	<ipaddr>
b.example.com	A	<ipaddr>
c.example.com	A	<ipaddr>
example.com	AAAA	<ip6lanprefix>
*.example.com	AAAA	<ip6lanprefix>
a.example.com	AAAA	<ip6lanprefix>
b.example.com	AAAA	<ip6lanprefix>
c.example.com	AAAA	<ip6lanprefix>

[molikuner]

I just tested with an old Fritz!Box that I had around and noticed some weird behavior in the dyndns client of it. For some reason it doesn't support using the <ipv6lanprefix> and <ipaddr> placeholder in the same request.

The update URL was set to (as suggested above):

https://update.dedyn.io/api/update?hostname=<domain>,a.<domain>&myipv4=<ipaddr>&myipv6=<ip6lanprefix>

This is the request that I observed:

/api/update?hostname=example.com,a.example.com&myipv4=1.2.3.4&myipv6=::

As you can see, the myipv6 parameter was set to ::, which is definitely wrong...

As a workaround, I noticed one can do two requests by configuring the client to use two update URLs by concatenating them using a space:

https://update.dedyn.io/api/update?hostname=<domain>,a.<domain>&myipv4=<ipaddr>&myipv6=preserve https://update.dedyn.io/api/update?hostname=<domain>,a.<domain>&myipv4=preserve&myipv6=<ip6lanprefix>

Then the first request will set the IPv4 addresses correctly and the second request will update the IPv6 addresses. I could observe the following requests in this case:

/api/update?hostname=example.com,a.example.com&myipv4=1.2.3.4&myipv6=preserve

/api/update?hostname=example.com,a.example.com&myipv4=preserve&myipv6=2001:9e8:3:4::/64

Note 1: You can not do more than two requests due to rate limiting in this way.

Note 2: This was tested on FRITZ!OS version 06.88 which is quite old at this point, but that particular Fritz!Box doesn't receive any updates anymore, so it's the newest version that I can test. The behavior might have changed in a newer versions.

[renne]

Today I tested a Fritz!Box 7530AX with Fritz!OS 8.20.
For the update-URL https://update.dedyn.io/?hostname=example.de%2C*.example.de%2Cffm.example.de&myipv4=<ipaddr>&myipv6=<ip6lanprefix> DynDNS-Fehler: Der DynDNS-Anbieter meldet Fehler 0 - is returned by the Fritz!Box. If commata are used instead of %2C the Fritz!Box does nothing including empty DynDNS logging.

[molikuner]

Since I had a rather elaborate setup process faking multiple things to test this, I wasn't 100% sure before, but I also had this problem that the Fritz!Box dyndns client would just not do anything.

You could try changing the value for the "Domainname" in config. Every time I changed the value, it was actually doing something for me. The logs are still empty, but at least in the "Online-Monitor" page I was able to see "IPv4-Status: angemeldet, IPv6-Status: angemeldet" after a few seconds.

I'm using an actual , in the "Update-URL". Using the URL you shared with %2C replaced by , worked for me with the caveat that myipv6=:: was send as explained earlier.

[fiwswe]

How about separating the potential FRITZ!OS issues from the actual deSEC update mechanism?

Build the test URL manually and send it via e.g. curl. E.g. use these two URLs alternately (replacing host1 and host2 with actual hostnames in the deSEC account of course):

• https://update.dedyn.io?hostname=host1,host2&myipv4=192.0.2.1&myipv6=2001:db8:1::/56
• https://update.dedyn.io?hostname=host1,host2&myipv4=192.51.100.2&myipv6=3fff:0:2::/56

If FRITZ!OS does not work as advertised then a bug should be reported to FRITZ! GmbH.

I have tried something like the above (using curl) but received HTTP Status 500 whenever I tried to update an IPv6 prefix. IPv6 addresses work fine. See Problems updating IPv6 prefix in the deSEC Forum.

I have not built a testing setup for testing the FRITZ!OS DynDNS client yet. It would require a webserver or proxy that logs the request to see what it is actually sending. I might do that though.

[fiwswe]

I have built a testing setup for the FRITZ!OS DynDNS client as follows:

• A webserver (hosted outside of my LAN) that always returns HTTP status 200 and good for valid queries and which logs the URL and the request headers to a file.

Then I modified the URL in the DynDNS settings in FRITZ!OS on my FRITZ!Box to point to my webserver instead of the DDNS provider I normally use. Nothing else was changed and the URL in the settings looked like this:
https://_mywebserver_/?hostname=<domain>&ipv4=<ipaddr>&ipv6=<ip6addr>&token=<username>&ipv6prefix=<ip6lanprefix>

This resulted in correct values for the parameters hostname, ipv4, ipv6, token, username and ipv6prefix being logged.

So the FRITZ!OS 8.20 DynDNS client works as advertised for me. All of the placeholders were replaced with the expected values.

@molikuner I don't know what the cause of your issue was. But if you used the <ip6lanprefix> placeholder with deSEC, you may have run into the Issue I have asked about in Problems updating IPv6 prefix and mentioned previously?

[renne]

@fiwswe Did you check if comma-separated hostnames work with the Fritz!OS DynDNS-client?

[fiwswe]

@renne Initially I didn't but I just checked now:

• The input field Domainnamen: does not accept a comma separated list. This is just a UI issue though.
• I was able to use hostname=<domain>,host2.com in the URL successfully. The comma separated list of hostnames was passed to my fake DDNS server.

So yes, with some caveats multiple hostnames work fine.

PS. During testing of some variants my FRITZ!Box apparently crashed and the device rebooted. So lesson learned: Don't try to change things too fast as I suspect multiple changes where in flight when this happened. FRITZ!OS does not like that, it seems.