DNS monitor -- allow hostname for resolver
Speedg33k opened this issue · comments
📑 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.
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
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
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?
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.
The systems DNS resolver should be a list. For example
1.1.1.1,4.2.2.4and8.8.8.8for 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?
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?
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)
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.