Understand DNS resolution checks

Learn how TechDash detects a hostname that no longer resolves.

Last checked 20 August 2026

TechDash resolves the exact monitored hostname every six hours. The lookup uses the operating system's DNS resolution from this computer and accepts any returned address. Both IPv4 and IPv6 addresses can satisfy the check.

The result appears in Sitewide Checks as either:

  • The site hostname resolves. with Good
  • The site hostname did not return any addresses. or The site hostname did not resolve. with Critical

The incident title is Hostname does not resolve.

Understand the schedule

A DNS lookup becomes due six hours after its last attempt. The lookup scheduler reviews due websites once an hour while monitoring is active, so the normal start is at the first hourly sweep after the six-hour due time.

The actual run can be later if:

  • TechDash is closed.
  • The computer is asleep or offline.
  • A Wi-Fi sign-in page is blocking internet access.
  • The license is unavailable.
  • The website is paused.
  • Another job is ahead in the DNS queue.

The lookup has a hard timeout. A successful resolution stores the hostname, returned addresses, completed state, and checked time. A failure stores the error and checked time and opens a Critical result. Because checked time advances on failure, the automatic scheduler normally waits another six hours before that website is due again.

Distinguish DNS from related checks

Hostname resolution asks whether this computer's resolver can obtain at least one address for the monitored hostname. It does not:

  • Fetch an HTTP page
  • Confirm that port 80 or 443 accepts connections
  • Validate the TLS certificate
  • Test every public resolver
  • Verify that all returned addresses serve the same website
  • Compare the complete A, AAAA, or CNAME record set with a baseline

A page check can fail after DNS succeeds because the origin, CDN, or TLS connection is broken. DNS can also fail before an HTTP request is possible.

Nameservers changed is different. It compares normalized registration-data nameservers from the daily RDAP or WHOIS lookup. Nameservers can change while the hostname continues to resolve, or remain unchanged while an A, AAAA, or CNAME record is removed.

Investigate a Critical incident

  1. Confirm the exact hostname shown on the website page. Include www or another subdomain exactly as monitored.
  2. Reproduce the lookup from the same computer and network. This establishes whether the incident is local.
  3. Query the authoritative nameservers for the hostname's A, AAAA, and CNAME chain.
  4. Check the parent-zone delegation and registrar nameservers if authoritative servers cannot be reached.
  5. Review recent DNS, CDN, hosting, registrar, and domain-transfer changes.
  6. Inspect DNSSEC if the domain uses it. A broken signature or delegation can cause validating resolvers to fail.
  7. Check whether a CNAME target was removed, expired, or no longer belongs to your account.
  8. Compare with at least one independent public resolver before changing production records.

Expected propagation is a reasonable explanation only after an intentional change. It does not repair an incorrect record, missing delegation, expired domain, or DNSSEC failure. During a planned cutover, keep old and new services available for the applicable TTL where possible.

Account for local conditions

TechDash uses dns.lookup, so results can be affected by the operating system resolver, local hosts configuration, VPN, proxy, corporate DNS, filtering software, and the current network. A local failure does not prove that every user sees an outage.

Conversely, one successful local answer does not prove global consistency. Compare the incident with authoritative responses and external resolvers. If only this computer fails, repair its DNS or network path before editing production DNS.

Recheck after a correction

Use Check & Verify in the incident to run the DNS lookup immediately. It re-resolves the hostname and refreshes the open issue. Check now in Site Resources does not run DNS, SSL, or domain lookups.

If recheck still fails, read the current error rather than repeatedly retrying. Confirm the correction is visible to the resolver used by this computer, flush local caches only when appropriate, and allow the configured TTL to expire after a known-good authoritative change.

Related articles