Technical reference
Domain Visualizer technical details
How Domain Visualizer works: input checks, the exact DNS-over-HTTPS lookups by mode, follow-ups, request budget, findings and their limits, scoring and caching.
The short answer
Domain Visualizer validates the domain you enter, checks whether you may run the chosen mode, and returns a saved result if one is still fresh. Otherwise it sends a fixed list of DNS-over-HTTPS lookups to a public resolver, follows up on the MX, name server and www hosts it finds, runs about forty rule checks over the answers, scores them with the active scoring model, and saves the result. Everything it knows comes from what public resolvers return; it does not query authoritative servers directly, fetch web pages or read registration data.
Scan progress steps
| Step shown | What happens |
|---|---|
| Starting the scan of your domain | The input is trimmed, lowercased and stripped of a trailing dot. Single-label names, internal or reserved suffixes such as .local, .internal and .example, and private reverse-DNS zones are refused. |
| Checking DNS setup | The mode's lookups are sent to the primary resolver |
| Checking mail and name server hosts | Follow-up lookups for each MX host, each name server and the www CNAME target |
| Reviewing findings | Rule checks run over the collected answers |
| Building your report | Findings are scored and the backend returns records, findings and graph together; Visualizer displays records and the graph, while Security Posture displays grades and findings |
The steps are a progress guide shown while the request runs; they are not timed against the server's work.
Acquisition
- Resolvers: lookups use JSON over HTTPS with DNSSEC data requested (DO); a validating resolver may return AD when it authenticates the answer. Each lookup has a five-second timeout. Cloudflare and Google are queried through their JSON interfaces. Quad9 is queried with standard RFC 8484 wire-format DoH, because Quad9 retired its JSON service on May 5, 2025.
- Standard lookups: NS, SOA, A, AAAA, MX, TXT, CAA, DS and DNSKEY at the apex; A, AAAA and CNAME at www; TXT at _dmarc, _mta-sts, _smtp._tls, default._bimi, selector1._domainkey and selector2._domainkey; TLSA at _443._tcp.
- Follow-ups: A, AAAA and _25._tcp TLSA for each MX host; A, AAAA and SOA for each name server host; A, AAAA and CNAME for the www CNAME target.
- Advanced lookups: autodiscover A and CNAME, five SRV names (including Microsoft-specific _sip._tls, but omitting standard _sips._tcp discovery), a random-label wildcard probe, and subdomain discovery from certificate-transparency logs plus probes of common names. Discovered names are then looked up within the remaining budget.
- Request budget: every scan has a cap on outbound requests, set in Site Settings. Lookups that do not fit are marked as not checked rather than treated as missing, and the findings say so.
- Second resolver: when a second resolver is selected and the Standard lookups fit in the remaining budget, they are repeated there and differences are reported as resolver variance.
Analysis and findings
Each rule produces a finding with an identifier, a pass or fail result, a severity, a category and the records it is based on. Some examples of what the rules can and cannot conclude:
| Finding | Based on | Limitation |
|---|---|---|
| DNSSEC valid, absent, not confirmed, DS without DNSKEY, DNSKEY without DS | Whether DS and DNSKEY records came back, and the resolver's AD flag | Does not check key tags, algorithms or signature dates itself |
| Lame name server | A name server host with no A or AAAA record | Does not query the server, so a server that has an address but does not answer for the zone is not detected |
| No DKIM at common selectors | TXT at selector1 and selector2 | Informational only; other selectors are not checked |
| Wildcard DNS | An answer for a random label (Advanced mode) | Shows that a wildcard exists, not that it is exploitable |
| No MTA-STS | The _mta-sts TXT record | The HTTPS policy file is not fetched |
Scoring
Findings are scored with the active scoring model. Each category starts at 100 and loses severity deductions and any extra penalties, up to the category's cap; the overall score is the weighted sum of the category scores. The current weights, deductions, caps, penalties and grade cutoffs are published live in the Domain Visualizer guide. Findings that could not be checked carry no deduction.
Caching
Results are saved per domain, mode and scoring model for 24 hours by default (configurable from one minute to seven days). A saved result is discarded early when the analysis rules change version. A scan whose certificate-transparency lookup failed is not saved, so the next attempt can try again. Results served from the cache show a Cached badge with their age.
Analyst notes
The backend scoring described here feeds other consumers; Visualizer itself displays records and a graph. Use Security Posture for grades and remediation findings. The Market Index stores the same grade from nine of the cards (all but Brand Protection, Attack Surface, Network Security, Vulnerability Management and Credential Exposure), so it can differ from the Security Posture page, which grades those too. Treat grades as triage and verify fixes against the raw records. For checks Visualizer does not make, such as direct queries to each authoritative server or full DNSSEC chain analysis, use dig, delv or DNSViz.
Sources and further reading
- RFC 8484: DNS Queries over HTTPS (DoH)
- RFC 4035: Protocol Modifications for the DNS Security Extensions: the DO and AD bits Visualizer relies on
- RFC 6761: Special-Use Domain Names: why names such as .example and .localhost are refused
- IANA: Special-use domain names registry
- Cloudflare: DNS over HTTPS JSON format