Scoping certificate-validation bypass in a PowerShell DNS/TLS triage script that must run on 5.1 and 7

Goal

I am designing a diagnostic script that separates DNS resolution failures from TLS certificate-validation failures when an internal HTTPS endpoint is unreachable. It uses Resolve-DnsName with -Server and -DnsOnly to compare resolvers, then Test-NetConnection -Port 443 -InformationLevel Detailed, and finally Invoke-RestMethod to surface the TLS error.

Constraints and uncertainty

The script must run on both Windows PowerShell 5.1 and PowerShell 7. On 7, -SkipCertificateCheck gives a per-request bypass for confirming that an error is certificate validation rather than connectivity. On 5.1 the only equivalent I know is overriding [System.Net.ServicePointManager]::ServerCertificateValidationCallback, which is process-global and persists for the session. I also want the script to inspect the served chain via SslStream.AuthenticateAsClient so I can check expiry, chain Build() status, and hostname match instead of blindly bypassing.

The unresolved decision is whether the tool should relax validation at all, or only report the chain problem and leave trust fixes (installing the missing root/intermediate CA) to the operator, since a bypass masks real man-in-the-middle risk.

Questions

• Is there a supported way in 5.1 to scope the certificate callback override to a single request and reliably restore it, or is process-global the only option?
• Should edition detection gate -SkipCertificateCheck so 5.1 falls back to chain inspection only?
• Are there Resolve-DnsName output differences on Linux/macOS under PowerShell 7 that a cross-platform parser must handle?