Support Dual Stack and multiple configurations about cloudflare-ddns HOT 5 CLOSED

Anyway, when you have a connection in Germany, you usually get "DS-Lite" (DS=Dual Stack). This means, that you only have a real IP v6 address, your IP v4 address is "virtual", in the sense that it is shared with other users (due to the lack of available IP v4 addresses) and you can't host a server on IP v4.

Except, of course, you get your provider to do a port forwarding for you or switch your connection to Dual Stack. This simply means that you have your own IP v4 addresses again (together with an IP v6).

Got it, thanks for the explanation :)

if you want to make it as easy as possible, maybe one can add a tool create the config file? E.g.

cloudflare-ddns-create <api_key> <zone_id> <record_name>

The tool would then scan all record matching that name via https://api.cloudflare.com/#dns-records-for-a-zone-list-dns-records. It then detects whether there is a matching A or AAAA entry (or both) and create an approriate config file with the record ID.

E.g.

[ddns]
api_key = <api_key>
zone_id = <zone_id>
record_id_ipv4 = <record_id_for_A_record> # can be omitted if no A record
record_id_ipv6 = <record_id_for_AAAA_record> # can be ommited if no AAAA record

Honestly this sounds quite complex 😅️

I would prefer to avoid having to expose Cloudflare's implementation details like record IDs. To be honest, I really dislike having to expose the "zone ID" too, as it doesn't really mean much to the user (and as you said in #12 (comment) it was one of your pain points when using this tool); after all, the zone is something that should be automatically inferred by looking at the DNS record (e.g. if you look at ddns.pappacoda.it you immediately notice that pappacoda.it is the zone). I'll look into adding some kind of logic that, based on the record name, automatically infers the zone and its id (probably using this: api.cloudflare.com/#zone-list-zones). Opened #15 to track the feature status.

Getting back to this issue, what if cloudflare-ddns automatically figured out if it needs to update both an A and AAAA record? Right now, the client figures out if it needs to update an A or AAAA record based on the value of the aaaa out parameter of get_record(). But again, I made a mistake based on wrong assumptions; a boolean isn't enough to express a situation where a single domain name references both an A and an AAAA record, so I'll probably need to refactor the code to take into account this third possible state. Changing aaaa to a type enum would allow me to better handle the situation in the tool. If type is DDNS_TYPE_BOTH (or something like that) I can call get_local_ip() twice to get both IP addresses. Then, I call update_record() for each of the successful get_local_ip() calls; not failing if one of the get_local_ip() calls fails is important because it is possible that a user might have two different hosts on two different networks that both update the same record name, but one is under an IPv4 network and the other is on IPv6.

This way, all the complexity is hidden in the implementation, and users don't need to worry about it.

from cloudflare-ddns.

Wouldn't be the zone ID an additional point in favor of creating the config with a "human readable" tool? I.e. the actual config for the cloudflare-ddns daemon / API exposes the cloudflare API for fast execution time, but at the same time users don't actually need to use them.

Yes and no. Yes, because I like tools like systemctl edit that make it simple to edit configuration files. No for two main reasons:

• cloudflare-ddns' config format is way simpler that systemd's one (no overrides, drop ins, etc, and has just two or three config keys)
• Caching shouldn't be done in a configuration file anyway.

Also, I think that caching in a non-temporary file could lead to reliability issues. What if the record ID changes, e.g. because the user has deleted and recreated it? Or what if for some reason the Zone ID changes as well? You would need to edit your configuration for things that you didn't configure in the first place, weird...

Your performance concerns are valid though, and proper caching of the Zone ID would still be a good thing. There are better places to store the ID on Linux systems, like /var/cache or even /tmp (but the latter might not be helpful in practice, as /tmp files are often to be considered bound to the lifetime of the service, especially when using systemd's PrivateTmp=).

a function where you only have the record name, that in turn calls functions to get the zone ID and the record ID.

I'm working on it. Getting the zone ID and the record ID requires two different API calls, so mixing both in one function doesn't really provide any benefit, unfortunately

from cloudflare-ddns.

Hi, thanks for your suggestion! As I said here in Italy IPv6 addressed are not that popular, so I don't have a way of knowing what the shortcomings of this tool are when it comes to IPv6 support; thus I really appreciate your feedbacks :)

One major goal I have for this tool is that it has to be simple; if you don't know anything about IPv4, AAAA, barely know what a DNS record is, but you just want to host a little webpage on your home network you should be able to do it easily.

So an explicit caching option is out of scope (probably). It is a cool concept indeed, but it is something not directly related to the fetch-compare-update loop of the program, and I would prefer to avoid introducing new concepts in the README / docs. Thinking about it, not having documentation at all would be a great accomplishment, as it means that the tool is so simple that a couple of hints in the readme should be enough to get newbies up and running. Not that I hate advanced stuff, heck I'm a giant nerd, but I see this tool as something that I could send to my not-so-techy friend to get him interested enough into server / web development (something that I already did, and worked!).

I also thought that supporting a setup where you have a single name pointing to multiple IP addresses was out of scope, and it kinda is if you consider only IPv4 or only IPv6 as I originally did — if you have to constantly update a DNS record that points to different addresses it gets tricky, if not impossible, to figure out which records are still valid and which aren't, as the only ways I can think of ensuring that a record is valid are either being on the machine whose record changes dynamically, or sending a request to all the relevant IPs and expect a particular response.

BUT having a name pointing to a single IPv4 address and a single IPv6 address (so an A and an AAAA record, both having the same name and pointing to a single address) is, as you pointed out, a valid use case that is worth supporting, I suppose. Could you please explain me more in detail what you mean by "Dual Stack"?

Lastly, I agree that this tool should also support multiple DNS records. It could be useful if you want to play around with nginx / apache2 virtual hosts, for example. And doesn't even complicate things that much neither for me nor the users, because we both need to simply repeat the same operation multiple times, no new concepts involved. (here caching could indeed be useful; if you need to update multiple records at the same time from the same hosts calling get_local_ip() multiple times is pointless).

I apologize if something I said doesn't make sense, networking is not the field I know best :)

Edit: actually, I think that supporting multiple DNS records is not needed; you can simply create a CNAME record pointing to the record updated by cloudflare-ddns

from cloudflare-ddns.

BUT having a name pointing to a single IPv4 address and a single IPv6 address (so an A and an AAAA record, both having the same name and pointing to a single address) is, as you pointed out, a valid use case that is worth supporting, I suppose. Could you please explain me more in detail what you mean by "Dual Stack"?

Right, the multiple websites entry thing is not really something that useful for this tool I suppose (as you mentioned it is also possible with a CNAME record).

Anyway, when you have a connection in Germany, you usually get "DS-Lite" (DS=Dual Stack). This means, that you only have a real IP v6 address, your IP v4 address is "virtual", in the sense that it is shared with other users (due to the lack of available IP v4 addresses) and you can't host a server on IP v4.

Except, of course, you get your provider to do a port forwarding for you or switch your connection to Dual Stack. This simply means that you have your own IP v4 addresses again (together with an IP v6). I first considered setting up my home server just with IP v6 because we have DS-Lite, but then I noticed that eduroam doesn't have IP v6 :/

Anyway, if you want to make it as easy as possible, maybe one can add a tool create the config file? E.g.

cloudflare-ddns-create <api_key> <zone_id> <record_name>

The tool would then scan all record matching that name via https://api.cloudflare.com/#dns-records-for-a-zone-list-dns-records. It then detects whether there is a matching A or AAAA entry (or both) and create an approriate config file with the record ID.

E.g.

[ddns]
api_key = <api_key>
zone_id = <zone_id>
record_id_ipv4 = <record_id_for_A_record> # can be omitted if no A record
record_id_ipv6 = <record_id_for_AAAA_record> # can be ommited if no AAAA record

Another advantage of this config-creation tool would be, that there is no need to call cloudflare first to get the record ID every time, and IP v4 and IP v6 can be done in parallel.

from cloudflare-ddns.

if you want to make it as easy as possible, maybe one can add a tool create the config file? E.g.

cloudflare-ddns-create <api_key> <zone_id> <record_name>

The tool would then scan all record matching that name via https://api.cloudflare.com/#dns-records-for-a-zone-list-dns-records. It then detects whether there is a matching A or AAAA entry (or both) and create an approriate config file with the record ID.
E.g.

[ddns]
api_key = <api_key>
zone_id = <zone_id>
record_id_ipv4 = <record_id_for_A_record> # can be omitted if no A record
record_id_ipv6 = <record_id_for_AAAA_record> # can be ommited if no AAAA record

Honestly this sounds quite complex sweat_smile

I would prefer to avoid having to expose Cloudflare's implementation details like record IDs. To be honest, I really dislike having to expose the "zone ID" too, as it doesn't really mean much to the user (and as you said in #12 (comment) it was one of your pain points when using this tool); after all, the zone is something that should be automatically inferred by looking at the DNS record (e.g. if you look at ddns.pappacoda.it you immediately notice that pappacoda.it is the zone). I'll look into adding some kind of logic that, based on the record name, automatically infers the zone and its id (probably using this: api.cloudflare.com/#zone-list-zones). Opened #15 to track the feature status.

Wouldn't be the zone ID an additional point in favor of creating the config with a "human readable" tool? I.e. the actual config for the cloudflare-ddns daemon / API exposes the cloudflare API for fast execution time, but at the same time users don't actually need to use them.

But I agree, it would be even better to if users just need the API key and the record name, the rest should be done by automagically. But at least as far as I see it from the cloudflare API, this requires at least three calls to cloudflare (get zone ID, get record IDs, update records). If we cache the zone and record IDs in a config file this could be done to at most two calls.

Getting back to this issue, what if cloudflare-ddns automatically figured out if it needs to update both an A and AAAA record? Right now, the client figures out if it needs to update an A or AAAA record based on the value of the aaaa out parameter of get_record(). But again, I made a mistake based on wrong assumptions; a boolean isn't enough to express a situation where a single domain name references both an A and an AAAA record, so I'll probably need to refactor the code to take into account this third possible state. Changing aaaa to a type enum would allow me to better handle the situation in the tool. If type is DDNS_TYPE_BOTH (or something like that) I can call get_local_ip() twice to get both IP addresses. Then, I call update_record() for each of the successful get_local_ip() calls; not failing if one of the get_local_ip() calls fails is important because it is possible that a user might have two different hosts on two different networks that both update the same record name, but one is under an IPv4 network and the other is on IPv6.

This way, all the complexity is hidden in the implementation, and users don't need to worry about it.

Maybe both can be provided in the C API? E.g. a function where you only have the record name, that in turn calls functions to get the zone ID and the record ID. This way both can be done, if cloudflare-ddns is called with one argument -> config file, if called with two arguments -> API key and record name, get zone and record ID(s) automagically, three arguments -> API key, zone ID and record ID.

I still feel that it would be better to cache the zone and record IDs in a config file, created by some handy cli tool. For one, it's easier for users than editing a config file, since it can give some verbose output if it worked and which records are found. The second reason is permissions, if you want to create a different config the tool could handle file permissions, and there would be no need for a non-functional default config.

from cloudflare-ddns.