Domain monitoring

What it is#

Domain monitoring is the practice of continuously tracking new domain registrations, Domain Name System (DNS) configuration changes, Transport Layer Security (TLS) certificate issuance, and web content on domains that may impersonate or attack an organization. It is the primary detection mechanism for domain-based phishing, typosquatting, and brand impersonation, and a core component of any domain protection strategy.

Unlike defensive registration, which prevents abuse by owning domains preemptively, monitoring detects abuse after a domain is registered but (ideally) before it reaches victims. For most organizations, monitoring provides far broader coverage than registration alone because the space of possible lookalike domains is effectively infinite.

Detection approaches#

Domain monitoring uses two complementary approaches to surface threats. The most effective programs combine both.

Proactive permutation detection starts from a protected domain and systematically generates every plausible variant an attacker might register, including character omissions, transpositions, adjacent-key substitutions, homoglyph replacements, TLD swaps, hyphenation, and combosquatting patterns. The resulting permutation set is then checked against live DNS to determine which variants are actually registered. This is the primary method for detecting typosquatted domains because it does not depend on a name appearing in any external feed; it finds predictable lookalikes directly by querying the DNS for each candidate.

Feed-based matching takes the opposite direction. Instead of starting from a seed and checking outward, it ingests streams of newly observed domain names (from registration feeds, certificate logs, and DNS data) and scores each incoming name against the protected brand using string similarity and keyword matching. This approach catches registrations that fall outside the permutation set, such as creative keyword combinations or impersonation patterns that a fixed permutation engine would not generate.

Neither approach alone provides complete coverage. Permutation detection is thorough for predictable variants but cannot anticipate every creative abuse. Feed-based matching covers a broader namespace but depends on the coverage and latency of its upstream data sources. Layering both provides the strongest detection posture.

Data sources#

Several data feeds support the detection pipeline, each with distinct strengths and coverage gaps.

• Newly registered domain (NRD) feeds are daily or near-real-time lists of domains registered across major TLDs. These are the most direct signal for feed-based detection of lookalike registrations. Feeds vary in coverage, latency, and cost; some cover only legacy gTLDs while others include new gTLDs and select ccTLDs.
• Zone files. TLD zone file access (available through ICANN's CZDS for gTLDs) provides authoritative records of which domains exist under a given TLD. Zone file diffs can reveal new registrations, but access is not universal; many ccTLDs do not publish zone files.
• Certificate Transparency (CT) logs are public, append-only records of every TLS certificate issued by participating certificate authorities. A certificate issued for y0urbank-login.com is a strong signal even before the domain resolves to active content. CT monitoring is especially valuable because attackers who intend to serve HTTPS phishing pages typically obtain a certificate early in the attack chain, often before the site is live.
• Passive DNS is historical DNS resolution data collected from recursive resolvers, useful for tracking when a domain changes its hosting, mail configuration, or name servers. It also helps identify shared infrastructure; multiple phishing domains pointing to the same IP often indicate a coordinated campaign.

No single source covers the full namespace. NRD feeds may miss certain TLDs. CT logs only capture domains that obtain certificates. Passive DNS depends on resolver visibility. Combining multiple sources reduces blind spots.

The monitoring pipeline#

A typical monitoring pipeline follows four stages:

1. Ingest. Collect data from NRD feeds, CT logs, zone files, and passive DNS on a continuous basis. Latency matters; a phishing domain can be weaponized within hours of registration, so near-real-time ingestion is preferable to daily batch processing.
2. Match. Compare incoming domains against typosquatting permutations of protected brand assets using string similarity, edit distance, homoglyph tables, and keyword matching. The permutation set should be precomputed and updated whenever brand assets change.
3. Enrich and score. Resolve DNS records to determine whether the domain is active and whether MX records suggest email intent. Pull WHOIS data for creation date and registrar context. Check TLS certificate issuance as a signal of intent to serve HTTPS content. Capture HTTP banners and screenshots to reveal what the domain actually serves. Assign a composite risk score based on these factors, weighting similarity to the brand, TLD reputation, and hosting infrastructure overlap with known-bad campaigns.
4. Triage. Surface high-scoring domains to analysts with enough context (DNS records, WHOIS data, screenshots, content analysis) to support a disposition decision quickly. Low-scoring domains enter a watch list for re-evaluation if their posture changes.

The match and score stages are where most tuning happens. Overly broad matching produces noise; overly narrow matching misses creative abuse.

False positive management#

False positives are unavoidable, especially for brands with short or common names. A company named "Arc" will match thousands of legitimate domains. Strategies for managing noise include:

• Multiple signals improve precision; similarity alone is rarely sufficient. Combining it with hosting indicators, content analysis, or certificate signals dramatically reduces noise.
• Allowlists for known-good registrants and domains reduce recurring false positives.
• TLD-specific thresholds reflect realistic risk; a match in .com typically warrants more attention than one in a niche ccTLD.
• Temporal signals matter; a domain registered yesterday is more suspicious than one registered five years ago.
• False positive rate is worth tracking as a metric. If analysts routinely dismiss the majority of alerts, the detection logic needs tightening. Acceptable thresholds vary by brand commonality and program maturity.

Integration with incident response#

Monitoring detections should feed directly into existing security and legal workflows rather than existing as isolated alerts.

High-confidence phishing domains get routed to security operations for internal blocking (DNS sinkholes, firewall rules, proxy blocklists) and to legal or a managed provider for takedown. Lower-confidence alerts enter an analyst triage queue. API integrations with security information and event management (SIEM) platforms, ticketing systems, and firewall management tools reduce the manual overhead of copying data between systems.

The most effective programs also feed monitoring intelligence back into brand protection workflows, tracking which registrars host the most abuse, which TLDs are repeatedly targeted, and whether takedown actions are effective. This feedback loop improves both detection accuracy and enforcement strategy over time.

Tooling#

Have I Been Squatted's twistrs library can cover permutation generation and basic DNS resolution checks for teams that assemble their own stack, but permutation generation is only one stage of the pipeline. A production monitoring system also needs NRD feed ingestion, CT log watchers, enrichment (WHOIS, HTTP content, screenshots), scoring logic, alert routing, and an interface for analyst triage. Building and maintaining that infrastructure in-house requires significant, ongoing engineering effort.

Managed solutions handle pipeline maintenance and enrichment. Have I Been Squatted generates permutations from each monitored seed, checks registrations across TLDs, enriches matches with DNS, RDAP, HTTP, and certificate data, scores candidates, and surfaces actionable alerts. It also allows teams to automate the abuse response with fully managed takedowns, closing the loop from detection to resolution without custom pipeline engineering.