mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
DNS monitor -- allow hostname for resolver #3295
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#3295
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Speedg33k on GitHub (Apr 24, 2024).
📑 I have found these related issues/pull requests
I did not see any similar issues posted,
🏷️ Feature Request Type
Change to existing monitor DNS Monitor
🔖 Feature description
The ability to specify the resolver by hostname rather than IP address would be great.
✔️ Solution
I am monitoring some websites, and want to also monitor the NSs for those sites, but the hosting providers tend to shuffle ip addresses and break my monitors.
❓ Alternatives
I can't see any alternatives to allowing a hostname, but feel free to point out anything I missed.
📝 Additional Context
Allowing a hostname would remove the necessity to update monitors every time a hosting provider moves a NS to a new host.
@Speedg33k commented on GitHub (Apr 24, 2024):
@CommanderStorm commented on GitHub (Apr 24, 2024):
The resolver server is just the ip adress of the DNS Resolver.
This should be verrry static.
Why don't you use a normal DNS provider like cloudflare which does not switch where the DNS Resolver lives?
Was this an outage of your cloud provider (which?) or what do you mean by the following
@Speedg33k commented on GitHub (Apr 24, 2024):
Thanks for the quick response! Uptime Kuma is a gem, and I sincerely hope I can help add a bit more precision to the DNS monitor.
Nameserver IP addresses do change.
Maintenance and failover are 2 cases where this happens.
If I query Cloudflare or other public DNS servers, I will get an answer, even if one of the name servers is fully down.
The goal is to detect individual server failure, even if we have redundant servers.
Querying cloud flare or other public DNS would mask the single failure issue.
On the detection side, we need the ability to query by host name and by IP to eliminate the redundancy, and detect individual outages even if a failover has occurred.
The only thing that is missing is the ability to specify a host name.
@CommanderStorm commented on GitHub (Apr 24, 2024):
So you want to specify this single resolver server of the cloud provider.
How would a hostname solve this but not an IP?
I don't get why you need the following:
Would the following not be sufficient?
@Speedg33k commented on GitHub (Apr 25, 2024):
Example. (I have several other use cases but this is the least complicated I could produce off the cuff)
We have a DNS Monitor for mystuff.com, using 1.2.3.4. 1.2.3.4 is hosted by foo.com
Foo.com is replacing a server and updates the DNS record for NS1.foo.com from 1.2.3.4 to 1.2.3.5. TTLs expire, DNS propagates, and then foo.com turns off 1.2.3.4. My monitor now fails, even though public DNS is still working.
So I should use public DNS like 1.1.1.1 and my monitor would not fail? True, but ---
We set our monitor to 1.1.1.1 instead ---
1.1.1.1 gets eaten by a fancy bear (halts and catches fire). My monitor now fails even though all of foo.com and mystuff.com is working fine.
If I can monitor NS1.foo.com I do not get failures when a 3rd party (1.1.1.1) goes offline, nor do I see false outages when foo.com replaces hardware and the IP changes.
I see no downside to allowing the DNS Monitor to connect by hostname, but I look forward to getting your perspective.
-Brian
-------- Original message --------
From: Frank Elsinga @.>
Date: 4/24/24 10:58 PM (GMT-05:00)
To: louislam/uptime-kuma @.>
Cc: Brian Benner @.>, Author @.>
Subject: Re: [louislam/uptime-kuma] DNS monitor -- allow hostname for resolver (Issue #4707)
So you want to specify this single resolver server of the cloud provider.
How would a hostname solve this but not an IP?
I don't get why you need the following:
we need the ability to query by host name and by IP to eliminate the redundancy, and detect individual outages even if a failover has occurred.
Would the following not be sufficient?
Cloudprovider DNS-NS Group
|---> DNS Monitor NS via Resovler IP1
|---> DNS Monitor NS via Resovler IP2
|---> DNS Monitor NS via Resovler IP3
—
Reply to this email directly, view it on GitHubhttps://github.com/louislam/uptime-kuma/issues/4707#issuecomment-2076262413, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVGLFF3IDOHUT5K5SORL7VDY7BWM7AVCNFSM6AAAAABGXR63JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZWGI3DENBRGM.
You are receiving this because you authored the thread.Message ID: @.***>
@CommanderStorm commented on GitHub (Apr 25, 2024):
In that case, the monitor would also not work if that is the configured DNS resolver.
=> you would not be able to resolve NS1.foo.com
I think this would be worse as this mechanism or failour case would be entirely intransparent.
Other things where you configure a dns reolver such as an OS also don't have hostname support..
Why don't you use your cloud providers' dns resolver if you don't trust 1.1.1.1 and don't want to use a second monitor with for example 8.8.8.8?
@Speedg33k commented on GitHub (Apr 25, 2024):
The systems DNS resolver should be a list. For example 1.1.1.1 4.2.2.4 and 8.8.8.8 for redundancy.
If 1.1.1.1 fails The system will still be able to resolve FS1.foo.com and the monitor carries on correctly reporting the latency and functionality of the actual DNS server for the domain I am responsible for monitoring.
Downsides to using 1.1.1.1
Hides individual NS outages.
Eliminates all latency data for the authoritative server, we see latency for 1.1.1.1
Caching will entirely hide an outage until the TTL expires and the whole world gets to enjoy the outage.
Is there any downside to allowing a hostname?
-Brian
-------- Original message --------
From: Frank Elsinga @.>
Date: 4/25/24 6:16 AM (GMT-05:00)
To: louislam/uptime-kuma @.>
Cc: Brian Benner @.>, Author @.>
Subject: Re: [louislam/uptime-kuma] DNS monitor -- allow hostname for resolver (Issue #4707)
1.1.1.1 gets eaten by a fancy bear
In that case, the monitor would also not work if that is the configured DNS resolver.
=> you would not be able to resolve NS1.foo.com
I think this would be worse as this mechanism or failour case would be entirely intransparent.
Other things where you configure a dns reolver such as an OS also don't have hostname support..
Why don't you use your cloud providers' dns resolver if you don't trust 1.1.1.1 and don't want to use a second monitor with for example 8.8.8.8?
—
Reply to this email directly, view it on GitHubhttps://github.com/louislam/uptime-kuma/issues/4707#issuecomment-2076843576, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVGLFF6QXAR6DG6N5ZR43ITY7DJW3AVCNFSM6AAAAABGXR63JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZWHA2DGNJXGY.
You are receiving this because you authored the thread.Message ID: @.***>
@CommanderStorm commented on GitHub (Apr 25, 2024):
I think you forgot to answer above.
I do think that you can just solve it with the existing tools.
I would assume (as for every nonstandard feature which is unclear to use) there to be a nontrivial amount of support nessesary.
Also see above:
I think this would be worse as this mechanism or failour case would be entirely intransparent.
@Speedg33k commented on GitHub (Apr 25, 2024):
The downsides that I listed for using 1.1.1.1 also apply to using "My cloud providers DNS"
The exact same downsides apply. It would no longer collect latency data, and caching would hide outages.
-Brian
-------- Original message --------
From: Frank Elsinga @.>
Date: 4/25/24 10:52 AM (GMT-05:00)
To: louislam/uptime-kuma @.>
Cc: Brian Benner @.>, Author @.>
Subject: Re: [louislam/uptime-kuma] DNS monitor -- allow hostname for resolver (Issue #4707)
Why don't you use your cloud providers' dns resolver if you don't trust 1.1.1.1 and don't want to use a second monitor with for example 8.8.8.8?
I think you forgot to answer above.
I do think that you can just solve it with the existing tools.
Is there any downside to allowing a hostname?
I would assume (as for every nonstandard feature which is unclear to use) there to be a nontrivial amount of support nessesary.
Also see above:
I think this would be worse as this mechanism or failour case would be entirely intransparent.
—
Reply to this email directly, view it on GitHubhttps://github.com/louislam/uptime-kuma/issues/4707#issuecomment-2077437016, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVGLFF7XD5CN4ROVPW4NQ6LY7EKBBAVCNFSM6AAAAABGXR63JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGQZTOMBRGY.
You are receiving this because you authored the thread.Message ID: @.***>
@CommanderStorm commented on GitHub (Apr 25, 2024):
I think making it into a list of resolvers (i.e. the same way the OS handles it is a) is a better call as this does not introduce the hidden failour case.
You said that you had
Would this fit into them? If not what are they?
@Speedg33k commented on GitHub (Apr 25, 2024):
The systems DNS resolver should be a list.
The monitors DNS resolver should be configurable as an IP or a hostname.
Depending on use case you may need to use one or the other.
-Brian
-------- Original message --------
From: Frank Elsinga @.>
Date: 4/25/24 6:50 PM (GMT-05:00)
To: louislam/uptime-kuma @.>
Cc: Brian Benner @.>, Author @.>
Subject: Re: [louislam/uptime-kuma] DNS monitor -- allow hostname for resolver (Issue #4707)
The systems DNS resolver should be a list. For example 1.1.1.1, 4.2.2.4 and 8.8.8.8 for redundancy.
I think making it into a list of resolvers (i.e. the same way the OS handles it is a) is a better call as this does not introduce the hidden failour case.
You said that you had
several other use cases but this is the least complicated I could produce off the cuff
Would this fit into them? If not what are they?
—
Reply to this email directly, view it on GitHubhttps://github.com/louislam/uptime-kuma/issues/4707#issuecomment-2078296519, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVGLFF6XZICTTWHUWVNVA73Y7GCCHAVCNFSM6AAAAABGXR63JWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYGI4TMNJRHE.
You are receiving this because you authored the thread.Message ID: @.***>
@CommanderStorm commented on GitHub (Apr 25, 2024):
Why? (it should be this way is not really an argument)
It does resolve the having to go to a backup dns resolver as you outlined above.
=> no false positives, no hidden failiour cases
Reiterating my question:
@chris114782 commented on GitHub (Jul 9, 2024):
I'm having this same issue, I want to monitor the DNS responses of my own local resolver, which exists on the host machine kuma's docker container runs on, so I want to use host.docker.internal as the resolver name.
Essentially the resolver is the target of my probe, not the hostname being resolved (which ultimately i don't care about, i'll just use something always likely to be resolveable like google or whatever)
@Speedg33k commented on GitHub (Jul 9, 2024):
Chris, I would love to see this changed. I hope you have better luck communicating the need than I did. If I can be of any assistance let me know.
@GasPar-Sec commented on GitHub (Mar 11, 2025):
Hi
I don't know if I can comment here to restart the discussion or if I need to create a new issue.
I have the same exact need as the original poster, but I will add some context.
I have a client who exposes their DNS server on the internet. I can't go into details about the reason, but it's a requirement in their architecture. Let's say their domain, example.com, is tied to their public IP which exposes the DNS service. This IP is dynamic, so it can change over time and at any moment. Fortunately, dynDNS updates its A record for example.com with the new IP.
This means that the 'Resolver Server' will change its IP over time. By being able to use a hostname instead of an IP, I wouldn't need to manually update the IP in the resolver, but just follow the hostname that gets updated.
In the same way that in a nslookup you can specify the resolver server using a hostname (here, dns.google instead of 8.8.8.8)."
@Speedg33k commented on GitHub (Mar 14, 2025):
I am still interested in this. I don't think I adequately explained the use cases, and felt frustrated with the "solutions"
If you manage other people's DNS infrastructure, this is an essential feature. DNS hijack detection alone would make this worth the price of admission.