Check the CAA records returned for a hostname, alongside DS and DNSKEY observations from two public resolvers. Enter a name such as example.com, run the lookup and inspect the records and provider status. An empty answer applies to the requested name; it does not by itself establish the effective CAA policy or the DNSSEC state of its containing zone.
Read the CAA result
A CAA record has flags, a tag and a value. For example, the hypothetical record 0 issue "ca.example" identifies an issuer for non-wildcard certificates. The issuewild tag concerns wildcard certificates; iodef supplies a reporting destination rather than naming an issuer. The example is explanatory, not a record this site recommends publishing.
The result table shows the records observed at the queried name. Matching answers from Cloudflare and Google are combined into one row with both providers named. Different answers remain visible as a disagreement, rather than being turned into one authoritative policy.
Under RFC 8659, determining the relevant CAA record set can require following DNS aliases and checking parent names. This tool queries the name entered; it does not perform the complete issuer-authorisation algorithm. No CAA answer at www.example.com therefore does not establish that no parent restriction applies.
Before changing a real CAA policy, identify the authorities your certificate provider uses and check its renewal instructions. Reading the current record does not verify that a replacement policy will allow the provider’s next renewal.
Empty, incomplete and failed lookups
| Result | What it establishes | Next check |
|---|---|---|
| Records observed | At least one resolver returned matching records | Read the values and compare provider status |
| No matching answer | Usable DNS responses returned no record of that type at this name | Check the intended name, aliases or zone boundary |
| Unknown or incomplete | A request failed or returned an unusable DNS status | Retry and inspect the named provider’s error |
| Resolver disagreement | The compared responses differed | Compare with your DNS provider and allow for cache TTL |
A timeout or SERVFAIL is not proof that a record is absent. A result with one working resolver preserves its positive observations and marks the other provider’s failure. If that single successful response is empty, the overall absence question remains unknown.
What the DNSSEC records establish
DS and DNSKEY records are inputs to DNSSEC validation. Their presence does not verify matching keys, signatures or a chain to a trust anchor. An empty query at a host below the zone apex does not prove that the containing zone is unsigned.
Use a validating DNSSEC diagnostic when you need a chain verdict. This page keeps that verdict unknown and reports only the records and resolver responses. RFC 4033 explains the authentication chain. For ordinary address or mail records, use the DNS lookup; for the same records compared across these two resolvers, use the DNS propagation checker.
Calculate a certificate date window
Paste the Not Before and Not After lines from a certificate you already inspected. The tool subtracts the dates to show its total window and calculates remaining days against the current time. It does not fetch those dates or prove that the certificate is installed on your server.
A future date alone cannot establish that a certificate is trusted or matches a hostname. To inspect response headers you already have, use the HTTP header check. For a site that does not load, the network guide separates DNS resolution from later connection checks.