Security

Domain Monitoring for Security Teams: A Practical Baseline

January 18, 20268 min readMonitoring · DNS · WHOIS · Security

Introduction

Domain infrastructure has become a primary attack surface. Threat actors register lookalike domains, hijack legitimate ones, abuse expiring registrations, and silently redirect DNS to intercept traffic. The volume of phishing domains detected per day now runs into the tens of thousands, brand impersonation campaigns spin up in under an hour, and domain hijacking incidents — including against enterprise targets — are no longer rare. For security teams, monitoring the domain layer is no longer optional. It is a foundational defensive control. This article covers what to monitor, why each signal matters, how three real threat scenarios unfold, and how to automate detection with an API.

What Security Teams Actually Monitor

Five signal categories cover the majority of domain-layer threats:

WHOIS Changes

Registrant, registrar, nameserver, or status changes. Any modification to registration data is a high-priority event — it may indicate a takeover in progress or an ownership transfer that bypasses your change management process.

DNS Modifications

Changes to A, AAAA, MX, NS, or TXT records. DNS is the most critical layer: a single record change can redirect web traffic, intercept email, or break SPF/DKIM validation. These changes can propagate globally within minutes.

SSL Certificate Events

Expiry warnings, new certificate issuance for monitored domains, and unexpected issuer changes. Certificate Transparency logs also surface newly issued certs for lookalike domains before they go live.

New Subdomains

Unexpected subdomain creation can indicate account compromise, unauthorized deployments, or a forgotten staging environment being repurposed by an attacker. Passive DNS and subdomain enumeration both contribute to this signal.

Typosquatting & Lookalikes

Domains that visually or phonetically resemble yours: character substitution (rn for m), homoglyph attacks, hyphen insertion, TLD variations. Detection requires proactive scanning of newly registered domains — passive monitoring alone is too slow.

The Threat Scenarios

Three scenarios illustrate how these signals translate to real incidents.

01

Infrastructure Phishing via DNS Change

Signal: DNS A record change

A threat actor compromises a DNS registrar account — often via credential stuffing or a phishing attack targeting the domain owner's email. They update the A record for the target domain or a subdomain (login, mail, portal) to point to a server they control. From that point, all HTTP traffic goes to a cloned login page that harvests credentials. The attack window begins the moment DNS propagates, often within 5 minutes. Without continuous DNS monitoring, the redirect may not be discovered for hours or days.

Detection: Compare the current A record for monitored domains and subdomains against a stored baseline. Any change should trigger an immediate alert regardless of source.
02

Domain Hijacking via WHOIS Takeover

Signal: Registrant / registrar change

Domain hijacking involves transferring a domain to a different registrar or changing registrant contact details without authorization. Attack vectors include social engineering registrar support staff, compromising the registrant's email to authorize transfers, or exploiting registrars with weak identity verification. Once the registrar or registrant changes, the attacker controls DNS, SSL, and the domain's entire identity. ICANN's transfer policies include a 60-day lock after certain changes, but attackers work around this through registrars in jurisdictions with loose enforcement.

Detection: Monitor the registrar, registrant, and statusAnalysis.clientTransferProhibited fields via WHOIS/RDAP. Any change to registrar name or the appearance of a transfer-related status is a critical event.
03

Brand Impersonation via Typosquatting

Signal: New lookalike domain registration

Attackers register domains that look like yours — paypa1.com, arnazon-support.net, g00gle-login.co — and use them for phishing campaigns, fake customer support portals, or SEO manipulation. These domains are registered fresh and often have no initial content, making them hard to detect reactively. By the time a phishing email is reported, the campaign has already run. The effective defense is proactive: scan newly registered domain feeds and newly observed domains for matches against your brand name, product names, and executive names.

Detection: Combine age.isNewlyRegistered and age.isYoung from the WHOIS API with fuzzy name matching. Flag domains registered within the last 30 days that score above a similarity threshold.

Building a Monitoring Baseline

What a lean security team should monitor at minimum, and at what cadence:

SignalFrequencyPriorityData Source
DNS A / AAAA recordsReal-time (15 min)CriticalDNS lookup
DNS NS recordsReal-time (15 min)CriticalDNS lookup
DNS MX recordsHourlyHighDNS lookup
WHOIS registrar / registrantDailyCriticalWHOIS / RDAP
Domain expiry (30 / 14 / 7 days)DailyHighWHOIS / RDAP
SSL certificate expiryDailyHighSSL check
SSL certificate issuer changeDailyMediumSSL check
Subdomain enumerationWeeklyMediumPassive DNS / active enum
Typosquatting / new lookalikesDailyMediumNewly registered domains feed

The minimum viable baseline is DNS (A + NS) and WHOIS (registrar + expiry) for all production domains. Add MX if you run email infrastructure, SSL if certificates are customer-facing, and typosquatting monitoring if brand impersonation is a live concern for your organization.

Automating Alerts with an API

The simplest monitoring pattern: store a baseline snapshot per domain, query the API on a schedule, diff the result, and alert on any change. The example below uses the WhoisJSON API with native Node.js fetch — no extra dependencies.

monitor.jsJavaScript
const API_KEY    = process.env.WHOISJSON_API_KEY;
const API_BASE   = 'https://whoisjson.com/api/v1';
const DOMAINS    = ['example.com', 'yourbrand.net', 'partner-domain.io'];

// Simulated baseline store (use Redis / DB in production)
const baseline = new Map();

async function fetchDomainData(domain) {
    const res = await fetch(`${API_BASE}/whois?domain=${domain}`, {
        headers: { 'Authorization': `TOKEN=${API_KEY}` },
        signal: AbortSignal.timeout(8000)
    });
    if (!res.ok) throw new Error(`API error ${res.status} for ${domain}`);
    return res.json();
}

function extractBaseline(data) {
    return {
        registrar:   data.registrar?.[0] ?? null,
        registrant:  data.contacts?.registrant?.[0]?.organization ?? null,
        nameservers: (data.nameserver ?? []).slice().sort().join(','),
        expires:     data.expires ?? null,
        status:      data.statusAnalysis?.isActive ?? null,
        transferLock: data.statusAnalysis?.clientTransferProhibited ?? null
    };
}

function detectChanges(domain, current, previous) {
    const alerts = [];
    for (const [key, val] of Object.entries(current)) {
        if (previous[key] !== val) {
            alerts.push({ domain, field: key, from: previous[key], to: val });
        }
    }
    return alerts;
}

async function sendAlert(alert) {
    // Replace with Slack webhook, PagerDuty, email, etc.
    console.warn('[ALERT]', JSON.stringify(alert, null, 2));
}

async function runMonitoringCycle() {
    for (const domain of DOMAINS) {
        try {
            const data    = await fetchDomainData(domain);
            const current = extractBaseline(data);

            if (baseline.has(domain)) {
                const changes = detectChanges(domain, current, baseline.get(domain));
                for (const change of changes) await sendAlert(change);
            }

            baseline.set(domain, current);
        } catch (err) {
            console.error(`[ERROR] ${domain}: ${err.message}`);
        }
    }
}

// Run immediately, then every 15 minutes
runMonitoringCycle();
setInterval(runMonitoringCycle, 15 * 60 * 1000);

The key fields to diff are registrar, nameservers, expires, and statusAnalysis.clientTransferProhibited. A loss of the transfer lock combined with a registrar change in the same cycle is a strong hijacking signal and should trigger an immediate high-priority alert regardless of business hours.

From Raw Data to Risk Score

Monitoring produces a stream of events. For teams that want to act on risk rather than manage raw events, the next step is aggregating those signals into a structured score. A domain risk score synthesizes multiple weak signals — recently registered, no transfer lock, newly issued certificate, DNS on shared infrastructure, registrar in high-risk jurisdiction — into a single number that prioritizes analyst attention.

WhoisJSON provides the normalized data layer: structured WHOIS/RDAP fields, pre-computed age, expiration, and statusAnalysis objects, DNS records, and SSL data. For teams that do not want to build the aggregation pipeline themselves, domainrisk.io aggregates these signals into a scored risk assessment — covering domain age, registration patterns, infrastructure reputation, and lookalike proximity — without requiring custom code.

Example signals that contribute to a risk score:
  • age.isNewlyRegistered — domain registered within the last 30 days
  • expiration.isExpiringSoon — domain expiring in under 14 days (drop-catch target)
  • statusAnalysis.clientTransferProhibited = false — no transfer lock
  • nsAnalysis.singleInfrastructure = false — nameservers on mixed or untrusted infrastructure

WhoisJSON Domain Monitoring

Beyond the API, WhoisJSON includes a built-in domain monitoring feature for teams that prefer a managed solution over a self-hosted script. You register the domains you want tracked, set alert thresholds, and receive notifications when a change is detected.

WHOIS Alerts

Registrar, registrant, and status change notifications. Configurable per domain with custom alert channels.

DNS & SSL Tracking

Continuous polling of DNS records and SSL certificate metadata. Alert on any modification or approaching expiry.

Expiry Reminders

Automated reminders at 30, 14, and 7 days before domain expiry. Integrates with webhook endpoints for ticketing systems.

View Domain Monitoring features

Conclusion

Domain monitoring is a lightweight, high-signal defensive control. The attack patterns it detects — hijacking, phishing infrastructure, brand impersonation — are active, growing, and frequently succeed precisely because organizations have no visibility into their domain layer until after the incident. A practical baseline requires monitoring five signal categories, with DNS and WHOIS as the non-negotiable foundation.

The implementation path depends on your team's resources. Developers building custom pipelines get structured, normalized domain data from the WhoisJSON API — WHOIS/RDAP, DNS, SSL, and pre-computed risk fields in a single response. Security teams that want risk aggregation without building the pipeline can use domainrisk.io to go from raw domain names to scored threat assessments.

For Developers

Monitor any domain programmatically. 1,000 free API requests per month — no credit card.

Get API Key

For Security Teams

Domain risk scoring without building the pipeline. Aggregated signals, instant assessments.

Try domainrisk.io
Domain Monitoring & Risk Intelligence

Detect Threats Before They Become Incidents

Two tools, one workflow. Query domain data with the WhoisJSON API or get scored risk assessments from domainrisk.io.

WHOIS + DNS + SSLReal-time change detection1,000 free requests/month

Developers

Structured domain data via REST API. Normalize WHOIS, DNS, SSL into one JSON response.

Get Free API Key

Security Teams

Risk scoring without building the pipeline. Aggregated signals, instant domain assessments.

Try domainrisk.io