DDNS - Cloudflare Not working

[jbhorner]

Title covers it pretty much. By "not working" I mean it is not updating in Cloudflare. This worked perfectly pre 24.7.

I have all of the information set correctly. When I used DDCLIENT, the logs show nothing under debug.

When I used "native", the logs show:

   Account 00000000-0000-0000-0000-000000000000 [cloudflare - Cloudflare DDNS xxxxxxxx.COM] error receiving ZoneID [[{"code": 6003, "message": "Invalid request headers", "error_chain": [{"code": 6103, "message": "Invalid format for X-Auth-Key header"}]}]]

I rolled and reimplemented the API key with no success.

[Monviech]

Alternatively you could use os-caddy as your DynDNS client with Cloudflare.

https://docs.opnsense.org/manual/how-tos/caddy.html#dynamic-dns-in-client-mode

[jbhorner]

Alternatively you could use os-caddy as your DynDNS client with Cloudflare.

https://docs.opnsense.org/manual/how-tos/caddy.html#dynamic-dns-in-client-mode

Hi - Thanks. I tried that, but reached a limit of my knowledge of Caddy for use with Cloudflare. I put in the api key, and added two additional fields--email address (used for login with the API token) and base domain. It didn't work, but I'm sure I was doing something wrong. (I followed the rest of the instructions found in the link you'd provided; it mentioned none of these other things.)

With that said, I removed the configuration items I'd added in the GUI, and disabled Caddy through the UI. I then removed the package.

Now, the DDNS service won't even start if using ddclient versus native. (Native continues to throw the same errors.) Although not really a step backwards since it didn't work anyway, but another problem tied to this.

The original configuration should have worked without issues after implementing 24.7. In my case, I installed 24.7 fresh, updated, and then restored my configuration. I did it this way to avoid problems like this. I'm now wondering what else is wrong that I've not yet discovered across my implementation.

[Monviech]

I mean there are helps to read beneath the fields. For Cloudflare just the API key should be enough, its one field.

To update the domains, creating one domain for each that should be updated does the rest.

I understand it though, hope you can get ddclient to work again.

I heard things can get weird if you change backends back and forth too often.

[julsssark]

I am using Cloudflare with DDNS and have not had any problems under 24.7.x. Can you please confirm whether you are using the global API key or an API token? From Cloudflare, you can see them both by selecting your user icon in the top right and then My Profile->API Tokens. I am using the native backend and an API token (not global API Key). Using the token, the username should be "token" (without quotes and lower case). My Cloudflare API token has access to read the zone and edit DNS.

[Monviech]

You have to use a selective API token that has DNS edit rights.

It should not be the global token.

[jbhorner]

I'll answer a couple of questions from above, and then give the solution I found.

As to which auth I was using, I tried both global and api. For API, I did indeed have the API token set as "Edit" as one of the options. Ultimately I was able to get this to work with the username field left empty (I hadn't yet seen the recommendation to use "token"), and the check IP method set to "Interface." (Before, I had my email name in the username field, and the check IP method set to my WAN interface.

This is using the ddclient method, not Native. I may tackle the Native at some point, but it's not in the cards today, and probably won't be unless I hear of a compelling reason to do so.

I do not recall anything in the release notes stating that there were changes to this functionality. The complete configuration was identical to earlier versions (meaning I didn't modify anything), and it worked without issue. In fact, I brought up the prior version and verified that it worked correctly. So, something changed somewhere in the latest version of OPNsense. If Cloudflare is selected as the service, it seems to me that it should completely ignore the username field if it is indeed superfluous. (Or better still, do not display the field if it's not appropriate to the service selected.)

As an aside, earlier I'd noted that the ddclient service failed to start after trying Caddy as suggested earlier in this thread. Rather than re-hash what I did there, it's above. Suffice to say, the only way I could overcome the service not starting was to reboot OPNsense. I can think of very few reasons that one should ever have to reboot a firewall; this does not fit into a use case where I think it's justified. Perhaps the team that works the magic with OPNsense will take this into consideration.


Thank you all for your suggestions.

[jjrushford]

I do not recall anything in the release notes stating that there were changes to this functionality. The complete configuration was identical to earlier versions (meaning I didn't modify anything), and it worked without issue. In fact, I brought up the prior version and verified that it worked correctly. So, something changed somewhere in the latest version of OPNsense. If Cloudflare is selected as the service, it seems to me that it should completely ignore the username field if it is indeed superfluous. (Or better still, do not display the field if it's not appropriate to the service selected.)

Thank you all for your suggestions.

I tried your suggestion and left the username blank and just populated the password with my API key.  I have my zone and hostname populated and am using the WAN interfaces as the IP lookup method.  I now get errors that say it's unable to update my IP addresses as the A and AAAA records do not exist in Cloudflare.  I created the A and AAAA records for my host at my Cloudflare DNS before I even configured os-ddclient and they still exist so, I do not understand why I'm getting these errors.  Any ideas?

[julsssark]

Are you using the native or legacy backend? Are you using the global API key or an API token?

[jjrushford]

I'm using the ddclient backend with the API token.  I believe there is a bug in the ddclient perl script. 

I haven't tracked it down yet but here is the API call to cloud flare using a curl script that I verified is returning
my A and AAAA records in the JSON response.

#!/usr/local/bin/bash

set -x
curl --request GET \
  --url https://api.cloudflare.com/client/v4/zones/REDACTED ZONE_ID/dns_records \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer REDACTED API TOKEN"

I've looked at the /var/log/ddclient/latest.log and I see the query being made, the URL looks correct and I see the Authorization header in the log is set correctly using my API token but when the script examines the decoded JSON, it fails to get the A and AAAA records from the response.  To be clear, ddclient is sending the exact same query as the curl above but when examining the response, it does not resolve the records from the JSON response.

I'm currently trying to debug the script.

[jjrushford]

Ok, I got it debugged and now have it working.  I saw in the ddclient latest.log, that it queried using query parameters to specify the particular A and AAAA record.  So I ran the query manually using curl

curl --request GET \
  --url https://api.cloudflare.com/client/v4/zones/REDACTED ZONE_ID/dns_records?type=A&name=www\
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer REDACTED API TOKEN"

Note the query parameters, ?type=A&name=www.  When I ran the query no A record was returned in the JSON.  When I left out the query parameters, I saw that my A record name was the FQDN, ie hostname.domainname.  I updated the ddclient settings in the OPNsense UI and changed my 'www' hostname to the FQDN, and now it's working.

This doesn't seem right to me or it's my misunderstanding.  Why would an A or AAAA record name need to be the specified using the entire FQDN?  Am I making a mistake in my A/AAAA record creation by using only the hostname?

[jjrushford]

My mistake, I checked the OPNsense documentation and the hostname setting is supposed to be the fully qualified hostname, I missed that.  Anyway, I have it working now, that's the main thing