Protective DNS Architecture

01Executive Summary

Protective DNS (PDNS) intercepts domain resolution requests and blocks connections to known-malicious infrastructure before a TCP handshake ever occurs. Because every network connection begins with a DNS lookup, the DNS layer is the single most efficient point to disrupt malware delivery, command-and-control communication, phishing, and data exfiltration.

This is not a theoretical model. It is active government policy:

• The UK National Cyber Security Centre operates PDNS for all central government departments and has published deployment guidance for the private sector
• The US NSA and CISA issued joint guidance (2021, updated 2023) recommending protective DNS as a foundational security control for all organizations
• The European Union is funding DNS4EU, a continent-wide protective DNS infrastructure under the Connecting Europe Facility

Escudo implements PDNS as a managed service. A single DNS configuration change — no software, no agents, no appliances — activates threat blocking, content filtering, device identification, and forensic logging across every device on a network.

02Threat Intelligence Pipeline

Escudo aggregates threat data from 18 independent feed sources, organized by threat category:

Category	Feed count	Coverage
Malware distribution	4	Domains hosting payloads, exploit kits, drive-by downloads
Phishing	3	Credential harvesting, brand impersonation, social engineering
Command and control	3	Botnet C2, RAT callbacks, data exfiltration endpoints
Ad networks and trackers	4	Cross-site tracking, fingerprinting, malvertising vectors
Telemetry and analytics	2	OS-level telemetry, app analytics, crash reporting
Newly registered domains	2	Domains under 30 days old (high-risk category)

Feed processing architecture

Feeds are refreshed on a 5-minute cycle. Each refresh follows a deterministic pipeline:

1. Fetch: Pull updated lists from upstream sources via HTTPS. Retry with exponential backoff on failure.
2. Normalize: Convert all formats (hostfile, domain list, DNSBL, JSON) to a canonical domain representation. Strip subdomains where the root domain is blocked.
3. Deduplicate: Merge across feeds. A domain appearing in multiple feeds increases confidence but is stored once.
4. Validate: Reject entries that fail DNS syntax validation. Flag and quarantine feeds with anomalous update sizes (potential feed compromise).
5. Load: Atomically swap the active blocklist in memory. No query is ever served from a partially-loaded list.

The current unified blocklist contains approximately 1.53 million unique domains.

03DGA Heuristic Engine

Domain Generation Algorithms (DGAs) are used by malware families to produce pseudo-random domain names for command-and-control communication. Because these domains are generated dynamically, they cannot appear in static blocklists. Escudo applies real-time heuristic analysis to every queried domain.

Scoring methodology

Each domain label is evaluated across four independent dimensions:

• Shannon entropy: Measures character randomness. Natural language domains (e.g., amazon.com) have low entropy. DGA domains (e.g., xjk8mzp3qr.net) have high entropy. The engine computes entropy per label and normalizes against label length.
• Character bigram frequency: Compares character pair distribution against a reference corpus of legitimate domains. DGA output typically contains bigrams rare in natural language.
• TLD reputation weighting: Certain TLDs (.top, .xyz, .buzz, .gq) show disproportionate use in malicious registrations. The engine applies a configurable weight based on historical abuse rates.
• Composite scoring: Individual signals are combined into a normalized score. Domains exceeding a configurable threshold trigger a block response. Thresholds can be tuned per deployment — aggressive for consumer networks, conservative for enterprise environments where false positives carry higher cost.

04PIX Fraud Detection

PIX is Brazil's instant payment system, processing over 3 billion transactions per month. Attackers create convincing replicas of banking portals to intercept PIX transfers. Escudo applies specialized heuristics to identify these domains before users reach them.

Detection signals

• Typosquat analysis: Computes edit distance (Levenshtein) between queried domains and a protected list of financial institution domains. Domains within a configurable distance threshold are flagged for additional analysis.
• Keyword presence: Scores domains containing financial terms (pix, banco, pagamento, transferencia, boleto) combined with brand names.
• TLD reputation: Weights domains on TLDs with high abuse rates more heavily.
• Registration recency: Newly registered domains matching financial patterns receive elevated risk scores. Most legitimate banking domains have registration histories measured in years, not days.

Protected institutions

The detection model covers major Brazilian financial institutions including Banco do Brasil, Bradesco, Itau, Caixa Economica, Nubank, Inter, C6, Santander Brasil, BTG Pactual, and Mercado Pago, among others. The protected institution list is updated continuously.

05Device Fingerprinting

Escudo identifies device types on the network through passive DNS pattern analysis — no active scanning, no agents, no SNMP.

Methodology

Different operating systems and device types generate characteristic DNS queries as part of their normal operation:

• Apple devices query captive portal detection domains and iCloud services
• Android devices query Google connectivity checks and Play services
• Windows devices query Microsoft NTP, telemetry, and update endpoints
• Smart TVs, IoT devices, and gaming consoles query manufacturer-specific domains

Escudo maintains a rule engine of 127 pattern definitions that map DNS query signatures to device categories. Each pattern carries a confidence weight. When multiple patterns match for a single source IP, confidence scores are aggregated to produce a device classification.

06Forensic Evidence Chain

For organizations with compliance, audit, or incident response requirements, Escudo provides tamper-evident logging that can demonstrate the integrity of DNS records after the fact.

Hash chain architecture

1. Per-event hashing: Every DNS event (query, response, block decision) is hashed with SHA-256 at the time of recording. The hash includes the event data, timestamp, and the hash of the previous event — forming a sequential chain.
2. Hourly checkpoints: At the top of each hour, a checkpoint hash is computed from all events in the preceding hour. This allows efficient verification of any time range without replaying the entire chain.
3. Daily Merkle root: At midnight UTC, a Merkle tree is constructed from all hourly checkpoints. The root hash provides a single value that verifies the integrity of an entire day's records.

Tamper detection

Any modification to a historical record — insertion, deletion, or alteration — breaks the hash chain from that point forward. Verification can be performed independently: given the raw event data and the published checkpoint hashes, any party can recompute the chain and confirm integrity.

Export formats

Forensic logs can be exported in JSON (for programmatic analysis) or CSV (for spreadsheet and SIEM import). Exports include the hash chain data, allowing independent verification of the exported records against the checkpoint hashes.

07Infrastructure

Escudo operates a two-node architecture optimized for the primary deployment regions:

Role	Location	Provider	Function
DNS Resolver	Sao Paulo, Brazil	Vultr	Primary resolver for Latin American networks
DNS Resolver	Falkenstein, Germany	Hetzner	Primary resolver for European networks
Management	Nuremberg, Germany	Hetzner	API, dashboard, threat intelligence processing

Latency

Brazilian ISPs using the Sao Paulo resolver see sub-5ms response times for cached queries. European networks served from Falkenstein achieve comparable latency. The architecture is anycast-ready — additional resolver nodes can be deployed in any region without changes to client configuration.

Failover

Each resolver operates independently with a full copy of the blocklist and threat intelligence data. If one node becomes unavailable, clients configured with both resolver addresses automatically fail over to the surviving node. The management layer synchronizes state to all resolvers but is not in the query path — resolvers continue to function during management downtime.

08Multi-Tenancy

Escudo is designed for ISP deployment where a single resolver instance serves thousands of subscribers, each with potentially different security policies.

Tenant isolation

• Subscriber detection: Source IP address is mapped to a subscriber account at query time. ISPs provide IP-to-subscriber mappings via API or RADIUS integration.
• Policy isolation: Each subscriber's filtering configuration, content categories, device groups, and logging preferences are independent. One subscriber's configuration cannot affect another's.
• Data isolation: Query logs are partitioned per subscriber. ISPs receive aggregate analytics only. Individual subscriber data is accessible only to the subscriber and to authorized ISP support staff with explicit permission.

White-label customization

ISPs can customize block pages (branding, messaging, support links), dashboard appearance, and notification templates. The subscriber-facing experience can be fully branded as the ISP's own security product.

API authentication

All management API endpoints require authentication via API key passed in the request header. Keys are scoped per tenant with configurable permission levels (read-only, subscriber management, full administration). Rate limiting is applied per key.

09Compliance

LGPD (Brazil)

DNS query processing is based on the legal basis of legitimate interest (Art. 10) for threat detection and contractual necessity (Art. 7, V) for paid service features. Data subject rights (access, deletion, portability) are supported via API and email request. The Data Protection Officer can be reached at privacy@escudo.network.

GDPR (EU)

European data is processed and stored exclusively in Hetzner's German data centers. Processing basis aligns with LGPD: legitimate interest for security functions, contract performance for paid features. Standard Contractual Clauses are available for ISP deployments requiring cross-border data processing agreements.

NIS2 Directive

Escudo's architecture supports NIS2 compliance for entities classified as essential or important: incident reporting via forensic export, supply chain documentation via sub-processor transparency, and security-by-design through Rust's memory safety guarantees.

Data retention

All DNS query metadata is permanently deleted after 30 days. No anonymized or aggregated derivatives are retained beyond this period. Account data is retained for 90 days after account closure.

10Performance

Language and runtime

Escudo is written in Rust. This is a deliberate technical choice with specific implications for a security product:

• Memory safety: Buffer overflows, use-after-free, and null pointer dereferences — the vulnerability classes responsible for approximately 70% of CVEs in C/C++ codebases — are eliminated at compile time.
• Zero-cost abstractions: High-level constructs (iterators, pattern matching, trait-based polymorphism) compile to the same machine code as hand-written loops. There is no runtime overhead for code clarity.
• No garbage collector: Memory is managed deterministically through ownership and borrowing. There are no GC pauses, no stop-the-world events, no latency spikes during collection cycles.

Blocklist lookup performance

The unified blocklist is stored in a HashSet with O(1) average lookup complexity. A DNS query against 1.53 million blocked domains completes in microseconds. The entire blocklist resides in memory — there is no disk I/O in the query path.

Async I/O

Network operations use Tokio, Rust's async runtime. Each DNS query is handled as a lightweight task (not a thread). A single resolver node can sustain tens of thousands of concurrent queries without thread pool exhaustion.

Infrastructure cost

The complete Escudo deployment — two DNS resolvers, management server, database, threat intelligence processing — operates on approximately EUR 28 per month of infrastructure. This cost efficiency is a direct consequence of Rust's performance characteristics and the architectural decision to keep the system simple.