Domain Tech Similarity (datapulse_dns_dptechsim)

Find domains with similar DNS infrastructure using vector similarity search.

Overview

The datapulse_dns_dptechsim tool discovers domains that share similar technical infrastructure by comparing vector embeddings derived from DNS fingerprints. This enables:

• Infrastructure clustering: Find domains hosted on the same or similar infrastructure
• Operator discovery: Identify domains likely operated by the same entity
• IOC expansion: Pivot from suspicious domains to related infrastructure
• Brand protection: Find domains mimicking legitimate infrastructure patterns

Parameters

Parameter Details

domain

• Accepts ASCII domains or internationalized domain names (IDN/UTF-8)
• Unicode domains are automatically converted to Punycode (A-label) format
• The spelling is canonicalized (case, whitespace, trailing dots) and no labels are removed: www.example.com is looked up as www.example.com
• A single label (localhost, com) is rejected before any lookup
• When canonicalizing changed more than letter case, the output carries a hint line submitted_domain: <your input> (sent as <name>). See datapulse_help(topic="normalization")
• Maximum length: 253 characters
• Examples: example.com, münchen.de, xn--mnchen-3ya.de

similarity

• Higher values = stricter matching (fewer, more similar results)
• Lower values = broader matching (more results, less similar)
• Recommended ranges:
  • 0.98-1.00: Near-identical infrastructure (the same hosting stack; evidence for, not proof of, a common operator)
  • 0.92-0.97: Very similar (shared major infrastructure components)
  • 0.85-0.91: Similar (shared hosting/registrar patterns)
  • 0.75-0.84: Loosely similar (common provider overlap)

Example Usage

Basic search (high similarity)

{
  "domain": "example.com"
}

Broader search (lower threshold)

{
  "domain": "suspicious-domain.com",
  "similarity": 0.85
}

IDN domain search

{
  "domain": "münchen.de",
  "similarity": 0.90
}

Response Format

Returns CSV with a header row and one row per matching domain. Cosine similarity is rounded to 4 decimal places. Multi-value fields use * as a delimiter (e.g., 21342*44273).

Success Response

name,registrar_iana_id,registration_date,fpons,fpons_asn,fprns,fprns_asn,fpmx,fpmx_asn,fpaw_asn,cosine_similarity
example.com,1234,2023-01-15T00:00:00,a.ns.example*b.ns.ex,13335*15169,a.ns.example*b.ns.ex,13335*15169,mx1.example.com*mx2.,13335,13335*15169,1.0000
related-domain.com,1234,2023-03-20T00:00:00,a.ns.example*b.ns.ex,13335*15169,a.ns.example*b.ns.ex,13335*15169,mx1.example.com*mx2.,13335,13335,0.9730

CSV Columns

Error Responses

{"error": "missing required parameter 'domain'"}
{"error": "similarity must be between 0.75 and 1.00"}
{"error": "simserver: <the daemon's own error message, verbatim>"}

No similar domains is not an error: the CSV header row comes back alone with a hint as a second content item. A daemon that cannot be reached fails with the socket error itself.

Similarity Signals (Feature Space)

The similarity score is computed from a 1000-dimensional unified embedding composed of these DNS infrastructure signals:

Signal Categories

How Similarity Works

1. Each signal is tokenized and embedded into a 100D vector
2. Vectors are concatenated into a 1000D unified embedding
3. PCA reduces dimensionality for efficient similarity search
4. Cosine similarity compares embeddings using pgvector

Signal Weighting Implications

Strong indicators (rare overlaps = high signal):

• Matching custom nameservers (not Cloudflare/AWS/etc.)
• Same boutique hosting ASN
• Matching MX configuration
• Same registrar + similar registration date

Weak indicators (common = low signal):

• Cloudflare (ASN 13335) - millions of domains
• Google Cloud (ASN 15169) - very common
• AWS (various ASNs) - extremely common
• Major registrars (GoDaddy, Namecheap, etc.)

Interpretation Guide

Score Interpretation

What High Similarity Means

A score of 0.95+ typically indicates:

• Same nameserver configuration
• Same hosting provider/ASN
• Same mail infrastructure
• Often the same registrar
• Similar registration timeframe

What High Similarity Does NOT Mean

• Domains are definitively owned by same entity
• Domains are related by content
• Domains share the same website
• Domains have similar names (use searchlabels for that)

Use Cases

A) Security Investigation - IOC Expansion

Start with a known malicious domain, find related infrastructure:

{"domain": "phishing-site.example", "similarity": 0.90}

Workflow:

1. dptechsim → find infrastructure siblings
2. dphistory on top hits → check historical changes
3. datapulse_live_rdap → verify registration patterns
4. datapulse_live_dns → current DNS verification

B) Brand Protection

Find domains mimicking legitimate infrastructure:

{"domain": "your-brand.com", "similarity": 0.85}

Look for:

• Similar infrastructure but different registrar
• Recent registration dates
• Matching hosting but different content

C) Operator Discovery

Find all domains by a suspected operator:

{"domain": "known-operator-domain.com", "similarity": 0.95}

Indicators that point toward a common operator (none of them proves it):

• Identical nameserver configuration
• Same registrar IANA ID
• Clustered registration dates

D) Infrastructure Mapping

Map hosting relationships for a domain portfolio:

{"domain": "company-domain.com", "similarity": 0.92}

Common Pitfalls

1. Major CDN/Hosting Noise

Domains on Cloudflare, AWS, or Google Cloud will show many false positives.

Mitigation:

• Use higher similarity thresholds (0.95+)
• Look for matching registrar + registration date patterns
• Filter results by ASN fingerprints in response

2. Shared Hosting Platforms

Many unrelated domains share hosting infrastructure (Shopify, WordPress.com, etc.).

Mitigation:

• Cross-reference with searchlabels for name patterns
• Check registration dates for clustering
• Use dphistory to see infrastructure changes over time

3. Score vs. Significance

A 0.85 score between two Cloudflare domains is less meaningful than 0.85 between two domains on a boutique host.

Mitigation:

• Examine the fingerprint fields in the response
• Look for rare ASNs or custom nameservers
• Weight rare overlaps higher in your analysis

Limits and Constraints

Performance Notes

• First query after cold start: 30-60 seconds (index warming)
• Subsequent queries: typically < 5 seconds
• Major domains (banks, tech): may take 40-50 seconds due to many matches

Relationship to Other Tools

Complementary Tools

Suggested Workflows

Typosquatting Investigation:

searchlabels("brand") → dptechsim(top_hit) → dphistory(matches) → live_rdap(suspicious)

Infrastructure Pivot:

dptechsim(seed, 0.90) → filter by rare ASN → dphistory(filtered) → live_rdap(filtered)

Operator Attribution:

dptechsim(known_domain, 0.95) → group by registrar_iana_id → dphistory(clusters)

Availability

This tool requires the simserver daemon to be running. If unavailable:

• Tool will not appear in tools/list response
• Health check will report unhealthy status
• Calls fail with the socket connection error, verbatim

Check availability via datapulse_health().

Data Freshness

• DNS fingerprints are updated periodically (typically daily)
• Vector embeddings are regenerated on major updates
• Historical data available via dphistory for change tracking