[BUG] curl: (3) URL rejected: Malformed input to a URL function

[enjunear]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current Behavior

Opening this because #70 was closed without a resolution.

When running with docker-compose, the curl call to duckdns fails.

Expected Behavior

The call should not fail

Steps To Reproduce

1. Grab the sample docker-compose file from the readme.
2. BYO domain, token, etc.
3. Set UPDATE_IP=both (in my case)
4. docker-compose up
5. Watch it fail

Environment

- OS:Ubuntu 24.04
- How docker service was installed: By following the instructions on https://docs.docker.com/engine/install/

CPU architecture

x86-64

Docker creation

docker-compose.yml

---
services:
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    network_mode: host #optional
    environment:
      - PUID=1000 #optional
      - PGID=1000 #optional
      - TZ=Etc/UTC #optional
      - SUBDOMAINS=mydomain
      - TOKEN=my-super-secret-token
      - UPDATE_IP=both
      # - LOG_FILE=false #optional
    # volumes:
    #   - /path/to/duckdns/config:/config #optional
    restart: unless-stopped


to run:

docker --context server compose -f duckdns/docker-compose.yml up --detach

Container logs

[migrations] started
[migrations] no migrations found
───────────────────────────────────────

██╗     ███████╗██╗ ██████╗
██║     ██╔════╝██║██╔═══██╗
██║     ███████╗██║██║   ██║
██║     ╚════██║██║██║   ██║
███████╗███████║██║╚██████╔╝
╚══════╝╚══════╝╚═╝ ╚═════╝

Brought to you by linuxserver.io
───────────────────────────────────────

To support the app dev(s) visit:
DuckDNS: https://www.patreon.com/user?u=3209735

To support LSIO projects visit:
https://www.linuxserver.io/donate/

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────
Linuxserver.io version: 3a206e10-ls47
Build-date: 2025-03-10T03:58:13+00:00
───────────────────────────────────────

Detecting IPv4 and IPv6 via CloudFlare
curl: (3) URL rejected: Malformed input to a URL function
Something went wrong, please check your settings Fri Mar 14 18:42:58 AWST 2025
The response returned was:


[custom-init] No custom files found, skipping...
[ls.io-init] done.

[github-actions[bot]]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[enjunear]

Doing some troubleshooting, it seems the line to get the ipv6 address causes the issue.

Logs from manually running the lines:

michael@server:~$ dig +short ch txt whoami.cloudflare -4 @1.1.1.1 | sed 's/"//g'
123.456.789.123

michael@server:~$ dig +short ch txt whoami.cloudflare -6 @2606:4700:4700::1111 | sed 's/"//g'
;; UDP setup with 2606:4700:4700::1111#53(2606:4700:4700::1111) for whoami.cloudflare failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2606:4700:4700::1111#53(2606:4700:4700::1111) for whoami.cloudflare failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2606:4700:4700::1111#53(2606:4700:4700::1111) for whoami.cloudflare failed: network unreachable.
;; no servers could be reached

Running compose with - UPDATE_IP=ipv4 does the trick for now.

Might be worth doing some graceful fallback to ipv4 only.

[rosalesKevin]

I encountered the same error message, and after debugging for several days, I discovered that the issue was due to spaces between multiple domain names in the SUBDOMAINS variable.

For example, I had it set as: -SUBDOMAINS=domain1, domain2, etc.

However, the documentation specifies that there should be no spaces between domain names.

This might not be the issue in your case, but if anyone else facing a similar problem, double-check for unintended spaces in your configuration.

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[Hisui02]

I had both settings you guys say and I was having the same problem, it got solved disabling Cloudflare IP getting and using DuckDNS default.

On compose.yaml commented out the - UPDATE_IP=ipv4 line, the script inside the container uses DuckDNS service to retrieve the IP if it is not set and Cloudflare otherwise.

Debugging it seems that Cloudflare it getting times out:

root@server:/app# dig +short ch txt whoami.cloudflare -4 @1.1.1.1 | sed 's/"//g'
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; communications error to 1.1.1.1#53: timed out
;; no servers could be reached

But DuckDNS service doesn't:

root@server:/app# curl -sS --max-time 60 "https://www.duckdns.org/update?domains=${SUBDOMAINS}&token=${TOKEN}&ip=&verbose=true"
OK
<MY IP>

So my compose.yaml ends like this:

services:
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    network_mode: host #optional
    environment:
      - PUID=1000 #optional
      - PGID=1000 #optional
      - TZ=$COMMON_TIME_ZONE #optional
      - SUBDOMAINS=<subdomains>
      - TOKEN=<token>
    #  - UPDATE_IP=ipv4 #optional
      - LOG_FILE=true #optional
    volumes:
      - $CONFIG_PATH/duckdns/config:/config #optional
    restart: unless-stopped

[FWinkler79]

I have the same issue, and while leaving UPDATE_IP=both commented out fixes the issue, I don't think it is a good solution. Especially not, if like in my case you need updating IPv6 addresses. So it would really be great if someone on the linuxserver side could have a look at this.

I noticed that the linuxserver image for DuckDNS uses the following commands to resolve the IP addresses via CloudFlare (see root > app > duck.sh:

# for IPv4
dig +short ch txt whoami.cloudflare -4 @1.1.1.1 | sed 's/"//g'

# for IPv6
dig +short ch txt whoami.cloudflare -6 @2606:4700:4700::1111 | sed 's/"//g'

When I try to execute these commands in the running DuckDNS container like this ...

docker exec -it duckdns dig +short ch txt whoami.cloudflare -4 @1.1.1.1 | sed 's/"//g'
docker exec -it duckdns dig +short ch txt whoami.cloudflare -6 @2606:4700:4700::1111 | sed 's/"//g'

... it fails with an error like this:

# IPv4
;; communications error to 1.1.1.1#53: host unreachable
;; communications error to 1.1.1.1#53: host unreachable
;; communications error to 1.1.1.1#53: host unreachable
;; no servers could be reached

# IPv6
;; communications error to 2606:4700:4700::1111#53: permission denied
;; communications error to 2606:4700:4700::1111#53: permission denied
;; communications error to 2606:4700:4700::1111#53: permission denied
;; no servers could be reached

However, when I run it without the @ in front of the IP address, it returns a valid IPv4 address - strangely enough in both cases asking for an IPv4 and IPv6 address.

Could it be the Cloud Flare is requiring some kind of authentication now? Could it be the dig command has changed somehow?

[LinuxServer-CI]

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[drizuid]

Might be worth doing some graceful fallback to ipv4 only.

you specifically told it to do both, us telling it to ignore you would be inappropriate.

for other users, if you selected both and not using both works, this is again a choice you made. You likely do not have docker ipv6 properly setup causing a failure. I'm happy to provide guidance for enabling ipv6 in docker on discord, but this is not an appropriate location for help. As the OPs issue was self-inflicted and resolved, I will close this