search

qdm12 / ddns-updater

Container to update DNS records periodically with WebUI for many DNS providers
https://hub.docker.com/r/qmcgaw/ddns-updater/
MIT License
1.61k stars 156 forks source link

Bug: non-update shows as update #117

Closed bcurran3 closed 7 months ago

bcurran3 commented 3 years ago

TLDR: Describe your issue in a one liner here

Hi Quentin,

Wanted to share some weirdness. IP has not changed in months. All IPs redacted are identical. No changes in months.

image

  1. Is this urgent?

    • [ ] Yes
    • [X] No

  2. What DNS service provider(s) are you using?

    • [ ] Cloudflare
    • [ ] DDNSS.de
    • [ ] DonDominio
    • [ ] DNSOMatic
    • [ ] DNSPod
    • [ ] Dreamhost
    • [ ] DuckDNS
    • [X] DynDNS
    • [ ] GoDaddy
    • [ ] Google
    • [ ] He.net
    • [ ] Infomaniak
    • [ ] Namecheap
    • [ ] NoIP

  3. What's the version of the program?

    See the line at the top of your logs

Running version latest built on 2020-11-11T22:29:05Z (commit 166b0c7)

  1. What are you using to run the container?

    • [ ] Docker run
    • [ ] Docker Compose
    • [ ] Kubernetes
    • [ ] Docker stack
    • [ ] Docker swarm
    • [ ] Podman
    • [X] Other:

  2. Extra information

Logs:

Configuration file (remove your credentials!):

Host OS:

Ubuntu 20.04 LTS

qdm12 commented 3 years ago

Hello there!

Do you mean your IP did not change in months but the container shows an update success 40h ago despite it not changing?

bcurran3 commented 3 years ago

Correctomatico!

qdm12 commented 3 years ago

Correctomatico!

That means yes right? 😅

Maybe you rebooted the container 40 hours ago? It does force the update at start (maybe, not too sure but I can check). Anyway let me know if this weirdness happens again. I'll investigate later if you don't mind, so let's keep the issue opened.

fredericrous commented 3 years ago

I think that adding debug logs would help indicate what is happening here and especially if it's related to ddns-updater or not. See my comment https://github.com/qdm12/ddns-updater/pull/164#pullrequestreview-585460089

armanatz commented 3 years ago

@qdm12 I can confirm that this is happening to me as well. IP addresses are showing as updated even though the actual IP never changed. I am using Cloudflare DNS so not sure if it is related to proxying. This is making my Gotify notifications to go crazy as I am getting notifications every 10 mins. Had to disable Gotify for this container as I was missing other important notifications. Any thing I can provide to help with this bug?

qdm12 commented 3 years ago

Did you set the proxied option? If your domain is behind Cloudflare proxy, the IP address of your domain will be one of Cloudflare's servers and not your direct IP address. That's most likely why it triggers an update every period. With that option, the program uses the last IP address updated stored in updates.json and only trigger an update when it's different from your public IP address.

Note that works to detect changes BUT won't detect if someone changes the IP address on Cloudflare's UI, as it only triggers when your public IP address changes & is different from the last IP address used in an update.

armanatz commented 3 years ago

Yes I do have proxied: true in my config and I can confirm that the IP address is indeed being set correctly in Cloudflare A name record. In the container's webui I can also confirm that the IP addresses are all my external IP. So for all intents and purposes, everything seems to be rigged up fine

qdm12 commented 3 years ago

I just added some debug logs you can enable with -e LOG_LEVEL=debug which should explain for each record why they are getting updated or not. Maybe try with:

docker pull qmcgaw/ddns-updater

and post back your logs?

bcurran3 commented 3 years ago

Correctomatico!

That means yes right? 😅

Maybe you rebooted the container 40 hours ago? It does force the update at start (maybe, not too sure but I can check). Anyway let me know if this weirdness happens again. I'll investigate later if you don't mind, so let's keep the issue opened.

Sorry for the very late reply. Correctomatico = yes. :)

Reboots from logs around the time I opened the issue (Nov 17, 2020): reboot system boot 5.4.0-53-generic Sun Nov 15 02:04 - 00:20 (13+22:15) <--- based on this I probably did reboot ~40 hours ago reboot system boot 5.4.0-52-generic Wed Nov 4 06:57 - 02:01 (10+19:04)

I have a new IP since then, currently "Previous IPs" shows the same .84 twice ", and 3 more"

Not sure what already happens and don't mean to tell you what to do, but how about the current IP saved to a temp text file and then on running the program again check that file to see if the IP has changed or not? If not, then don't log a change.

OR

On the webpage printout a table with history of the IP address along with the check date and other related info. (I think you might have mentioned you were going to do that anyway.)

armanatz commented 3 years ago

I just added some debug logs you can enable with -e LOG_LEVEL=debug which should explain for each record why they are getting updated or not. Maybe try with:

docker pull qmcgaw/ddns-updater

and post back your logs?

Here's the interesting thing. After pulling the latest update and setting LOG_LEVEL=debug, the container has been skipping updates since no changes were detected between local and Cloudflare. So confused. It hasn't updated for 20 hours

qdm12 commented 3 years ago

Hey bcurran3! I wrote this in the readme to clarify how the program works and why 😉

I think the craziness re-updating a record that did not change IP address was due to DNS resolutions failing from time to time. If so, I took the design decision to still make the update call, as for example your record could not exist or be empty.

I mitigated it a few days ago with https://github.com/qdm12/ddns-updater/commit/d5e493667969f71382dc0480859087b8d2cdf477 where it now tries to DNS resolve 5 times before failing. I also had this behavior where some (duckdns) records would not DNS resolve from time to time with a timeout error.

Now I would prefer to leave the logic as is (without adding deduplication etc.) as, even if the IP address is the same, an update occurred. If someone manually changes the record on the DNS provider web UI, the program still re-changed the IP address, although it might had changed it back to the same IP address as before.

Finally, yes there is a timestamp stored for every update, although not shown in the UI. I'm a bit pausing effort on the current UI as I would like to get a more interactive React UI sometime (sorry, I know progress is very slooowww, gluetun is also taking a lot of my time, that's what happens when creating multiple projects 😅)

EDIT: Let's keep this opened for a few days so you guys let me know if the update craziness happens again. I think it stopped for me.

qdm12 commented 3 years ago

@armanatz have a look at the architecture section in the readme to know a bit more what's it's doing for Cloudflare proxied records.

Basically it should only update when your public IP address changes, as it can't be aware of the IP address set on Cloudflare.

walderston commented 3 years ago

@bcurran3 out of interest, do you have an internal DNS which resolves the domain? I'm an internal DNS resolver and have mydomain.com resolved to an internal IP address and every time ddns-updater runs, it changes the IP address in cloudflare despite it being correct.

from Portainer: image from GUI: image

@qdm12 could specifying a DNS resolver be added?

qdm12 commented 3 years ago

@walderston you can specify a resolver for the container with --dns 1.1.1.1 for example. I could support specifying it in the code but i think it's better to leave up to the container setup.

If you use the proxied option (only available for Cloudflare though), it won't do a healthcheck for that record and won't DNS resolve the hostname. Let me know if this is not happening for you.

bcurran3 commented 3 years ago

@walderston - Yes I have an internal DNS server but the container has dns_servers: "1.1.1.1" in the setup.

My setup is hybrid - I have an A record to my domain on my internal DNS and a CNAME to my domain on external DNS pointing to the DDNS record FQDN.

@qdm12 - Not of much help but my current status is "Up to date (no IP change for 7d), 120h58m35s ago" which appears accurate as I had an outage and my IP changed.

qdm12 commented 3 years ago

My setup is hybrid - I have an A record to my domain on my internal DNS and a CNAME to my domain on external DNS pointing to the DDNS record FQDN.

This is confusing but you have my respect 😄

Not of much help but my current status is "Up to date (no IP change for 7d), 120h58m35s ago" which appears accurate as I had an outage and my IP changed.

Cool, let me you if you see inconsistencies again with the update times, and also check if it matches your debug logs (set the logging level to debug too to have that).

Basti-Fantasti commented 3 years ago

I think I'm facing the same issue.

I've set up my subdomain config for a subdomain on dynv6.com

I've fired up the docker container with docker compose. The IP was already set correctly at dynv6 for my subdomain By my router, so I expected no change/update to be needed.

Then I manually changed the IP of my subdomain using the dynv6 website to a random IP - just to check if the update would work afterwards.

Gotify keeps sending me now messages every 5 minutes that the update was successful but the correct IP is not set. So I assume that the updater recognizes that an old/wrong IP is set but the update is not triggered.

The correct current IP (my actual public IP) is shown on the UI and on gotify, but the update Itself seems to be skipped.

Edit: I forced a reconnect of my Internet connection to get a new IP. Now the update was triggered

Edit2: but the gotify push message And the UI still show the previous public IP.

qdm12 commented 3 years ago

What do you get in your logs? Try also setting LOG_LEVEL=debug to see why it skips the update

Basti-Fantasti commented 3 years ago

I've set the LOG_LEVEL variable to debug in my docker-compose file and restarted the container (down/up)

but no log files are written (or I assume that I don't know where to look) and no additional infos are pushed to gotify.

Do I need to add the debug setting in the config.json file or in my docker-compose.yml

qdm12 commented 3 years ago

@Basti-Fantasti try with docker-compose logs in the directory where your docker-compose.yml is

Basti-Fantasti commented 3 years ago

@qdm12 ok found it. I'll dig deeper and try to find the relevant information.

Thanks in advance

bcurran3 commented 3 years ago

Cool, let me you if you see inconsistencies again with the update times, and also check if it matches your debug logs (set the logging level to debug too to have that).

Nothing new to report yet: "Up to date (no IP change for 68d), 200h33m53s ago"

qdm12 commented 3 years ago

Hmm OK and I guess it rebooted 200h33m53s ago 🤔 A bit confusing; I'll add some tests soon.

qdm12 commented 7 months ago

This might be fixed by now, feel free to let me know if someone has a similar issue still and I'll re-open. Thanks! 👍