RedundantDNS nameservers

The RedundantDNS nameservers are DNS servers we run ourselves, in several regions and at different hosting providers. You attach them to a zone like any other provider, with no account to open and no credentials to give: they are one more independent copy of your zone next to the providers you already use.

What you get

• Several nameservers in one attachment. Each node is a separate server with its own name (vega-latam.redundantdns.org, altair-na.redundantdns.org, ...). Attaching "RedundantDNS nameservers" to a zone creates the zone on every node, writes every record to each of them, and adds every node's name to the zone's NS set.
• Independent nodes. The nodes are never a primary and a secondary: the platform writes each one directly. A node that is down loses nothing; the others keep answering with every record, and the node catches up when it is back.
• Included in your plan. Every plan includes them, the trial too, with no pass-through line on your bill and no per-query charge. They count as one provider toward your plan's providers per zone.
• Free for domains registered or transferred here. When a zone has the name of a domain your organization registered on RedundantDNS or transferred in to RedundantDNS, the RedundantDNS nameservers are free for it, with or without a plan: the zone does not count toward your plan's zones, the nameservers do not count toward its providers per zone, and it keeps working after the trial ends or while a payment is late (records, reconcile, detach and delete stay open, and the nameservers keep receiving your changes). The zone shows a Free with your domain badge. Other providers and standby attachments follow your plan. A zone stops being free when its domain is no longer ours: it expired or was deleted at the registrar, or its registration or transfer was canceled. The zone and its records are kept and follow your plan again; renewing the domain makes the zone free again.
• Same rules as any provider. The zone's capabilities, drift checks, probes, alerts and the delegation check work as for the other providers.

Add them

1. On Providers, choose Add connection, then RedundantDNS nameservers (managed). There is nothing to fill in; a name is optional.
2. An owner or admin accepts the RedundantDNS Nameservers Terms once for the organization, if it has not already. They are separate from the Managed Provider Terms of third-party managed accounts.
3. On the zone's Providers tab, choose Attach provider and pick the connection. The zone is created on every node and the NS plan grows with their names.
4. Update the delegation at your registrar with the new NS plan (the Delegation tab lists it), as for any provider you add.

The provider only appears in the form when the platform has nameserver nodes; an installation without them does not offer it.

Reading the status

The attachment shows one line per node: the node's name, its region, its last sync and its state.

A node that stops answering also shows on the zone's Health panel and, when every node of the attachment is down, raises provider_down like any provider. The platform's operators are alerted about a node that is down and take care of it; you do not need to act.

When the operators retire or add a node, the NS set of the attachment changes: the zone gets a new serial, every provider receives the new apex NS set, and the delegation check tells you when the registrar should be updated.

Detach

Detaching the RedundantDNS nameservers deletes the zone from every node (the nodes belong to the platform, so nothing is left behind on them). Deleting the zone does the same, and so does a billing detach (an unpaid invoice past the detach period) of a zone that is not free. Remove their names from the delegation at your registrar first.

Zone names on the nodes

The nodes serve every organization's zones from one namespace, so a zone name belongs to one organization with everything under it: you cannot create a zone inside a verified zone another organization manages (_acme-challenge.example.com next to someone else's example.com), nor above one (409 zoneNameUnderAnotherOrg, 409 zoneNameAboveAnotherOrg). Subzones of your own zones work as usual. Each zone on a node records your organization as its owner (the PowerDNS zone account).

If the name (or a parent of it) is already delegated to these nameservers when you attach them, for example a delegation left at your registrar after a zone was deleted, the attach asks for proof of control (409 delegationOwnedElsewhere): publish the TXT record shown on the zone's Delegation tab (_rdns-challenge.<zone>) on another nameserver your domain delegates to, then attach again. If your delegation lists only these nameservers, add one of your own nameservers to it temporarily to serve that TXT, register or transfer the domain here, or (when your organization deleted the zone) create it again within 30 days of the delete. Domains registered or transferred here never need it. See the API guide, "Zone names, claims and takeover protection".

Limits

The nodes are sized for these limits each; the platform adds nodes before any of them passes 60% of a limit.

Fair use applies to queries per plan (Starter lowest, Business highest), with a warning before any limiting. Enterprise can have dedicated nodes.

What the platform does

• Create and manage zones only: the connection always creates, writes and deletes the zone on the nodes (there is no "manage an existing zone" or mirror source level, and no credentials to rotate).
• The capabilities are PowerDNS's: every record type of the canonical model, TTLs from 1 second, wildcards, an editable apex NS set, no CNAME at the apex.