Failed to find the zone

[ruisu07]

Good evening to all!

I'm trying to use the cloudflare-ddns with limited knowledge on this kind of systems, I have my domain configured on cloudflare correctly and I have been accesing it with the zero trust tunnels for websites until now. Recently I'm also hosting gameservers but I cannot use those tunnels and needed this ddns for them but I'm getting an error after launching the docker compose

cloudflare-ddns_1 | 🌐 Detected the IPv4 address xx.xxx.xx.xx
cloudflare-ddns_1 | 😞 Failed to find the zone of mydomain.es
cloudflare-ddns_1 | 😞 Failed to send HTTP(S) request to "https://api.cloudflare.com/cdn-cgi/trace": GET https://api.cloudflare.com/cdn-cgi/trace giving up after 1 attempt(s): context deadline exceeded
cloudflare-ddns_1 | 😞 Failed to detect the IPv6 address
cloudflare-ddns_1 | ⏰ Checking the IP addresses in about 4m55s . . .

This just goes on every try in a 25 minutes try. The token is set, the domain is set, and I have also tried turning off the zero trust tunnels. I cannot find what is wrong with it after following the directions on Github

[speter2]

I've been using cloudflare-ddns for a month now and this issue suddenly appeared. I did not change any settings and it just suddenly broke. Maybe cloudflare changed some api settings on their side?
The logs look like this for me:
🌟 Cloudflare DDNS (v1.15.1-0-ga0938af)

📖 Reading settings . . .

🔸 Use default IP4_PROVIDER=cloudflare.trace
🔸 Use default UPDATE_CRON=@every 5m
🔸 Use default UPDATE_ON_START=true
🔸 Use default DELETE_ON_STOP=false
🔸 Use default CACHE_EXPIRATION=6h0m0s
🔸 Use default TTL=1
🔸 Use default DETECTION_TIMEOUT=5s
🔸 Use default UPDATE_TIMEOUT=30s

📖 Checking settings . . .

📖 Current settings:

🔧 Domains, IP providers, and WAF lists:

  🔸 IPv4-enabled domains:    *, <hidden for privacy>
  🔸 IPv4 provider:           cloudflare.trace
  🔸 WAF lists:               (none)

🔧 Scheduling:

  🔸 Timezone:                UTC (currently UTC+00)
  🔸 Update schedule:         @every 5m
  🔸 Update on start?         true
  🔸 Delete on stop?          false
  🔸 Cache expiration:        6h0m0s

🔧 Parameters of new DNS records and WAF lists:

  🔸 TTL:                     1 (auto)
  🔸 Proxied domains:         *, <hidden for privacy>
  🔸 Unproxied domains:       (none)
  🔸 DNS record comment:      (empty)
  🔸 WAF list description:    (empty)

🔧 Timeouts:

  🔸 IP detection:            5s
  🔸 Record/list updating:    30s

🌐 Detected the IPv4 address

😞 Failed to find the zone of *

⏰ Checking the IP addresses in about 4m57s . . .

[speter2]

@ruisu07 I've just figured it out randomly... You need to put the full domain name now. Most tutorials and guides are incorrect.
So instead of * you need to use *.my-domain.com

[favonia]

@speter2 Thank you for tracking it down (and apologizes for my current very limited bandwidth). Yes, the full domain names are the most reliable ways to interact with Cloudflare. I hope the documentation is clear. If not, please let me know!

[favonia]

@ruisu07 Sorry for the confusion earlier---my reply to @speter2 was about a different topic.

From your logs, IPv4 detection appears to be working (Detected the IPv4 address). The intermittent failures (e.g. API calls to look up zones) look more like network slowness or timeouts than a config typo—especially if it only fails occasionally and then succeeds on the next run. When the zone update fails, the next cycle will retry; in most setups the previous DNS value should remain in place.

A couple things to try:

1. Increase the timeout: UPDATE_TIMEOUT=2m (default is 30s).
2. If you don’t need IPv6 (or your host/network doesn’t support it), disable IPv6 checks to reduce noise: IP6_PROVIDER=none

Also, could you paste your non-secret environment variables (redact tokens and any private URLs), especially IP4_PROVIDER, IP6_PROVIDER, UPDATE_TIMEOUT, and DETECTION_TIMEOUT? That should help me to narrow it down.

[favonia]

@ruisu07 If this turns out to be a real bug on my side and needs a code change, I hope I can pick it up before summer, but I am still recovering from a long-term health issue so I cannot promise a timeline. Sorry for the confusion earlier; I mistakenly thought a similar-looking issue had been resolved, but it looks like this is a different problem.