search

louislam / uptime-kuma

A fancy self-hosted monitoring tool
https://uptime.kuma.pet
MIT License
59.7k stars 5.34k forks source link

Allow specifying DNS check "resolver server" by hostname #2330

Closed stephen304 closed 11 months ago

stephen304 commented 1 year ago

⚠️ Please verify that this feature request has NOT been suggested before.

🏷️ Feature Request Type

UI Feature

🔖 Feature description

I know it sounds weird, but it makes a lot of sense for dockerized setups. I have both uptime kuma and pihole running in containers, and I would like to have uptime kuma check pihole.

The first issue is that the local IP of the host machine which is mapped to the pihole container isn't available to the uptime kuma container, which I have made accessible using traefik. I solved this and other container reachability issues using the standard docker method of creating an external network, I called "healthcheck" that I add to uptime kuma and all containers I want to check.

The issue is that, once all relevant containers are in the "healthcheck" network, they can access each other using the docker-compose service name, which is automatically resolved to an IP address. For example, since my pihole container is just called "pihole" in my docker compose, I can ping "pihole" from inside my uptime kuma container like so:

root@8a60bc9850e9:/app# ping pihole
PING pihole (172.16.208.3) 56(84) bytes of data.
64 bytes from pihole.healthcheck (172.16.208.3): icmp_seq=1 ttl=64 time=0.142 ms
^C
--- pihole ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.142/0.142/0.142/0.000 ms

I can also add an uptime kuma DNS check using the pihole IP address directly (172.16.208.3) and that works as expected, though that IP is not guaranteed to be stable.

✔️ Solution

The solution would be to allow specifying a hostname for the resolver server, that way I could specify the pihole hostname. It could be resolved at check time and cause the check to fail if it cannot be resolved. That would allow us to use container hostname networking to do checks on DNS servers running in separate containers

❓ Alternatives

I'm not sure what workarounds are possible - maybe using host networking on uptime kuma and/or the pihole container would work but I haven't tried that. For now I specified the container IP directly and will just update it when it changes.

📝 Additional Context

Below you can also see that dig from inside the uptime kuma container to the LAN ip of the docker host fails with reply from unexpected source, but digging to the hostname @pihole succeeds - it would be nice for uptime kuma to similarly be able to take a hostname that can be resolved to the correct container IP:

root@8a60bc9850e9:/# dig google.com @192.168.100.4
;; reply from unexpected source: 172.16.208.1#53, expected 192.168.100.4#53
;; reply from unexpected source: 172.16.208.1#53, expected 192.168.100.4#53
;; reply from unexpected source: 172.16.208.1#53, expected 192.168.100.4#53

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> google.com @192.168.100.4
;; global options: +cmd
;; connection timed out; no servers could be reached
root@8a60bc9850e9:/# dig google.com @pihole

; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> google.com @pihole
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4528
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.            IN  A

;; ANSWER SECTION:
google.com.     136 IN  A   142.251.41.14

;; Query time: 0 msec
;; SERVER: 172.16.208.3#53(172.16.208.3)
;; WHEN: Fri Nov 18 05:54:25 UTC 2022
;; MSG SIZE  rcvd: 55
rezzorix commented 1 year ago

I think this could be helpful: https://docs.docker.com/config/containers/container-networking/

stephen304 commented 1 year ago

I think this could be helpful: https://docs.docker.com/config/containers/container-networking/

I'm not sure how that can help, I'm already publishing port 53 of my pihole container to the docker host as described there, and I can query it as you can see above. The issue is that uptime kuma fails to do a check against the ip of the host (maybe related to reply from unexpected source) while doing the same from a separate device on the network is successful (I'm using pihole for many devices so I know querying the host IP with the published port 53 is working). Additionally, the query from uptime kuma succeeds using the ephemeral container IP. Unless you are suggesting using the container hostname which is the part that fails because unlike dig, uptime kuma can't use a hostname as a resolver for a DNS check.

rezzorix commented 1 year ago

In general from your explanation it sounds like your network setup is a bit overcomplicated. Therefore I most likely misunderstood your post at first.

So question: Why wouldnt you give at least your pihole a fixed IP-address within your docker network? That would solve all your issues and no other work-around needed, no?

ftpd commented 1 year ago

I second to this feature request, as I'm in the same situation.

The issue is that uptime kuma fails to do a check against the ip of the host (maybe related to reply from unexpected source)

Unfortunately, UDP just works this way and we won't be able to 'fix' in on our side in any way. It seems that the packet has the address from routing table, not the one that the sender provided.

your network setup is a bit overcomplicated

Really? Having two containers in one internal docker's network is 'overcomplicated' network setup? Why?
They can communicate using the hostname and it's perfectly fine. Now we just would like to put the hostname instead of IP address.

Why wouldnt you give at least your pihole a fixed IP-address within your docker network?

Because this is something I would call 'overcomplication'. Addressing inside docker should be transparent to user.

PHPGangsta commented 1 year ago

I just wanted to add a DNS check to uptime-kuma, and put the hostname of one of my authoritative DNS Anycast clouds into the "Resolver Server" field. The error message is:

Invalid IP address: [anycast1.mydnsprovider.net]:53

If I put in an IP address, it works fine. But I don't want to put in an IP address there because it might change at any time. And I don't care about the IP address that my DNS provider uses, I just need to make sure that the NS server (or anycast cloud) that is in my NS records can resolve my domains.

CommanderStorm commented 1 year ago

But I don't want to put in an IP address there because it might change at any time.

That would be a defect on the side of the DNS Provider. The IP of a DNS Server is fixed, as ordinarily you can only configure the IP afaik Examples: 1.1.1.1 or 8.8.8.8

Resolving hostnames -> IPs is the whole point of an dns server...

CommanderStorm commented 11 months ago

Given that Resolving hostnames -> IPs is the whole point of an dns server I am going to close this as wontfix. I don't know of any services that allow inputting of hostnames into a dns field (how would resolving this hostname even work?)

Note that configuring containers dns server is possible via upstream-mechanisms: https://docs.docker.com/network/#dns-services

stephen304 commented 11 months ago

Given that Resolving hostnames -> IPs is the whole point of an dns server I am going to close this as wontfix. I don't know of any services that allow inputting of hostnames into a dns field (how would resolving this hostname even work?)

Note that configuring containers dns server is possible via upstream-mechanisms: https://docs.docker.com/network/#dns-services

I guess I will assign my dns container a static IP then. Setting the uptime-kuma container's DNS to my dns server doesn't help because then if my DNS container goes down, uptime-kuma won't be able to notify me. My docker host already has a static IP (which is the static IP actual clients using the dns server use to reach it), but I wanted to avoid having to unnecessarily allocate static IPs inside the docker container IP pool since everything within a docker network can be resolved via hostnames, and uptime-kuma can reach my dns container through a docker network using a hostname anyway.