IPv4 / IPv6 support#177

It would be nice if we got a http(s) monitor that verifies both or selectable ipv4 and IPv6 connections based on the url.

Being able to do anything except ping with ipv6 would be nice.

DNS connection/UDP connection/ etc.

I also recommend to have the ipv6 check support. It’s quite required as loosing ipv6 connectivity is a bit hard to detect.

I had a failure recently where a reconfigured site was not properly enabled for IPv6 (giving a 404) so half the internet was getting an error and half wasn’t - definitely would love this feature in UptimeRobot - thank you!

“Best way to work around this is to set up separate DNS entries for IPv4 and IPv6, and set up monitoring for both.” what, as in “dns4.example.com” and “dns6.example.com”? Ok but that won’t actually check what our users are doing and that’s what I want checked. We had a situation where we messed up one of the DNS entries but not the other and some users saw problems but we didn’t see any check failures. That’s not good enought.

The best way around this I’ve found is to use someone else (we also use self hosted Prometheus).

I have done the dns[46].example before and I think it’s a good idea. You’re right that this isn’t a perfect representation of what customers see, but I didn’t think you can expect to replicate the various client Happy Eyeballs implementations anyway.

This still leaves UTR with a good use case to consider, and that is to monitor, test, and report on all entries in a DNS round robin, even distinct from IPv6 vs legacy. So if you have
Service = {ip_1, ip_2, …, ip_n}
It would be good to have UTR detect problems with individual hosts. Note this would work whether these are legacy A records or IPv6 AAAA records.

I do this myself, where I have UTR do what it does testing service.example, then I also have monitors for by-ip testing, where you can explicitly specify the IPv6 address. This works but the automation integration when I deploy a new farm is significantly more involved than if UTR just did this.

In the past we had occurrences where connections via IPv6 were presented a wrong SAN TLS Cert.

UptimeRobot cannot notice this for over a year

UptimeRobot - your app has one job: to tell us when our sites are down. You need to check IPv4 and IPv6 to effectively do this. So just do it.

Yeah, this is going to cause me to leave in the future. I need to be able to check a /health endpoing using both ipv4 and ipv6, and fail if one of them fails. I don’t care if I need to set up 2 monitors, but I am not going to change/add a separate DNS entry for this. That is backwards.

Hey everyone, just wanted to inform you all that we are building this currently.