I raised this same issue under this discussion almost two years - unfortunately it's been completely ignored: https://updown.uservoice.com/forums/177972-general/suggestions/38068798-add-the-ability-to-disable-following-redirects.

I've worked around this in the past but it's starting to cause problems again, so I'm raising it again and this time I'll expand on the specifics of the problem I'm having.

I run web services from behind Cloudflare. When you set up Cloudflare for proxying, you provide your backend DNS entries to them and enable proxying. They'll then create public facing DNS entries for you that point to Cloudflare, and proxy connections through to your backend. For this, Cloudflare automatically add public AAAA records for all your endpoints. This is usually fine and doesn’t require your backend to support IPv6 because Cloudflare will handle consuming the IPv6 connection and proxying it to the IPv4 backend.

However, when the IPv4 backend then responds with a e.g. a 302 redirect, and the target of that redirect doesn't support IPv6, updown.io reports this as a partial connectivity failure.

This is because of the curl command used, i.e. 'curl -gkvLI6 redirect.example.com'. This command will force curl to resolve 'redirect.example.com' on its AAAA record, receive the redirect (e.g. 302), and then force it to attempt to resolve the redirect target on its AAAA record. If no AAAA record exists for the redirect target (due to lack of IPv6 support) or the backend does have a AAAA record by no IPv6 listener, the curl command fails and this is reported as a partial failure in updown.io.

The only way I think that this problem could be solved by updown.io is to offer the option of preventing the curl check from following redirects, i.e. toggle the '-L' flag off. This would let me check the health of my IPv4 and IPv6 facing endpoint without having to worry about the status of the redirect target, and then check the health of the redirect target itself separately.

I'm really needing a "hidden" status for pages, for them to be shareable (to client ..).

Exactly on the same model that Gdrive/Gsuite :

Private > For your eyes Only

Public > Shareable to the world. Can be linked on a public website. Can be found and indexed by google (and you have a lot .. https://www.google.com/search?q=site%3Aupdown.io

Hidden > Only for people who know the URL, to be shared internally. With a long hash key in url that cannot be bruteforced, with meta no index , cannot be indexed by google.

(YES, one could find the url if they hack my mailbox,the same if I share a password by email , same for google drive "shared to anyone with the link", or a wetransfer private file, that's good a security enough for most usecases)

Right now, public pages are too easy to find and can be indexed, so nogo for this usecase.

thanks for the consideration !

Hi,
I have implemented a simple php script on one of my servers to take a query via GET method and returns the requested DNS record.
The site is restricted to updown.io servers and uses a URL in the following format :

https://webserver.com/lookup.php?T=A&D=google.co.uk&R=IP

This uses the following fields :
T - Type of record to return eg. MX/A/TXT
D - Domain to check eg. google.co.uk
R - Record field to return. eg. ip for ip address
The server code simple checks if the record type is a valid one we accept, checks the domain name is in a valid format and then performs a PHP dnsgetrecord(), it then checks if the R field is in the result and returns it if it is. If there are multiple matching records, then it simple returns them all separated by a ',' this allows using the 'contains' field within the check portal to check for the required data.
This allows me to check that a DNS record hasn't been changed by a third party (eg. I host a customers web page, but all there DNS etc is handled by someone else).
Would be happy to supply the scripts if anyone is interested, would be great to add to updown as a service (with rate limiting etc!)
marl_scot

Currently updown.io breaks out the time of normal requests into:

• name lookup;
• connection;
• tls handshake; and
• response time

but shows redirects as a single block of time. It would be useful to see redirects broken out the same way.

Users often type naked domains, like example.com, into browsers. That might lead to this sequence of redirects:

http://example.com/ -> https://example.com
https://example.com/ -> https://www.example.com

(HSTS preload requires the first redirect; you can't go straight from http://example.com/ to https://www.example.com.)

Depending on how you're handling both http and naked domains the time for the redirects can be much greater than the time of a page load. It would be useful to know where that time is actually being spent. For example, maybe your naked domain doesn't have good geographic distribution, or maybe it has slow TLS handshakes.