No one needs to monitor a domain that is on multiple servers? am I alone?

Personally, for me, if the domain is on multiple servers and one server goes down, I would not consider the domain its self to be down as the other servers can still respond to the clients reqests. This is where you could monitor the domain as a whole as well as your seperate servers. I.e have one monitor for example.com and then another for 1.cnd.example.com, 2.cnd.example.com ... n.cnd.example.com.

yes ... but I have lots of SSL certificates on each server, I would like to know if my admin forgot to renew a SSL on one of the edges. Your solution 1.cnd 2.cnd won't work for that scenario.

It would be nice if it was possible specify the domain for SSL / SNI separately from the hostname or IP address to connect to.

specify the domain for SSL / SNI separately from the hostname or IP address to connect to

You can do that with the tools currently at your disposal:

• you enter the ip into the url field
• you enter the Host header as described in Ability to monitor individual SSL sites on single server via SNI #2991

In my case I am TCP port monitoring my ingress DNS record which has two IP addresses and when one of those goes down, Kuma will repeatedly flip between up/down state. I'd much prefer the monitor to have an option to monitor multiple IPs separately from that DNS record and report down if all or any are down (with this being a configurable option).

About your comments

monitor multiple IPs separately from that DNS record

IP and HOST header can be monitored separately as stated in #1689 (comment)

report down if all [...] are down

We track this in

• [groups] Conditional monitoring #2487
• [groups] Dependent monitoring of hierarchical monitors #1089
• [groups] Boolean OR operand to get notification for total failure of redundant systems #3387

If somebody wants to improve the group monitor them via a PR our contribution guide is here

report down if [...] any are down

This is the current behaviour of groups.

I think what this issue is really lacking is "How should this work" without exponentially increasing the complexity.
There are already probably too many settings, I don't want this to turn into a parameter dump by adding resolution and SNI settings when they essentially already exist via the IP+HOST settings.
Do people have any ideas on this?

An implementation that adds no extra settings could be something like this https://serverfault.com/questions/327708/how-browsers-handle-multiple-ips

Essentially, resolve DNS name, if multiple IPs present, check first one, if success - check is ok. If it fails, try next IP. If a failed over IP works, could either mark it as healthy or degraded - well, that could be a setting ;).

This is what browsers do under the hood, albeit slowly and sometimes the page takes forever to load but it eventually fails over.

We use axios/Node.js to do the heavy lifting in this department.
According to axios/axios#4534 (comment) we already do Happy Eyeballs.
Said issue is a bit contradictory/outdated with nodejs/node#48145 and nodejs/node#708 (comment)

There also has been a fair bit of traffic on happy eyeballs in node. See https://github.com/nodejs/node/issues?q=is%3Aissue+happy+eyeballs+is%3Aclosed

=> This might be resolved when we upgrade the docker image to node v18 -> v22

Interesting; however, Happy Eyeballs isn't quite the same what the old fashioned failover behavior is like.
Though, if it works, it will essentially solve my issue if it tries to establish multiple connections to multiple IPs within the same stack (IPv4) - it looks like main purpose of the above is to handle dual stack environments.

Are there any node v22 dev builds available?

As far as I read section-5.4 of RFC6555, the logic you are talking about SHOULD work as far as I read this part. (not a specs-expert)

Are there any node v22 dev builds available?

See #4500 what bugs remain before we can publish the first beta of v2.0