Two stateless checkers look at public DNS: the Cloudflare Checker and the DNSSEC Checker. Neither stores a result unless you ask for the report by email.
Cloudflare Checker
The Cloudflare Checker tells you whether a website is on Cloudflare and whether its traffic goes through Cloudflare's proxy. It makes standard DNS lookups and one HTTPS request to the hostname.
| Signal | What it reads |
|---|---|
| IP addresses | The hostname's A and AAAA records, compared with Cloudflare's published IPv4 and IPv6 ranges. |
| CF-Ray and Server headers | The HTTPS response. Proxied responses carry CF-Ray and usually Server: cloudflare. A cf-mitigated: challenge header means Cloudflare served a challenge page. |
| Nameservers | The zone's NS records. Cloudflare nameservers end in ns.cloudflare.com; Foundation DNS uses foundationdns.com, .net and .org. Custom nameservers cannot be recognised. |
| Partial (CNAME) setup | A CNAME to a name ending in cdn.cloudflare.net: Cloudflare proxies the hostname while DNS stays with another provider. |
Verdicts
| Verdict | Meaning |
|---|---|
| Proxied through Cloudflare | Traffic goes through Cloudflare's network, where WAF rules, DDoS protection and caching can apply. The account behind it is not visible: it may be the owner's or a hosting provider's. |
| Cloudflare DNS only | The zone uses Cloudflare nameservers, but the hostname resolves straight to the origin, so the proxy features do not apply and the origin's IP address is public. |
| Not on Cloudflare | None of the signals point to Cloudflare. |
The checker cannot see which WAF rules are switched on. To review that on your own account, run the Cloudflare Checkup.
DNSSEC Checker
The DNSSEC Checker checks whether a domain's DNS answers are signed and validate. It sends its queries over DNS-over-HTTPS to a public validating resolver: Cloudflare 1.1.1.1, with Google Public DNS as a fallback.
| What it shows | Meaning |
|---|---|
| AD flag | The resolver verified every record in the answer with DNSSEC. |
| DS record | Published in the parent zone through your registrar. Its key tag and algorithm must match a DNSKEY in your zone. IANA recommends SHA-256 (digest type 2) and says SHA-1 must not be used. |
| DNSKEY records | Your zone's public keys. Flags 257 marks the key-signing key that the DS record points to; 256 is a zone-signing key. |
| Algorithm | IANA lists 8 (RSASHA256), 13 (ECDSAP256SHA256) and 15 (ED25519) as recommended, and says 5 and 7 (RSA with SHA-1) must not be used to sign. |
| Validation failure | SERVFAIL with validation on, but an answer with validation off: the chain is broken. |
Fix a broken or missing chain
- Not signed. Turn on DNSSEC signing at your DNS provider, which gives you a DS record, then add the DS record at your registrar.
- Validation failure. The DS record usually no longer matches the zone's keys after a key change or a move to a new DNS provider. Users of validating resolvers cannot resolve the domain until you replace the DS record at the registrar with the current one.
- Weak algorithm. Move to algorithm 13 or 15, which also produce smaller signatures than RSA.
Report by email
Both checkers offer the report by email for a result that assessed something. When you ask, Vigilbase runs the check again on its servers and stores that result as a saved run at https://vigilbase.com/tools/run/<id>. A result with nothing to assess, such as an unreachable site or DNSSEC that could not be verified, is not stored or emailed.