starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Specify DNS servers to be used for uptime kuma in Settings #2249

New issue

Closed

opened 2026-02-28 02:48:00 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 02:48:00 -05:00

Owner

Originally created by @redtripleAAA on GitHub (Jun 11, 2023).

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

I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

Feature Request - Specify DNS servers to be used for uptime kuma in Settings

This is important in case we have two A records, and I wish to focus on specific DNS record that can be resolved when pointing to a DNS server.

btw, it works just fine when select DNS host monitor.

here:

✔️ Solution

To add settings page in the UI or even docker run parameters to specify DNS servers will be used for resolving DNS requests from uptime kuma.

/etc/hosts

/etc/resolv.conf

❓ Alternatives

Currently, you have to have some DNS input on the docker host or global DNS to get that working, still will be conflicting if there is more than A record.

📝 Additional Context

No response

Originally created by @redtripleAAA on GitHub (Jun 11, 2023). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type UI Feature ### 🔖 Feature description Feature Request - Specify DNS servers to be used for uptime kuma in Settings This is important in case we have two A records, and I wish to focus on specific DNS record that can be resolved when pointing to a DNS server. btw, it works just fine when select DNS host monitor. here: ![Screenshot 2023-06-11 at 5 52 40 AM](https://github.com/louislam/uptime-kuma/assets/5244872/85f7eaa7-579c-416f-9c76-b3ae1cebc927) ### ✔️ Solution To add settings page in the UI or even docker run parameters to specify DNS servers will be used for resolving DNS requests from uptime kuma. `/etc/hosts` `/etc/resolv.conf` ### ❓ Alternatives Currently, you have to have some DNS input on the docker host or global DNS to get that working, still will be conflicting if there is more than A record. ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:48:00 -05:00

closed this issue
added the
feature-request

A:settings
labels

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@solracsf commented on GitHub (Jun 22, 2023):

What about:

docker run -d --dns="1.1.1.1" {OTHER OPTIONS} louislam/uptime-kuma:1

Could this work?

@solracsf commented on GitHub (Jun 22, 2023): What about: `docker run -d --dns="1.1.1.1" {OTHER OPTIONS} louislam/uptime-kuma:1` Could this work?

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@redtripleAAA commented on GitHub (Jun 22, 2023):

@solracsf is that an actual existing parameter that I can use?!
If yes! Then that answers my question!!

@redtripleAAA commented on GitHub (Jun 22, 2023): @solracsf is that an actual existing parameter that I can use?! If yes! Then that answers my question!!

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@solracsf commented on GitHub (Jun 23, 2023):

https://docs.docker.com/network/#dns-services

@solracsf commented on GitHub (Jun 23, 2023): https://docs.docker.com/network/#dns-services

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 5, 2023):

If yes! Then that answers my question

I am going to close this issue as resolved.
Utilising the platform-provided (node/docker) mechanisms for configuring dns resolution is likely a better choice than implementing this into our current stack

@CommanderStorm commented on GitHub (Dec 5, 2023): > If yes! Then that answers my question I am going to close this issue as resolved. Utilising the platform-provided (node/docker) mechanisms for configuring dns resolution is likely a better choice than implementing this into our current stack

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@maxjoehnk commented on GitHub (Dec 8, 2023):

This might be better suited for a new issue but I have a use case which cannot be solved with the dns docker setting.
I have a Status page for multiple customers with applications only available via their respective vpn.
I can connect the host to multiple vpns but as configuring multiple dns hosts doesn't try all of them I can't use dns entries of any but the first customers.
Obviously I could setup a custom dns server which delegates the relevant domains to their regarding dns servers but I would prefer a simpler solution.

My ideal solution would be the ability to configure remote agents which report back to my primary instance but as I understood this might be more complicated than allowing configuration of the dns server per health check.

@maxjoehnk commented on GitHub (Dec 8, 2023): This might be better suited for a new issue but I have a use case which cannot be solved with the dns docker setting. I have a Status page for multiple customers with applications only available via their respective vpn. I can connect the host to multiple vpns but as configuring multiple dns hosts doesn't try all of them I can't use dns entries of any but the first customers. Obviously I could setup a custom dns server which delegates the relevant domains to their regarding dns servers but I would prefer a simpler solution. My ideal solution would be the ability to configure remote agents which report back to my primary instance but as I understood this might be more complicated than allowing configuration of the dns server per health check.

deekerman commented

2026-02-28 02:48:07 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 8, 2023):

remote agents which report back

See these issues

the push-monitor
Remote executors #84
Per montior dns configuration: #1302

@CommanderStorm commented on GitHub (Dec 8, 2023): > remote agents which report back See these issues - the `push`-monitor - Remote executors #84 - Per montior dns configuration: #1302