Feature request: Disable "lookup IP addresses do not match" healthcheck? #222

New Issue

saavagebueno · 2025-11-20T04:21:40-05:00

saavagebueno commented

2025-11-20 04:21:40 -05:00

Originally created by @raman325 on GitHub (Oct 16, 2022).

Originally assigned to: @qdm12 on GitHub.

What's the feature?

Not sure if this is a feature request or if I am just missing something, but is there a way to disable this healthcheck? I am using the updater to set an external IP for my home server. To keep internal calls from going out to Cloudflare, my internal DNS server responds with the internal IP for the home server so when the container tries to validate the IP, the validation fails.

When I first set this up I did not have the option to use hairpinning which is why I set it up this way. I have to look into whether I can leverage it or not, but in the interim, just looking for a way to avoid these failed healthchecks. Thanks in advance!

Originally created by @raman325 on GitHub (Oct 16, 2022). Originally assigned to: @qdm12 on GitHub. ## What's the feature? Not sure if this is a feature request or if I am just missing something, but is there a way to disable this healthcheck? I am using the updater to set an external IP for my home server. To keep internal calls from going out to Cloudflare, my internal DNS server responds with the internal IP for the home server so when the container tries to validate the IP, the validation fails. When I first set this up I did not have the option to use hairpinning which is why I set it up this way. I have to look into whether I can leverage it or not, but in the interim, just looking for a way to avoid these failed healthchecks. Thanks in advance!

saavagebueno closed this issue

2025-11-20 04:21:41 -05:00

saavagebueno commented

2025-11-20 04:21:41 -05:00

@nealey commented on GitHub (Nov 22, 2022):

I found this bug researching the same problem, with the same home DNS setup. Because I'm running under Docker, I was able to tell the container to use a CloudFlare DNS server (1.1.1.1), which fixed the failing healthcheck.

@nealey commented on GitHub (Nov 22, 2022): I found this bug researching the same problem, with the same home DNS setup. Because I'm running under Docker, I was able to tell the container to use a CloudFlare DNS server (1.1.1.1), which fixed the failing healthcheck.

saavagebueno commented

2025-11-20 04:21:41 -05:00

@raman325 commented on GitHub (Nov 22, 2022):

thanks for the tip, didn't realize how simple it was to override DNS for a container.

For anyone using docker run who runs into this issue, just add a --dns <dns_server> for each of the DNS servers you want the container to use

@raman325 commented on GitHub (Nov 22, 2022): thanks for the tip, didn't realize how simple it was to override DNS for a container. For anyone using `docker run` who runs into this issue, just add a `--dns <dns_server>` for each of the DNS servers you want the container to use

saavagebueno commented

2025-11-20 04:21:41 -05:00

@qdm12 commented on GitHub (Dec 7, 2022):

Added RESOLVER_ADDRESS and RESOLVER_TIMEOUT environment variables in 3250678c27a591b21bb18fb687481939a01350c1

It defaults to the default DNS resolver, and the resolver is used by both the healthcheck and the main run loop checking for IP address differences.

You can use for example RESOLVER_ADDRESS=1.1.1.1:53, RESOLVER_TIMEOUT defaults to 5 seconds.

@qdm12 commented on GitHub (Dec 7, 2022): Added `RESOLVER_ADDRESS` and `RESOLVER_TIMEOUT` environment variables in 3250678c27a591b21bb18fb687481939a01350c1 It defaults to the default DNS resolver, and the resolver is used by both the healthcheck and the main run loop checking for IP address differences. You can use for example `RESOLVER_ADDRESS=1.1.1.1:53`, `RESOLVER_TIMEOUT` defaults to 5 seconds.

saavagebueno referenced this issue

2025-11-20 04:25:39 -05:00

[PR #285] [MERGED] Add support for Dynu.com #673

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ddns-updater#222