How it works: enterprise

Multi-provider DNS where your provider credentials stay in your network

Run the data plane yourself. We publish the desired state of your zones to a bucket; the component in your network applies it to your providers and reports back. This page describes the design as it is being built.

Coming soon

Your provider credentials stay in your network

The part of RedundantDNS that talks to your DNS providers, the data plane, runs inside your network. It keeps the provider credentials in its own sealed store, encrypted with a key you control: a master key you generate, or your own AWS KMS or OCI Vault.

You enter credentials in the data plane’s own admin page or CLI, never in our dashboard. Our dashboard only shows that a connection exists and whether it is healthy. Our side keeps doing what needs no credentials: delegation checks, probes from our regions and alerts.

The RedundantDNS control plane writes the desired state to a bucket and reads status from it. A data plane inside the customer network reads the desired state, applies it to provider A and provider B with credentials kept in its own sealed store, and writes status back. Provider credentials never leave the customer network.

The bucket is the only channel

We publish the desired state of your zones to a bucket; your data plane reads it, applies it and writes back what it applied, any drift and its probe results. Everything the two sides exchange goes through it; the optional push described below only shortens the wait.

The bucket can be ours or yours (S3-compatible or OCI Object Storage). On ours, your data plane gets credentials scoped to your organization’s prefix, short-lived and renewed before they expire (a site with no connection to our API sets a scoped key by hand). On yours, you create a scoped identity for our control plane from a template we ship, and nothing of yours sits on our storage.

We write: orgs/<id>/zones/**
Cursor: orgs/<id>/head.json
Your data plane writes: orgs/<id>/status/**
Credentials: Scoped to the prefix, short-lived
Dashboard shows: Applied by data plane dp-1 at 10:42

Sample values.

Changes arrive fast without hammering storage

We keep one small cursor object per organization, rewritten as the last step of every change. Your data plane asks for it every 15 seconds with a conditional request: when nothing changed the answer is empty, and when something changed it lists exactly which zones to fetch.

When your data plane may reach us, it also keeps one outbound HTTPS connection to our event stream, so a change arrives in under a second. Sites that can resolve DNS but not reach our API can watch a DNS record that carries your organization’s serial instead. Both only shorten the wait: the cursor poll keeps running either way.

Three channels tell the data plane there is work: a conditional GET of the cursor object every 15 seconds, always on; a push over one outbound HTTPS connection, under a second; and a DNS wake-up record with the serial, 5 to 20 seconds. The data plane then fetches only the zones that changed.

Licensing that never takes your DNS down

Online, the installation checks a signed TXT record for your account, served by our own multi-provider zone, so the check is as available as the product. Offline, for air-gapped sites, it uses a signed license file renewed once a year and needs no network at all.

When a license expires, you get warnings and then a grace period: 10 days for a monthly license, 30 for a yearly one. After that the data plane stops applying changes. It never deletes, locks or hides your zones, your providers keep serving them, and export always works. The only outbound signal of the online check is that DNS query.

The installation checks its license at start and every 6 hours, online through a signed TXT record on the RedundantDNS multi-provider zone, or offline through a signed license file renewed yearly. States go from valid to warning, grace and degraded; degraded stops applying changes while zones keep being served.

An audit trail you can verify (planned)

Every audit event and every zone change will also go to an append-only audit stream. Each entry carries the hash of the one before it, and each day is sealed with a signature, so a missing or altered entry shows up when the chain is checked.

For stricter needs, the stream can go to a separate write-once bucket, such as S3 with Object Lock or OCI with a locked retention rule, written with a credential that cannot delete. A planned rdns compliance command reports the live state of these controls with the evidence behind each one. It is a report you can hand to an auditor, not a certification.

Audit stream: Hash-chained, sealed daily
Check it: rdns audit verify
Audit bucket: Write-once, optional
Posture report: rdns compliance

Planned. Sample values.

Health reports through your own zones

An installation we cannot reach can still tell us how it is doing, so we can alert you when it stalls. It publishes one small TXT record in a zone it already manages, encrypted to our public key and signed by the installation. Anyone can see that the record exists; only we can read it.

It carries the applied serial, the last apply time, provider health, the component version and the license state, and nothing about your records. You can switch it off per installation; you then only lose the alerts we would have raised from it.

Record: _rdns.example.com TXT
Readable by: RedundantDNS only (encrypted)
Carries: Applied serial, provider health, version
Switch off: RDNS_TELEMETRY_DNS=off

Sample values.

The same product underneath

The zone model, the diff, apply and verify cycle and the probes are the ones described in how it works. Syncing is deterministic: no model writes a record, and every change is a diff in the zone journal. The security page covers how the hosted platform handles keys and data.