Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DNS monitor -- allow hostname for resolver #4707

Open
Speedg33k opened this issue Apr 24, 2024 · 12 comments
Open

DNS monitor -- allow hostname for resolver #4707

Speedg33k opened this issue Apr 24, 2024 · 12 comments
Labels
area:monitor Everything related to monitors feature-request Request for new features to be added question Further information is requested type:enhance-existing feature wants to enhance existing monitor

Comments

@Speedg33k
Copy link

Speedg33k commented Apr 24, 2024 •
edited

📑 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 Speedg33k added the feature-request Request for new features to be added label Apr 24, 2024
@Speedg33k
Copy link
Author

dns

@CommanderStorm
Copy link
Collaborator

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

@CommanderStorm CommanderStorm added question Further information is requested area:monitor Everything related to monitors type:enhance-existing feature wants to enhance existing monitor labels Apr 25, 2024
@Speedg33k
Copy link
Author

Speedg33k commented Apr 25, 2024 via email •
edited by CommanderStorm

@CommanderStorm
Copy link
Collaborator

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
Copy link
Author

Speedg33k commented Apr 25, 2024 via email

@CommanderStorm
Copy link
Collaborator

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
Copy link
Author

Speedg33k commented Apr 25, 2024 via email

@CommanderStorm
Copy link
Collaborator

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
Copy link
Author

Speedg33k commented Apr 25, 2024 via email

@CommanderStorm
Copy link
Collaborator

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
Copy link
Author

Speedg33k commented Apr 26, 2024 via email

@CommanderStorm
Copy link
Collaborator

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area:monitor Everything related to monitors feature-request Request for new features to be added question Further information is requested type:enhance-existing feature wants to enhance existing monitor
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@CommanderStorm @Speedg33k