DNS Tools

The built-in DNS/email diagnostics console — run A/MX/TXT/SPF/DMARC/TLS/blacklist lookups from the dashboard and read the results.

DNS Tools

DNS Tools is an MXToolbox-style diagnostics console built into the dashboard. One input box runs every common DNS, email, and network check — type a domain, IP, or URL and it auto-detects what to run, or pick a command explicitly. Everything runs server-side and read-only; nothing you type sends mail or changes a record.

Access needs the dns.use privilege. Saved monitors additionally need dns.monitors.

This is the user guide. For the engineering internals — module layout, result shapes, the scheduler wiring, and how to add a command — see DNS Tools (dev).

The SuperTool

The search box is the whole tool. Enter one of:

  • A bare domain (example.com) → runs a full DNS lookup.
  • An IP (1.2.3.4) → checks it against blacklists.
  • A URL (https://site.com) → runs an HTTP(S) header check.
  • A host:port (example.com:443) → runs a TCP port check.
  • A keyword + argument (mx example.com, blacklist 1.2.3.4, spf example.com) → runs that specific command.

Leave the selector on Auto-detect to let it classify your input, or pick a command from the dropdown / quick chips (DNS · MX · Blacklist · SPF · DMARC · WHOIS · TLS · HTTP · Propagation). Results stack newest-first; the last several runs stay on screen so you can compare.

Commands

CommandWhat it answersExample input
dnsA, AAAA, MX, NS, TXT, SOA & more in one shotexample.com
a / aaaaIPv4 / IPv6 address recordsexample.com
cnameCanonical-name alias recordswww.example.com
mxMail exchangers, ordered by preferenceexample.com
nsAuthoritative name serversexample.com
txtAll TXT recordsexample.com
soaStart-of-authority (serial, refresh, expiry)example.com
ptrReverse DNS for an IP8.8.8.8
srvService records_sip._tcp.example.com
caaWhich CAs may issue certificatesexample.com
spfFind & validate the SPF policy (lookup count, all qualifier)example.com
dmarcFind & parse the _dmarc policyexample.com
dkimLook up a DKIM key — selector:domain, or probe common selectorssel:example.com
smtpConnect to the top MX: banner, EHLO caps, STARTTLS (read-only; no relay test)example.com
blacklistCheck an IP (or a domain's IP) against DNS blacklists1.2.3.4
whoisRegistry/registrar record for a domain or IPexample.com
httpsStatus, redirect chain, server & security headershttps://example.com
certCertificate chain, expiry, SANs, issuer, hostname matchexample.com
portTCP connect test to a host:portexample.com:443
pingTCP-connect latency (not ICMP)example.com
propagationThe same record across many public resolversmx:example.com
dnshealthDelegation, NS reachability, SOA-serial agreementexample.com
subdomainsDiscover subdomains from Certificate Transparency logs (passive)example.com
fingerprintIdentify CMS, framework, web server & WAF/CDN from headers + HTMLhttps://example.com

Reading the results

Every command renders the same way, so once you can read one you can read them all:

  • Checks — the findings, each flagged pass, warn, fail, or info. This is where you look first: a red fail on an SPF lookup count, an amber warn on a cert nearing expiry, and so on.
  • Tables — the raw answers (records, MX rows, resolver responses, blacklist zones).
  • Raw / timing — the underlying text and how long the lookup took.

A few honesty notes worth knowing when you read output:

  • "ping" is a TCP probe, not an ICMP ping — labelled as such.
  • SMTP does not run an open-relay test — it only reads the banner, capabilities, and STARTTLS.
  • Single lookups pin to Cloudflare (1.1.1.1) and tell you which resolver answered. Blacklist checks deliberately use the system resolver, because major DNSBLs refuse queries from big public resolvers.

Telemetry monitors

With the dns.monitors privilege you can save any check as a monitor — a watch that runs on a schedule, keeps history, and raises an alert when the answer degrades or drifts. The stat bar shows Monitors · Failing · Open alerts · Passing at a glance.

Monitor types available:

TypeWatches for
DNS recordAn A/AAAA/MX/NS/TXT/CAA answer changing (drift / hijack)
TLS certificateA cert nearing expiry or a broken chain
Blacklist (MTA)A mail server / egress IP getting listed on a DNSBL
PropagationPublic resolvers disagreeing (slow / stuck propagation)
DNS healthNS unreachability or SOA-serial disagreement
Domain expiryThe domain registration approaching expiry
HTTP(S)Non-2xx status or lost security headers
Cloudflare driftThe Cloudflare zone's intended records vs what resolvers return
Browser (rendered)A real-browser render: selector/text present, no console errors, within a load budget
Subdomain (CT)A new subdomain/cert appearing in Certificate Transparency logs

A monitor run yields pass · warn · fail · error, and an alert is raised when the status gets worse, the answer drifts, or the Node recovers. Those alerts surface on the Observability page. Which monitor types, quotas, intervals, and alert channels you get is gated by your plan — the Plan capabilities matrix on the page shows what your tier unlocks.

Attack surface (owner-gated)

The Attack surface panel runs an owner-gated self-scan of a domain you control: Certificate-Transparency subdomain discovery, then a curated port sweep and an exposed-file probe (.git / .env / backups / status pages). Active checks only run against verified-owned domains — you publish the DNS token first, then scan.

Command reference & help

The Command reference section at the bottom lists every command with its syntax, so you can prefix your input precisely (e.g. blacklist 1.2.3.4, spf example.com).