DNS monitor -- allow hostname for resolver

[Speedg33k]

📑 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]

[CommanderStorm]

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

tend to shuffle ip addresses

[Speedg33k]

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]

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

[Speedg33k]

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]

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?

[Speedg33k]

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]

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.

[Speedg33k]

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]

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?

[Speedg33k]

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]

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:

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?

[chris114782]

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]

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.