Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update multiple A records #22

Open
tonimelisma opened this issue May 10, 2023 · 11 comments
Open

Update multiple A records #22

tonimelisma opened this issue May 10, 2023 · 11 comments

Comments

@tonimelisma
Copy link

I have both a www.example.com as well as example.com records that need updating. Is there a way to update both using the .ini file? I couldn't figure out a way.

@Tachi107
Copy link
Owner

Hi @tonimelisma, thanks for checking out this project!

You could run multiple instances of the tool, one for each name you want to update, but it is way more robust to have cloudflare-ddns update a single record, like ddns.example.org, and have both www.example.org and other.example.org be CNAME records pointing to ddns.example.org.

I seem to remember that apex records (that is, example.org without any third level domain name) can only be an A or AAAA record. In that case, you can make cloudflare-ddns update example.org and setup www.example.org to point to example.org.

Does this solve your issue?

@tonimelisma
Copy link
Author

Hey, I'm pretty sure the DNS RFC standard forbids a CNAME of www.example.com pointing to a parent domain A record example.com. I'm using your package because it's installable via APT on Ubuntu. Unfortunately that doesn't have any automation to run cloudflare-ddns several times for different domain names. I would have to run one instance via the default mechanism and configuration file and develop a completely different, manual setup for another instance. I would also have to maintain both separately. That doesn't sound optimal.

Is cloudflare-ddns still maintained? Do you think you could add functionality to define several records to be updated, separated by a space or comma perhaps?

I'd offer to do a PR but unfortunately I haven't done C++ in over 25 years so my skills are a bit rusty 😆

@Tachi107
Copy link
Owner

Tachi107 commented May 12, 2023

Hey, I'm pretty sure the DNS RFC standard forbids a CNAME of www.example.com pointing to a parent domain A record example.com.

Interesting, would you be able to point me to that document? As far as I know you can't do example.com -> www.example.com, but the other way around is permitted. www is just a regular domain name after all, right?

I'm using your package because it's installable via APT on Ubuntu.

Happy to hear that! I maintain that too.

Unfortunately that doesn't have any automation to run cloudflare-ddns several times for different domain names. I would have to run one instance via the default mechanism and configuration file and develop a completely different, manual setup for another instance. I would also have to maintain both separately. That doesn't sound optimal.

Yeah, that's true. systemd provides a well defined mechanism to run multiple instances of a service, and I could look into leveraging that, if wanted. But thinking about it, adding multi-record support to the tool itself might result in a better user experience.

Is cloudflare-ddns still maintained?

Of course :) It doesn't receive lots of commits because it already does what I and a few friends need it to do.

Do you think you could add functionality to define several records to be updated, separated by a space or comma perhaps?

I've considered this option before, and I'd like to avoid it if possible. See issue #14 for some rationale. Of course, if there are no other ways around this issue I'd probably implement it.

I'd offer to do a PR but unfortunately I haven't done C++ in over 25 years so my skills are a bit rusty 😆

Don't worry, I appreciate the offer :)

Edit: looking at https://webmasters.stackexchange.com/questions/127252/is-a-cname-from-the-domain-apex-to-the-www-record-the-correct-way-to-configure-a it seems that www.example.com -> example.com is common practise

@Tachi107
Copy link
Owner

Hey @tonimelisma, did you try to set up a www.example.com -> example.com CNAME? Did it solve your issue?

@tonimelisma
Copy link
Author

Hey @Tachi107. No, it didn't. I also have a need to update other A records in other domains under my Cloudflare account. I suppose you can either keep this issue open as a feature request or if you don't want to implement it, close the issue and I will look for a replacement software.

Thanks for the program and have a great week.

@Tachi107
Copy link
Owner

No, it didn't.

Why not? Could you please help me better understand why you specifically need A records and cannot use CNAMEs?

I also have a need to update other A records in other domains under my Cloudflare account.

My answer would be to user cross-domain CNAME records, but I seem to understand that it doesn't seem to work for you.

I suppose you can either keep this issue open as a feature request or if you don't want to implement it, close the issue and I will look for a replacement software.

The thing is, it's not that I don't want to implement it, but any possible implementation of multiple A records support would be flaky. What happens if you loose network connection after only the first record is updated? You end up in an inconsistent state.

There's no way to atomically update multiple records, so any implementation of this feature would be inherently fragile. The only way to make this reliable is to solve the issue in an alternative way, i.e. by using CNAMEs pointing to one single dynamic record.

Does this now make more sense to you? Do you have any better idea about how to approach this inconsistency issue?

I really want to solve this issue, we just need to figure out how :)

@egildi81
Copy link

For this case i have a request , The idea is use multi-intense on systemd.
I have made the modification on my server, i gonna see how it work

Im on debian 12, and im not an expert on systemd, but this method seems clean to me :

cp -P /usr/lib/systemd/system/cloudflare-ddns.service /usr/lib/systemd/system/cloudflare-ddns\@.service
nano /usr/lib/systemd/system/cloudflare-ddns\@.service

Change on unit Part :
Description=Simple utility to dynamically change a DNS record [%i]
Change on Service Part :
ExecStart=/usr/bin/cloudflare-ddns --config /etc/cloudflare-ddns/config.%i.ini

cp -P /etc/cloudflare-ddns/config.ini /etc/cloudflare-ddns/config.<MYSECOND-DOMAIN>.ini

Change on ddns Part :
record_name = <MYSECOND-DOMAIN>

cp -P /usr/lib/systemd/system/cloudflare-ddns.timer /usr/lib/systemd/system/cloudflare-ddns\@.timer
systemctl enable cloudflare-ddns@<MYSECOND-DOMAIN>.timer

If you want to add another domain, I think you just need to duplicate the config file with the domain name and enable :
systemctl enable cloudflare-ddns@<MYTHIRD>.timer

One of the only fears I have is that cloudflare limits the number of updates per different process.
I think the systemd method can be improved (as I said, I'm not an expert on the subject).

For the CNAME debate, you can very well have an A record that you update, and the other records can be CNAMEs.
Otherwise, what's the point of CNAMEs?
I've seen that some DNS management interfaces from other providers don't really like CNAMEs just for MX records.
And if it's only the MX record, you can very well indicate the address of a server outside the zone, which does have a dynamically updated A record.

@Tachi107
Copy link
Owner

Hi @egildi81, thank you very much for your feedback! Yeah, I too was thinking about using systemd's multi-instance support, but I first need to refine the caching system because it currently has issues with updating multiple records at once. I'm pretty much done, but you can look at PR #20 for details.

Once that's done I'll look into this to figure out what's the best way to implement this feature. Thank you all again :)

@Tachi107
Copy link
Owner

After thinking about this more, I really can't find a good use case for this, and a case where such a feature would work better than CNAMEs. I'll mark this as wontfix, but if you think you can find an elegant solution to this, I'll be happy to review patches!

@Tachi107 Tachi107 added the wontfix This will not be worked on label May 12, 2024
@tonimelisma
Copy link
Author

Hi @Tachi107,
I appreciate your consideration of this feature request, but I respectfully disagree with your assessment that there isn't a good use case for updating multiple A records simultaneously.
As outlined in RFC1035 and other DNS standards, a domain name that has a CNAME record cannot have any other record types, such as NS, MX, SOA, or A records. This limitation means that in many scenarios, using multiple A records is the only viable option to achieve the desired DNS configuration.
Given this constraint imposed by the DNS standard, there is a clear need for users to be able to update several A records concurrently. This functionality would greatly benefit users who rely on your dynamic DNS software in situations where CNAMEs are not an option.
Regarding your statement about reviewing patches, I'm a bit confused. If you believe there is no use case for this feature, why would you be willing to review patches? It would be helpful to clarify whether you don't see the need for this functionality or if you simply don't have the time or interest to implement it yourself but understand that it's a valid user requirement.
I kindly request that you reconsider marking this as "wontfix" and instead keep the discussion open to explore elegant solutions that address this genuine user need.
Thank you for your time and consideration.

@Tachi107
Copy link
Owner

Tachi107 commented May 13, 2024

As outlined in RFC1035 and other DNS standards, a domain name that has a CNAME record cannot have any other record types, such as NS, MX, SOA, or A records. This limitation means that in many scenarios, using multiple A records is the only viable option to achieve the desired DNS configuration.

Oh, that is something I didn't understand... This changes the usefulness of the feature indeed.

Regarding your statement about reviewing patches, I'm a bit confused. If you believe there is no use case for this feature, why would you be willing to review patches? It would be helpful to clarify whether you don't see the need for this functionality or if you simply don't have the time or interest to implement it yourself but understand that it's a valid user requirement.

I didn't consider this feature important enough to spend time on it, but I did understand that it is something that users want. Hence if somebody wanted to work on this I'd review and (if clean enough) merge the feature.

Edit: to be clear, now that I better understand the issue, I'll eventually work on fixing it myself.

I kindly request that you reconsider marking this as "wontfix" and instead keep the discussion open to explore elegant solutions that address this genuine user need.

Sure!

Thank you for your time and consideration.

Thanks for your patience in making me understand why this is needed :)

@Tachi107 Tachi107 removed the wontfix This will not be worked on label May 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants