uptime-kuma
uptime-kuma copied to clipboard
louislam
Hostname always in IPv4
⚠️ 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
I tested TCP Port by putting the hostname and the check always uses IPv4 resolution.
✔️ Solution
Can we have the option to choose the dns resolution protocol? IPv4 or IPv6
❓ Alternatives
No response
📝 Additional Context
No response
This is possible, but I think we'll have to fork our own tcp-ping to expose more options in socket.connect().
I would also love to see such kind of a feature for HTTP(s) (keyword), ping and TCP ping to choose between IPv4 and IPv6: As the services to monitor usually are served on IPv4 and IPv6 we want to check the availability on both protocols. What I currently do is: I create a separate subdomain for the service to monitor. The subdomain only serves an AAAA record such that kuma is forced to check IPv6 only. However, I would like to avoid that as this is required for every service to be configured.
Same here. No way to check that ipv6 is served properly as kuma ist always using the ipv4 address for connection. How do I know this ? The host kuma runs on is ipv6 only, therefore I get connection errors ! (connect ENETUNREACH) Wanted to open a bug report, but stumbled upon this post when doing my research
I also was wondering why my HTTPS monitor of an IPv6-only host was failing, despite ping/DNS resolution working fine. Hope there's a solution one day!
I also was wondering why my HTTPS monitor of an IPv6-only host was failing, despite ping/DNS resolution working fine. Hope there's a solution one day!
It may be a bug of older version. 1.19.x allowed to disable dns cache, which should solve your issue.
Ah ok, good to know! I will try that out. 🙏 Thank you!
update: that worked! All is well as of now.
I've recently moved to kuma and I'm very very impressed.. Being able to test both IPv4 and IPv6 as different paths would be wonderful. I don't have a lot of faith in my IPv6 atm and It would help me build confidence.
@shleeable
as noted by @lucasnz in #3885 (we will review this PR in 2.1) the http monitors are blocked by these issues upstream:
- https://github.com/axios/axios/issues/5785
- https://github.com/axios/axios/issues/590
Would switching axios for something else be a more feasible approach? I'm not sure why axios was choosen initially (i.e. specific features not present in other modules?), but it doesn't look like axios will resolve this anytime soon. With AWS now charging for IPv4 addresses (and probably more cloud providers following in their path), SRv6 (i.e. IPv6-only infrastructure in service provider networks), IPv6-only ISPs (i.e. no IPv4 available), IPv6 adoption is really starting to get good traction (finally!). However, this means that IPv6 monitoring will be more relevant than it ever has, and the requirement for this will continue to increase in the near future.
I was not here when axios was chosen.
I am not aware of any alternatives to axios offering the features (robust error handling, proxy support, ...) we need.
Given the test coverage we have, I would be very, very hesitant to accept such a PR. Testcases of some notification-providers, all affected monitors and the proxy feature would be necessary. Currently the level of risk does not outweigh this singular feature. Especially with the proxy and single notification-providers, PRs are appreciated.