Defaults.Exposed

How to enable DNSSEC on Reg.ru

You’ve found the DNSSEC switch at Reg.ru and want to know whether pressing it finishes the job or can take the domain offline. That depends on where the two halves happen: the DNS host signs the zone and produces a DS record; the registrar lodges it in the parent zone. Until both are done, no resolver validates anything.

Reg.ru is the registrar and, when the domain uses its own nameservers, the DNS host for this record. It offers DNSSEC signing as a feature of a paid add-on rather than the free DNS service, and where an external host signs the zone instead, Reg.ru only carries the resulting keys through to the registry.

What a signed zone proves

DNSSEC attaches signatures to the answers your DNS hands out, so a resolver can confirm that the address it got for your domain came from your zone and wasn’t changed on the way. It says nothing about what’s running at that address, and nothing about email: a signed domain can still have its name forged on a message, because the controls for that are SPF, DKIM and DMARC, covered on the DMARC page.

The signing happens wherever the zone is served, so it’s a DNS host job, and the host publishes the public key in the zone as a DNSKEY record. The DS record is a hash of that key, and it belongs one level up, in the parent zone (.com, .org, .co.uk, whichever your domain sits under), where a resolver picks up the chain of trust before it asks your nameservers anything.

Only the registrar can place a record there, so the DS goes through the registrar’s account, which may or may not belong to the company running your DNS. Of the 316,600,902 domains carrying a grade or counted dead in the September 2026 census, 21,732,692 (6.9%) are signed and validate, and 173,606 (0.05%) are signed and broken, meaning a DS record is lodged and the signatures in the zone don’t match it. The order below keeps you out of the second group.

Confirm who answers DNS before you touch anything

Check the domain’s assigned nameservers in the Reg.ru console before doing anything else. DNSSEC only works when the domain is delegated to ns1.reg.ru and ns2.reg.ru. If the domain instead shows ns1.hosting.reg.ru, ns2.hosting.reg.ru, ns5.hosting.reg.ru or ns6.hosting.reg.ru, the DNSSEC option will not be available, because those hosting nameservers do not support it.

The steps run in the order that can’t break the domain, and each carries its own wait; this one has none. What it decides is which steps happen inside Reg.ru and which happen in another account. Skip it and you can end up signing a zone no resolver is querying, or lodging a DS for a key the live nameservers aren’t using.

Switch DNSSEC on

  1. Sign in to the Reg.ru personal account, labelled “личный кабинет”.
  2. Open the “Домены” (Domains) section from the account menu.
  3. Click the row for the domain to open its management page.
  4. Confirm the “Премиум DNS” (Premium DNS) service shows as active for the domain, and order it first if it does not.
  5. In the “DNS-серверы и управление зоной” (DNS servers and zone management) block, click “Изменить” (Edit).
  6. Open the “Управление” (Management) tab and find the DNSSEC field, which shows the current status.
  7. Switch the DNSSEC toggle on and confirm the change.
  8. Where an external host signs the zone instead, open the domain’s DNSSEC section and click “Добавить ключи” (Add keys) rather than switching Reg.ru’s own toggle on.

When DNSSEC is switched on through the nameserver path, Reg.ru signs the zone and lodges the DS and key material with the registry on its own, with nothing to copy or paste. When DNS sits elsewhere, Reg.ru only retrieves the DNSKEY records that host already published and passes them to the registry through “Добавить ключи”, leaving the actual signing to that other host.

Signatures and the DNSKEY have to be live on the nameservers before a DS pointing at them is lodged anywhere, because once the DS lands in the parent zone, validating resolvers demand signatures that match it. In a two-company setup this is the point to stop, wait for the DNS host to show the zone as signed, and only then carry the DS across.

The DS record, value by value

A DS record carries four values, shown together on one panel once signing is on. The key tag is a number identifying which DNSKEY the record refers to. The algorithm names the signing algorithm the host chose: 13 is ECDSA P-256 with SHA-256, what most hosts generate today; 8 is RSA with SHA-256, still valid; 5 and 7 are older RSA variants a fresh setup shouldn’t use.

The digest type says how the key was hashed: 2 is SHA-256, the one to publish; 4 is SHA-384, which some hosts offer alongside it; 1 is SHA-1, which registries are removing. The digest is the fingerprint itself, 64 hexadecimal characters for SHA-256, with no spaces. Here is what the panel gives you to carry across:

No record value to enter. Reg.ru generates the DNSKEY and DS material itself and lodges it with the registry when the toggle is switched on, and when "Добавить ключи" is used it retrieves the DNSKEY records from the zone's authoritative server automatically.

Lodge the DS values exactly as the host displays them. If the host offers two digest types for the same key, the SHA-256 one alone is enough. There’s nothing to tighten afterwards: the strength of the record is fixed by the algorithm the host signs with, and a host that manages the keys rolls them and refreshes the DS itself.

Where each value goes depends on the registrar’s form. There is no type, name or value field to fill in for this path. The DNSSEC field on the “Управление” tab is a status toggle, on or off, with no host or content to type. Where DNS is hosted elsewhere, the “Добавить ключи” action has no fields either, since Reg.ru pulls the DNSKEY records from the zone’s authoritative server on its own.

Paste every value rather than typing it. A digest with one wrong character produces a DS that no key in the zone matches, and a validating resolver can’t tell that apart from a hijacked zone, so it refuses the whole domain. Match the algorithm and digest type numbers to the panel, whatever the registrar’s form offers as a default.

A few things trip people at Reg.ru in particular.

Wait, then check the chain

Two waits stack here, and they aren’t the same length. The toggle takes effect within minutes, and the saved status appears back on the “Управление” tab where the DNSSEC field was found. Full propagation of the change across the wider DNS can take up to a day.

The parent zone is the slower one. The registry publishes the DS on its own schedule, and any resolver that looked your domain up recently keeps the old answer, with no DS in it, until the parent’s TTL runs out, which can be up to a day. During that window one network can show the domain validating while another shows it unsigned, and both are reporting what they’ve cached.

Once that day has passed, run the free scan against the domain. It validates the way a resolver does and reports each link separately: whether a DS is published in the parent, whether it matches a DNSKEY in the zone, and whether the signatures verify.

Return to the “Управление” tab and check the DNSSEC field shows as active once the toggle has been confirmed, or once the registry has accepted the keys added through “Добавить ключи”.

To see the raw answer, ask a validating resolver with dig:

dig +dnssec yourdomain.com A

Read the flags on the header line. ad means the resolver validated the chain and it held. A normal answer with no ad means the resolver saw the domain as unsigned, so after the wait the DS hasn’t reached the parent zone or was never lodged. SERVFAIL means the chain is there and broken, and the DNSSEC SERVFAIL page walks through which link.

Broken is worse than unsigned. Validating resolvers, including the large public ones, drop the domain for their users while everyone else still reaches it, so the outage looks intermittent and gets blamed on hosting.

Before you move DNS or turn signing off

The step that catches people comes months later, when the domain moves to a new DNS host or signing gets switched off and the DS record stays behind in the parent zone. From then on validating resolvers demand signatures the new nameservers aren’t producing, and the domain returns SERVFAIL for their users until someone removes the DS.

So the teardown runs in reverse. Remove the DS record at the registrar first, wait out the parent’s TTL so no resolver still holds a copy, and only then switch signing off or change the nameservers. A domain with no DS and a signed zone is treated as unsigned, which is safe; a domain with a DS and no signatures is treated as forged, which is the outage.

The other habit is signing in one place. If the DNS host already signs the zone, its DS goes to the registrar and the registrar’s own signing switch stays off; two signers means two keys and one DS, and resolvers refuse whichever half doesn’t match. The DNS page covers the other records in the same zone.

Before you log out of the registrar, write down where the DS is lodged and the key tag it carries, next to the renewal date, with “remove the DS first” beside it. That note is what stops the domain going dark the day someone changes the nameservers.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.