New: Cloudflare DDNS API-based IP verification - solves orange cloud proxy problem

Hi everyone,

I'm excited to share a major update to the Cloudflare DDNS documentation and a new feature that solves a long-standing issue with Cloudflare's proxy (orange cloud :orange_circle:) functionality.

For Other Provider Developers

This is implemented at the framework level in dynamic_dns_functions.sh. Other DNS providers with proxy/CDN features can implement API-based IP verification by adding GET_REGISTERED_IP mode support to their provider scripts.

The Problem

Many users have experienced an issue where their DDNS client constantly thinks an update is needed, even when their IP hasn't changed. This happens because:

  • When Cloudflare's proxy is enabled (orange cloud :orange_circle:), DNS lookups return Cloudflare's edge server IPs
  • The DDNS script compares this proxy IP to your actual router IP
  • They don't match, so it tries to update on every check
  • This wastes API calls and fills logs with false "Update needed" messages

The Solution

New in ddns-scripts 2.8.2-93: API-based registered IP verification via use_api_check option.

When enabled, the script queries Cloudflare's API directly to get your actual registered IP, bypassing DNS entirely. This gives you the real IP even when the proxy is enabled.

Key features:

  • :white_check_mark: Solves the orange cloud proxy IP problem
  • :white_check_mark: Gracefully falls back to DNS if API query fails
  • :white_check_mark: Framework-level feature (other providers can implement it too)
  • :white_check_mark: Completely optional (default behavior unchanged)
  • :white_check_mark: Safe to enable (automatic fallback)

How to Use It

Simple setup:

  1. Configure Cloudflare DDNS as normal (using API Token)
  2. Add one option to enable API verification:
uci set ddns.your_service.use_api_check='1'
uci commit ddns
/etc/init.d/ddns restart

Example configuration:

config service 'cloudflare'
        option service_name 'cloudflare.com-v4'
        option enabled '1'
        option domain 'home@example.com'
        option username 'Bearer'
        option password 'your_api_token'
        option interface 'wan'
        option use_https '1'
        option cacert '/etc/ssl/certs'
        option use_api_check '1'        # ← New option

What it looks like in logs:

Using provider API for registered IP check via '/usr/lib/ddns/update_cloudflare_com_v4.sh'
Registered IP '1.2.3.4' detected via Cloudflare API
IPv4 at CloudFlare.com already up to date

Updated Documentation

The Cloudflare section of the DDNS wiki has been completely rewritten with:

  • :open_book: Step-by-step setup for API Tokens (recommended) and Global API Key
  • :new_button: Complete documentation of the new API verification feature
  • :magnifying_glass_tilted_left: Real log output examples for all scenarios
  • :hammer_and_wrench: Comprehensive troubleshooting guide (including the orange cloud problem)
  • :white_check_mark: Testing and verification instructions
  • :red_question_mark: FAQ section covering common questions

Read the full documentation here:

Requirements

  • OpenWrt: 22.03 and newer, SNAPSHOT
  • Package: ddns-scripts 2.8.2-93 or newer
  • Install: opkg install ddns-scripts-cloudflare ca-certificates

When to Use This

You should enable use_api_check='1' if:

  • You use Cloudflare's proxy (orange cloud :orange_circle:) on your DDNS record
  • Your logs show constant "Update needed" messages even when your IP hasn't changed
  • You want to reduce unnecessary API calls

You don't need it if:

  • Your Cloudflare DNS record is set to "DNS only" (gray cloud :cloud:)
  • You're not experiencing the false update problem

See the Cloudflare implementation in /usr/lib/ddns/update_cloudflare_com_v4.sh as a reference (lines 247-263).

Backward Compatibility

  • :white_check_mark: Existing configurations continue to work without changes
  • :white_check_mark: Default behavior is unchanged (DNS lookup)
  • :white_check_mark: use_api_check is completely optional
  • :white_check_mark: Safe to upgrade

The framework-level design means other providers can easily add this capability too.

Feedback Welcome

If you've been experiencing the orange cloud problem, please try this feature and let me know how it works for you!

Questions, suggestions, or issues? Reply below or check the wiki documentation.


Useful Links:

Enjoy!


2 Likes

Please consider moving it to a separate page in the wiki. On the page you used we mainly have custom configurations that are not based on additional packages or scripts.