Bug: Domain update status 'Unset' when it exists in system hosts file

[brammp]

TLDR: When the domain exists in /etc/hosts the domain status gets stuck on 'Unset', and is not updated when using binary on Linux

1. Is this urgent: No

2. DNS provider(s) you use: OVH & Custom

3. Program version: 2.9.0 (commit 78f30614b1d085ef6bfbfce92b0e45ca0204f42a)

4. What are you using to run the container: N/A, using the binary on Linux

5. Extra information:
   When the domain entry is removed from /etc/hosts everyting works as expected and the ip is updated after restarting the binary.
   To replicate make sure updates.json is empty.
   Also tested the Windows, MacOS/Darwin versions and Docker, and these are not effected.

Logs OVH:

2024-12-28T22:19:23Z INFO Settings summary:
├── HTTP client
|   └── Timeout: 20s
├── Update
|   ├── Period: 10m0s
|   └── Cooldown: 5m0s
├── Public IP fetching
|   ├── HTTP enabled: yes
|   ├── HTTP IP providers
|   |   └── all
|   ├── HTTP IPv4 providers
|   |   └── all
|   ├── HTTP IPv6 providers
|   |   └── all
|   ├── DNS enabled: yes
|   ├── DNS timeout: 3s
|   └── DNS over TLS providers
|       └── all
├── Resolver: use Go default resolver
├── Server
|   ├── Listening address: :8000
|   └── Root URL: /
├── Health
|   └── Server is disabled
├── Paths
|   ├── Data directory: ./data
|   ├── Config file: data/config.json
|   └── Umask: system default
├── Backup: disabled
└── Logger
    ├── Level: INFO
    └── Caller: hidden
2024-12-28T22:19:23Z INFO reading JSON config from file data/config.json
2024-12-28T22:19:23Z INFO Found 2 settings to update records
2024-12-28T22:19:23Z INFO Reading history from database: domain test.lan owner @ ipv4
2024-12-28T22:19:23Z INFO Reading history from database: domain test.lan owner @ ipv6
2024-12-28T22:19:23Z INFO [http server] http server listening on [::]:8000
2024-12-28T22:19:23Z INFO [backup] disabled
2024-12-28T22:19:23Z INFO obtaining ipv4 address succeeded after 1 failed try
^C2024-12-28T22:42:02Z WARN Caught OS signal, shutting down
2024-12-28T22:42:07Z WARN Shutdown timed out

Configuration file OVH:

{
    "settings": [
        {
        "provider": "ovh",
        "mode": "api",
        "domain": "quartz.nxdi.nl",
        "api_endpoint": "ovh-eu",
        "app_key": "<app_key>",
        "app_secret": "<app_secret>",
        "consumer_key": "<consumer_key>",
        "ip_version": "ipv4"
        },
         {
        "provider": "ovh",
        "mode": "api",
        "domain": "quartz.nxdi.nl",
        "api_endpoint": "ovh-eu",
        "app_key": "<app_key>",
        "app_secret": "<app_secret>",
        "consumer_key": "<consumer_key>",
        "ip_version": "ipv6",
        "ipv6_suffix": ""
        }
    ]
}

Logs Custom:

2024-12-28T23:31:59+01:00 INFO Settings summary:
├── HTTP client
|   └── Timeout: 20s
├── Update
|   ├── Period: 10m0s
|   └── Cooldown: 5m0s
├── Public IP fetching
|   ├── HTTP enabled: yes
|   ├── HTTP IP providers
|   |   └── all
|   ├── HTTP IPv4 providers
|   |   └── all
|   ├── HTTP IPv6 providers
|   |   └── all
|   ├── DNS enabled: yes
|   ├── DNS timeout: 3s
|   └── DNS over TLS providers
|       └── all
├── Resolver: use Go default resolver
├── Server
|   ├── Listening address: :8000
|   └── Root URL: /
├── Health
|   └── Server listening address: 127.0.0.1:9999
├── Paths
|   ├── Data directory: ./data
|   ├── Config file: data/config.json
|   └── Umask: system default
├── Backup: disabled
└── Logger
    ├── Level: INFO
    └── Caller: hidden
2024-12-28T23:31:59+01:00 INFO reading JSON config from file data/config.json
2024-12-28T23:31:59+01:00 INFO Found 2 settings to update records
2024-12-28T23:31:59+01:00 INFO Reading history from database: domain test.lan owner @ ipv4
2024-12-28T23:31:59+01:00 INFO Reading history from database: domain test.lan owner @ ipv6
2024-12-28T23:31:59+01:00 INFO [http server] http server listening on [::]:8000
2024-12-28T23:31:59+01:00 INFO [backup] disabled
2024-12-28T23:31:59+01:00 INFO obtaining ipv4 address succeeded after 1 failed try
2024/12/28 23:32:01 "GET http://localhost:8000/ HTTP/1.1" from 127.0.0.1:59368 - 200 2899B in 71.014µs
2024/12/28 23:32:01 "GET http://localhost:8000/static/styles.css HTTP/1.1" from 127.0.0.1:59368 - 200 3203B in 9.520991ms
2024/12/28 23:32:02 "GET http://localhost:8000/ HTTP/1.1" from 127.0.0.1:59368 - 200 2899B in 88.667µs
2024/12/28 23:32:02 "GET http://localhost:8000/static/styles.css HTTP/1.1" from 127.0.0.1:59368 - 200 3203B in 91.753µs
^C2024-12-28T23:40:48+01:00 WARN Caught OS signal, shutting down
2024-12-28T23:40:53+01:00 WARN Shutdown timed out

Configuration file Custom:

{
  "settings": [
    {
      "provider": "custom",
      "domain": "test.lan",
      "url": "https://dev.bramp.nl/ddns/update.php?domain=test.local&hostname=Dev-VM&token=<TokenHere>",
      "ipv4key": "ipv4",
      "ipv6key": "ipv6",
      "success_regex": "good",
      "ip_version": "ipv4",
      "ipv6_suffix": ""
    },
    {
      "provider": "custom",
      "domain": "test.lan",
      "url": "https://dev.bramp.nl/ddns/update.php?domain=test.local&hostname=Dev-VM&token=<TokenHere>",
      "ipv4key": "ipv4",
      "ipv6key": "ipv6",
      "success_regex": "good",
      "ip_version": "ipv6",
      "ipv6_suffix": ""
    }
  ]
}

Host OS(s):
Debian 12, Ubuntu 24.04,Fedora 41, Rocky Linux9, Alpine 3.21, Arch Linux,OpenSuse Leap 15.9, Centos-Stream 10

[Asklios]

I had the same issue with a persistent unset status using docker and qmcgaw/ddns-updater:v2.9.0
I temporarily fixed it by using an older version.

[ParzivalSan]

I have the same issue. I was working fine some weeks ago

[Aerya]

Hi,

Same here:
Unset , 2562047h47m16.854775807s ago

Config example:

{
  "settings": [
    {
      "provider": "cloudflare",
      "zone_identifier": "xx",
      "domain": "2fa.domain.tld",
      "ttl": 1,
      "token": "xxx",
      "ip_version": "ipv4",
      "ipv6_suffix": ""
    },
    {
      "provider": "cloudflare",
      "zone_identifier": "xx",
      "domain": "airdrop.domain.tld",
      "ttl": 1,
      "token": "xxx",
      "ip_version": "ipv4",
      "ipv6_suffix": ""
    },

services:
  ddns-updater:
    image: qmcgaw/ddns-updater:latest
    container_name: ddns-updater
    network_mode: bridge
    ports:
      - 1924:8000/tcp
    volumes:
      - /volume1/docker/ddns-updater:/updater/data
    environment:
      - CONFIG=
      - PERIOD=5m
      - UPDATE_COOLDOWN_PERIOD=5m
      - PUBLICIP_FETCHERS=all
      - PUBLICIP_HTTP_PROVIDERS=all
      - PUBLICIPV4_HTTP_PROVIDERS=all
      - PUBLICIPV6_HTTP_PROVIDERS=all
      - PUBLICIP_DNS_PROVIDERS=all
      - PUBLICIP_DNS_TIMEOUT=10s
      - HTTP_TIMEOUT=10s
      - TZ=Europe/Paris
      - LISTENING_ADDRESS=:8000
      - RESOLVER_ADDRESS=192.168.1.64:53
      - PUBLICIP_HTTP_PROVIDERS=ipleak,icanhazip,ipinfo
      - PUBLICIP_DNS_PROVIDERS=opendns
      - ROOT_URL=/
      - BACKUP_PERIOD=0
      - BACKUP_DIRECTORY=/updater/data
      - LOG_LEVEL=debug
      - LOG_CALLER=hidden
      - SHOUTRRR_ADDRESSES=discord://xxx@xxx
    restart: always
    labels:
      - com.centurylinklabs.watchtower.enable=true

Any update bout this?

[jrmagers]

I'm also having the same issue on v2.9.0. Downgrading to v2.8.2 did not fix it.

[pulsar895]

Same here with Docker latest, v2.8.2 and v.2.8.

[jrmagers]

I was able to fix this by setting network_mode: bridge in my docker-compose.yml file. Previously I was specifying a docker network.

  ddns-updater:
    image: qmcgaw/ddns-updater:latest
    container_name: ddns-updater
    hostname: ddns
    network_mode: bridge
    ports:
      - 8000:8000/tcp
...

[pulsar895]

No change for me with network_mode: bridge

edit: I fix my problem by using --env RESOLVER_ADDRESS=193.110.81.9:53. It's a local DNS issue on my side.