DNS-over-HTTPS, commonly called DoH, protects DNS queries inside an encrypted HTTPS connection. That privacy layer is useful, but it also creates a combined dependency: the resolver must answer DNS correctly while its HTTPS endpoint, certificate, content type, caching behavior, and network path remain healthy. A scheduled external check can validate the complete request from a real client perspective and alert before users experience slow lookups or silent failures.
Monitor the service users actually depend on
A TCP connection to port 443 is not enough. The monitor should send a standards-compliant DNS message to the resolver’s published HTTPS endpoint, verify the HTTP response, parse the DNS payload, and decide whether the returned answer is correct for a controlled test name. This checks transport and DNS semantics in one transaction.
Use a domain you own for the primary probe. A stable record with a deliberately short but reasonable TTL lets you verify freshness without depending on a third party. Keep a second public name only as a diagnostic cross-check, not as the sole definition of success.
Choose GET, POST, or both
DoH supports queries encoded in a GET URL and DNS messages sent in a POST body. Production clients may use either form, so monitor the method your applications use. If the endpoint promises both, schedule separate lightweight probes for each path. A valid response should use the expected DNS media type, contain a matching transaction structure, and remain within your size and timing limits.
Treat redirects carefully. A permanent, documented redirect may be acceptable, but unexpected redirects can reveal a configuration error or send traffic to a login page, proxy splash screen, or unrelated host. Record the final destination and fail when it leaves the approved host list.
Validate HTTPS before trusting DNS
The check should verify the certificate chain, hostname, validity period, negotiated protocol, and connection time. Do not disable certificate validation to make the monitor pass. An endpoint with an expired or mismatched certificate is unavailable to standards-compliant clients even if it still returns DNS bytes.
Track certificate days remaining as an early-warning signal, but keep that warning separate from immediate availability. A certificate with ten days left is operational now and needs planned action; an expired certificate is an incident.
Check the DNS message, not only HTTP 200
An HTTP 200 response can still contain a DNS error, a stale record, an unexpected address, or a malformed message. Parse the DNS header and question section, then validate:
- the response flag is set and the question matches the request;
- the response code is expected, normally NOERROR for the positive probe;
- the answer contains an approved record type and value;
- the TTL is plausible and not permanently frozen;
- truncation, recursion, and authenticated-data flags match your policy;
- the message can be decoded without trailing or contradictory data.
Also maintain a negative probe for a unique nonexistent name below a domain you control. It should return NXDOMAIN with a reasonable authority section. This detects resolvers that rewrite missing names, captive portals, or filtering systems that return synthetic addresses.
Measure latency in useful phases
A single total duration hides the source of a slowdown. When possible, record DNS bootstrap time for the DoH hostname, TCP connection time, TLS handshake time, time to first byte, and complete response time. Reused HTTP connections behave differently from fresh connections, so test both according to how your clients operate.
Use percentiles over a rolling window rather than alerting on one slow query. A resolver may occasionally miss its cache and perform recursion. Alert when latency remains above the service objective, failure rate rises, or multiple regions show the same regression.
Avoid circular monitoring
The DoH hostname itself must be resolved before a new client can contact the service. If your monitor resolves that hostname through the same failing DoH resolver, the check may never reach the endpoint and may produce confusing evidence. Bootstrap with a pinned, regularly reviewed address or an independent system resolver, then validate the TLS hostname normally.
Do not pin indefinitely without a rotation process. Address changes are legitimate in load-balanced systems. Store the approved address set in configuration, monitor changes, and update it through a controlled workflow.
Compare regions and resolver instances
Run checks from at least two networks or geographic regions when the resolver serves a broad audience. A global success average can hide a routing problem that affects one provider. Tag every result with region, address family, resolver address, and protocol version so the alert explains where the failure occurs.
If the service uses several anycast or load-balanced instances, compare answer correctness and latency across observations. Large differences can indicate an unhealthy site, an incomplete deployment, or cache inconsistency.
Design a safe health endpoint or direct probe
You can have the web cron service call a small monitoring endpoint that performs the DoH transaction, or call a purpose-built probe URL in your infrastructure. Either way, return a concise status and safe measurements. Do not expose resolver administration credentials, internal topology, packet captures, or full query logs.
Protect the endpoint with TLS, scoped authentication, rate limits, and a narrow allowlist where appropriate. The guidance in Secure Web Cron Endpoints
Schedule, retry, and alert deliberately
A five-minute interval is sufficient for many public resolver checks, while a critical internal dependency may justify one-minute checks. Set a timeout that is longer than normal recursive latency but shorter than the user-facing failure budget. Use one or two bounded retries with short jitter to distinguish a transient packet loss from a sustained outage.
Retries should preserve the first failure evidence. Follow the principles in Cron Job Retry Strategies
Alert on state transitions or a persistence threshold. Include the endpoint, method, probe name, region, address family, DNS response code, TLS result, total latency, and last successful time. Send a recovery notification after consecutive successful checks confirm stability.
Keep evidence and test failure modes
Store the check time, query type, expected answer version, HTTP status, DNS response code, certificate expiry, response size, latency phases, resolver address, and final classification. This history reveals gradual TLS handshake growth, cache behavior changes, IPv6-only failures, and deployment inconsistencies.
Test with an expired certificate in staging, a wrong media type, a malformed DNS message, NXDOMAIN rewriting, delayed responses, a stale controlled record, and one unreachable backend. Use the bounded validation style described in Scheduled API Health Checks
Accurate timestamps are essential when comparing TTLs, certificates, and regional observations. If results appear to arrive before they were sent, add the safeguards from Server Clock Drift Monitoring.
Operational checklist
- Probe a controlled positive name and a controlled negative name.
- Validate TLS, HTTP behavior, media type, and the DNS payload.
- Measure connection, handshake, first-byte, and total latency.
- Avoid circular bootstrap dependencies.
- Check IPv4, IPv6, regions, and supported request methods.
- Use bounded retries and transition-based alerts.
- Retain safe evidence and exercise failure scenarios regularly.
A reliable DoH monitor verifies privacy transport and name resolution together. By checking the complete path on a schedule, teams can detect certificate problems, malformed answers, regional routing failures, stale data, and latency regressions before applications lose the DNS service they quietly depend on.