AIDE Is Now a Complete Domain Intelligence Platform: Five Pillars, One Risk Score

Why five pillars?

Most domain monitoring tools answer two questions: is the certificate valid, and is the server responding? But the majority of real-world compromises start with something neither check would catch — a dangling DNS record that lets an attacker claim a subdomain, a DMARC policy left at p=none that lets phishing emails impersonate the domain, or a MySQL database port left open to the internet.

Five pillars means monitoring the full infrastructure surface: the DNS layer that routes everything, the TLS certificates that secure connections, the email authentication stack, the server’s exposed web surface, and endpoint availability. Together they cover the attack vectors that matter to real organisations, not just the ones that are easy to check.

DNS Health — 17 checks, 30% weight

DNS is the lowest layer of domain infrastructure and the one attackers target first. AIDE runs 17 checks covering the full DNS attack surface. Key ones include:

• Subdomain takeover detection: dangling CNAMEs pointing to unclaimed GitHub Pages, Heroku, S3, and Vercel slots — an attacker claims the endpoint and serves phishing content under your brand domain.
• DNSSEC chain validation: 8 distinct states are tracked, including DS-without-DNSKEY which is treated as critical because it breaks resolution entirely for validating resolvers.
• Zone transfer exposure: AXFR attempted against every nameserver. A successful zone transfer leaks the complete DNS zone — every hostname, IP, and record type — to anyone who asks.
• DNSBL reputation: lookups across 20 blocklists with 4-scan confirmation to eliminate transient false positives before an alert fires.
• Open recursive nameserver detection: an open resolver on a domain’s nameserver enables DNS amplification DDoS attacks that can direct traffic at any target.
• DANE/TLSA: certificate pinning in DNS, verified against the live certificate chain.
• DNS propagation consistency: responses compared across 10 global resolvers. Split-horizon configurations and stale cache issues surface here.

DNS changes are confirmed across 4 consecutive resolver polls before alerting — no false positives from transient cache misses during propagation windows.

SSL/TLS Security — 17 checks, 30% weight

17 checks cover every part of the certificate lifecycle and TLS configuration. Highlights:

• Certificate expiry with Let’s Encrypt-specific thresholds: alert at 10 days (high) and 3 days (critical). Let’s Encrypt auto-renews at 60 days, so expiry this close means the renewal mechanism is broken — not that someone forgot to act.
• Live OCSP revocation query: the same real-time check a browser performs. Detects revoked certificates within minutes of revocation, not at the next scheduled scan.
• CRL fallback: Certificate Revocation List lookup with Redis caching per CRL distribution point URL, ensuring revocation status is checked even when OCSP is unavailable.
• CAA↔issuer reconciliation: if a certificate was issued by a CA not listed in the domain’s DNS CAA records, that is a supply chain red flag — it indicates either a misconfigured CAA policy or an unauthorised issuance.
• CT log monitoring: crt.sh queried every 30 minutes. Unknown certificates — including misissued ones — are detected within 30 minutes of issuance.
• SMTP STARTTLS negotiation: a full EHLO→STARTTLS→TLS upgrade sequence is tested, confirming that mail submission port TLS works end-to-end, not just at the HTTPS layer.

Expiry severity escalates in tiers (warning → high → critical) and only re-fires when the tier increases, preventing alert fatigue in the days immediately before expiry.

Email Security — 12 checks, 20% weight

Email authentication is the infrastructure layer with the highest real-world compromise rate. 12 checks run continuously across the full stack:

• DMARC policy enforcement: p=none scores 8/100 (visibility only, zero protection),p=quarantine scores 22/100, p=reject scores 30/100. A domain on p=noneis an open spoofing target.
• SPF include chain depth: the full include graph is traced. A warning fires at 8 DNS lookups; critical at 10. RFC 7208 specifies that exceeding 10 lookups causes a permerror that breaks SPF authentication for every receiving mail server.
• DKIM key strength: 1024-bit RSA keys are flagged critical. They are mathematically breakable with modern CPU clusters in a matter of weeks, allowing an attacker to forge valid DKIM signatures.
• SMTP open relay detection: a live SMTP session test sends RCPT TO for an external address, confirming whether the server accepts unauthenticated third-party delivery.
• MX DNSBL reputation: 16 parallel blocklist lookups per MX IP.
• MTA-STS enforce mode: confirms the policy is reachable, its mode, and whether the certificate chain at the MTA-STS endpoint is valid.

Hosting Security — 27 checks, 10% weight New in this release

Hosting security is the newest pillar and the one that covers the widest surface area. 27 checks span six groups:

Uptime & Availability — 7 checks, 10% weight

Uptime monitoring in AIDE is built to avoid false positives while still detecting real outages within seconds. Seven check types are supported:

• HTTP/HTTPS availability with 3-probe confirmation: the first probe detects a non-up state, then re-probes after 5 seconds and again after 10 seconds. All three must agree before an alert fires — eliminating false positives from transient network blips.
• Keyword / content verification: reads up to 512 KB of response body. Catches maintenance pages and CDN fallbacks that return HTTP 200 but serve no real content — a failure mode that HTTP status checks miss entirely.
• JSON API validation: field path and expected value assertion against parsed JSON. Used for health-check endpoints that return a payload.
• TCP port monitoring: with optional banner verification for non-HTTP services.
• ICMP ping: raw network reachability check, separate from HTTP layer availability.
• Latency threshold monitoring: a “slow” state is tracked separately from “down”. Degraded performance is surfaced before it becomes an outage.
• TLS error detection at probe time: catches certificate failures, expired certificates, and hostname mismatches at every probe, before the SSL worker’s next scheduled scan.

The Domain Risk Score — how it all adds up

Each pillar produces a score from 0 to 100. The Domain Risk Score is a weighted average of all active pillar scores. If a pillar is not monitored, it is excluded and the remaining weights are renormalized proportionally.

The critical cap rule: if any single pillar scores ≤ 25, the Domain Risk Score is capped at 50, regardless of what other pillars score. The design intention is explicit: a single catastrophic finding in one pillar — an open SMTP relay, an exposed Redis port, a zone transfer vulnerability — overrides an otherwise healthy domain. You cannot average away a critical security failure.

Score change alerts: fire when the Domain Risk Score changes by ≥ 5 points between consecutive evaluations. Severity is medium for a delta of 5–9 points, high for 10–24 points, and critical for ≥ 25 points. De-duplication prevents repeated alerts for the same steady state — an alert only re-fires when the score moves again or when a new check finding is added.

Who the platform is for