Error: Failed to find zone '%h/nic/update?system=dyndns'

[thadius83]

I have a USG 4, it's getting a bit long in the teeth but it's what I have.

Have managed to deploy the worker to cloudflare, no problems there. However it seems ddclient is sending the wrong GET request, and results in an error with the zone.

DDClient version is 3.9.1 Have tried both dyndns & custom

I see the get request within Cloudflare.

Contents of ddclient.config

# Service : dyndns
server=unifi-cloudflare-ddns.xxxxxxx.workers.dev/update?ip=%i&hostname=%h, protocol=dyndns2 max-interval=28d login=xxxyyy.com password='<apikey>' hostname.xxxyyy.com

Debug Logs:

From CF:

  "logs": [
    {
      "message": [
        "CloudflareApiException",
        "Error: Failed to find zone '%h/nic/update?system=dyndns'"
      ],
      "level": "error",
      "timestamp": 1716450843143
    }

From CLI

DEBUG:    get_ip: using if, eth2 reports 12.12.12.12
DEBUG:
DEBUG:     nic_dyndns2_update -------------------
INFO:     setting IP address to 12.12.12.12 for hostname.xxxyyy.com
UPDATE:   updating hostname.xxxyyy.com
DEBUG:    proxy    =
DEBUG:    protocol = https
DEBUG:    server   = unifi-cloudflare-ddns.xxxxxx.dev
DEBUG:    url      = update?ip=%i&hostname=%h/nic/update?system=dyndns&hostname=hostname.xxxyyy.com&myip=12.12.12.12
CONNECT:  unifi-cloudflare-ddns.xxxxxxx.workers.dev
CONNECTED:  using SSL
SENDING:  GET /update?ip=%i&hostname=%h/nic/update?system=dyndns&hostname=hostname.xxxyyy.com&myip=12.12.12.12 HTTP/1.0
SENDING:   Host: unifi-cloudflare-ddns.xxxxxxx.workers.dev
SENDING:   Authorization: Basic am12345456778
SENDING:   User-Agent: ddclient/3.9.1
SENDING:   Connection: close
SENDING:
SENDING:
RECEIVE:  HTTP/1.1 500 Internal Server Error
RECEIVE:  Date: Thu, 23 May 2024 07:48:54 GMT
RECEIVE:  Content-Type: text/plain;charset=UTF-8
RECEIVE:  Content-Length: 185
RECEIVE:  Connection: close
RECEIVE:  Cache-Control: no-store
RECEIVE:  Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=llaOyamuJxVpKfThHGOPD%2FZBEpPmKjhVXUnKqTqfSHQ5S2FV5OE%2F2zx7qm5kxohEemAB3XcQJsT%2FaRhyY%2BSDXXerPs8tsplhEO0aQ%2BgU1vKnabT3422clYjpPO2Ljsf"}],"group":"cf-nel","max_age":604800}
RECEIVE:  NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
RECEIVE:  Server: cloudflare
RECEIVE:  CF-RAY: 888372431c3da968-SYD
RECEIVE:  alt-svc: h3=":443"; ma=86400
RECEIVE:
RECEIVE:  Error: Failed to find zone '%h/nic/update?system=dyndns'
RECEIVE:      at Cloudflare.findZone (index.js:25:13)
RECEIVE:      at async informAPI (index.js:126:29)
RECEIVE:      at async handleRequest (index.js:109:5)

I'm guessing it's something within the USG that's appending the extra "/nic/update?system=dyndns&hostname=hostname.xxxyyy.com&myip=12.12.12.12"

Any thoughts on how to address this?

[MatthewA1]

What did you put in the server field in the web UI? For the USG, you only put the server FQDN, not the path with variables.

[kdmitriy]

Any updates on this? When I run without variables I get the following: /update?ip=%i&hostname=%h.^Cinadyn[1861141]: STOP command received, exiting. root@UXG-Pro:/# inadyn -n -1 --force -f /run/ddns-ppp0-inadyn.conf inadyn[1872452]: In-a-dyn version 2.9.1 -- Dynamic DNS update client. inadyn[1872452]: Update forced for alias subexampledomain.net, new IP# XX.XX.XX.XX inadyn[1872452]: Fatal error in DDNS server response: inadyn[1872452]: [400 Bad Request]

400 Bad Request

---

cloudflare inadyn[1872452]: Error response from DDNS server, exiting! inadyn[1872452]: Error code 48: DDNS server response not OK root@UXG-Pro:/#

[packetdog]

For the USG Pro 4 I can confirm that I had this issue, and then when I truncated the server address to workername.accountsubdomain.workers.dev in the ubiquiti network application everything started to work great.

I have not tested this with the UXG yet, but I'm looking forward to it.

Thanks to the dev team for their work, this is fantastic.

[MatthewA1]

I have set this up on a UXG Pro, and it is the same as the UDM series: DO include the full path with variables. Example: unifi-cloudflare-ddns.accountsubdomain.workers.dev/update?ip=%i&hostname=%h

The rules come down to this: (Use service dyndns for both options)

• For older gateways that use EdgeOS (USG, USG Pro): Use only the FQDN unifi-cloudflare-ddns.accountsubdomain.workers.dev
• For newer gateways (UDM (all), UDW, UDR, UXG (Max, Pro), UCG Ultra): Use the FQDN followed by the path with variables unifi-cloudflare-ddns.accountsubdomain.workers.dev/update?ip=%i&hostname=%h Note: This probably also includes the new lower spec UX and UXG Lite, but I'm not positive they use the same software stack

I've personally tested this works correctly on the USG-Pro-4, UDM-Pro, UDM-SE, and UXG-Pro. If someone has a UX to test this on, that might be good. It appears to be a much lower spec system than anything else currently available, so maybe it doesn't support this feature or use the same software (though I expect it probably does).

[kdmitriy]

@MatthewA1 So I had no issues with the actual domain. However when I specify a subdomain after I already had my A record created, I now get a different error. Not sure why it does not want to function with a domain. root@UXG-Pro:~# inadyn -n -1 --force -f /run/ddns-ppp0-inadyn.conf inadyn[2210461]: In-a-dyn version 2.9.1 -- Dynamic DNS update client. inadyn[2210461]: Update forced for alias sub.example.com, new IP# XX.XX.XX.XX inadyn[2210461]: Temporary error in DDNS server response: inadyn[2210461]: [500 Internal Server Error] Error: Failed to find zone 'sub.example.com' at Cloudflare.findZone (index.js:25:13) at async informAPI (index.js:126:29) at async handleRequest (index.js:109:5) inadyn[2210461]: Will retry again in 600 sec ...

[kdmitriy]

Update: Looking at the logs, CloudFront API complained about failing to find zone associated with sub.example.com. { "message": [ "CloudflareApiException", "Error: Failed to find zone 'sub.example.com'" ], Looking at the documentation here, it looks like I couldn't just create API key for the sub domain sounds like it is just not supported for free users and only available to enterprise. That's a bummer. https://community.cloudflare.com/t/edit-zone-dns-api-token-for-subdomain-only/520124

[MatthewA1]

Unfortunately I believe that is correct. Did switching to a zone-wide API key fix your issue?

[kdmitriy]

Unfortunately I believe that is correct. Did switching to a zone-wide API key fix your issue?

That didn't work unfortunately. Makes me miss Google DynDNS that was killed.

[MatthewA1]

Try a token that has permissions to all zones in your account and see if that works just to see if maybe there's some weird scoping problem.

[Rubeast]

Same error..

RECEIVE:  Error: Failed to find zone '%h/nic/update?system=dyndns'
RECEIVE:      at Cloudflare.findZone (index.js:26:13)
RECEIVE:      at async informAPI (index.js:118:29)
RECEIVE:      at async handleRequest (index.js:108:20)

No solutions found I guess..?

[packetdog]

There's lots of solutions found. Have you completed the following? Please advise:

The rules come down to this: (Use service dyndns for both options)

• For older gateways that use EdgeOS (USG, USG Pro): Use only the FQDN unifi-cloudflare-ddns.accountsubdomain.workers.dev

• For newer gateways (UDM (all), UDW, UDR, UXG (Max, Pro), UCG Ultra): Use the FQDN followed by the path with variables unifi-cloudflare-ddns.accountsubdomain.workers.dev/update?ip=%i&hostname=%h Note: This probably also includes the new lower spec UX and UXG Lite, but I'm not positive they use the same software stack

[Rubeast]

Ok. It seems that I misunderstood. In my mind I read that i had to use the FQDN and was thinking "that is what I'm using.." But I never tried to ONLY use the FQDN as the servername. The way you written it this time made that clear to me.

It works now. Thank you!

[MatthewA1]

Can this be closed @thadius83?

[stonewalljones]

This worked for me. I would suggest adding this to the setup instructions for the USGs though.

[Rubeast]

The instructions do say "For older UniFi devices, omit the URL path." But I would also suggest to make it more clear in the instructions and format it like @packetdog has written.

[willswire]

There is some great discussion here that I would like to capture in official documentation in a new /docs folder. @MatthewA1 would you consider writing up your findings in a new /docs/troubleshooting.md file?