Skip to main content
← back to home FR

Architecture

The last verified legacy state and the v2 target

Deployment status

At the last verified production snapshot on 2026-08-29, the three public nodes still used the legacy dnsdist, BIND and secondary-DNS service stack. That dated evidence is not proof of current live state; reverify the deployed service before making a current claim. The Go-native architecture below is the v2 target state. It is implemented in the rebuild branch, but repository state is not production-cutover evidence.

Last verified production snapshot

Current production status must be verified through the status service; this page does not make an uptime guarantee.

v2 target architecture

The v2 platform consists of five Go binaries plus data stores:

  1. The ledns binary runs as two separate services on distinct IP address sets: ledns-auth serves authoritative UDP/TCP DNS, while ledns-resolver handles recursive UDP/TCP, DoT, DoQ and DoH through BIND. They do not share an in-process hosted-zone dispatcher or database credentials.
  2. ledns-control provides account authentication, the customer portal, REST API and administration controls.
  3. ledns-signer exposes a bounded signing API around SoftHSM on an isolated host. SoftHSM is a software HSM, not dedicated hardware.
  4. ledns-analytics accepts only closed, thresholded aggregate batches.
  5. ledns-probe is an optional Pro/Enterprise health-check worker.

PostgreSQL is the source of truth for accounts, zones and control-plane state. ClickHouse stores thresholded DNS aggregates. Mimir and Loki hold operational metrics and logs on separate paths.

DNS serving

The recursive service uses the same independent path for classic and encrypted transports. It does not consult locally hosted zones, including stale zones whose ownership changed. Ordinary public delegation can still lead BIND to an authoritative service. The authoritative service retains its signed last-known-good behavior separately. These source and private-lab controls are not proof of public deployment or a completed delegation transfer. Resolver controls include per-client limits, bounded caching and stale-answer support.

Primary-zone record changes and scoped RFC 2136 updates are transactional. Secondary zones pull AXFR or IXFR from the customer’s primary after TSIG authentication. TSIG authenticates transfers; it does not encrypt ordinary DNS zone-transfer transport.

DNSSEC signing

The v2 signer supports generated and imported RSA/SHA-256 or ECDSA P-256 keys. Private keys imported into SoftHSM are configured as non-extractable. P-384 and Ed25519 are not currently supported by the signer.

DNSSEC signing is a v2 launch capability. At the last verified 2026-08-29 snapshot, the le_dns service zones were unsigned. That dated evidence is not proof of current live state; do not describe them as validating until the deployed signer and relevant parent DS records are verified.

Analytics boundary

The v2 resolver analytics path aggregates observations in memory for one-hour buckets. A row is released only after reaching the configured threshold, 100 queries by default. Released dimensions can include a registered domain or eligible normalized qname, a masked /24 IPv4 or /48 IPv6 network, ASN and organisation, country and subdivision, transport, result and TTL. ODoH rows omit source-network attribution.

Public-recursive hourly rows expire after 30 days and their daily rollups after 90 days. Privacy-safe authoritative customer aggregates are stored separately for operator capacity and reliability work: hourly rows expire after 180 days and daily rows after 730 days. Customer plans expose only the canonical zone owner’s current 7/30/90-day analytics history window; that window is not a tier-specific deletion schedule. These v2 guarantees do not retroactively describe the legacy telemetry path observed on 2026-08-29; reverify the deployed path before making a current claim and until cutover is proved.

Plan boundaries at v2 launch

Plan limits and feature gates come from one server-side catalogue. Free includes 2 authoritative and 5 secondary zones; Hobby includes 5 and 10; Pro includes 15 and 30; only Enterprise’s authoritative and secondary zone counts are unlimited. Other Enterprise resources retain finite safety ceilings. Plesk HTTPS desired-state synchronization has a Pro/Enterprise preview allocation but remains unavailable before server-side installation enrollment and external acceptance. See pricing.