Every entry in this category describes a safeguard that can be applied to a domain name, and what it does and does not stop. Controls are the other half of this reference: the incidents index describes ways a name is lost, and this one describes the mechanisms that make each of those losses harder, slower, or noisier. The entries are not a checklist and they are not ranked. They are described so you can tell which layer each one acts on, and therefore which failures it is capable of preventing.
The layer is the whole argument
Every control page opens with one word before any prose: registry, registrar or DNS. That is the answer-first field for this category, and it is doing more work than it looks like it is doing.
A control at the registry layer is enforced in the registry database itself, above the registrar. Its defining property is that it cannot be released from inside a registrar account, which is precisely why it survives the compromise of that account. A control at the registrar layer is enforced in the registrar's own systems and lives in the account. It is effective against outside requests and, by construction, offers much less against somebody who is already authenticated inside the account as the registrant. A control at the DNS layer does not touch the registration record at all; it constrains what answers resolve, or who is permitted to act on the name's behalf, and it is the right place to address a class of failures that never touch the registration.
Reading a control's layer first prevents the most common error in this field, which is to adopt a safeguard at one layer and assume it covers a failure at another. A lock in the registrar account does not help if the registrar account is what was taken. A cryptographic guarantee about DNS answers does nothing about who is listed as the registrant. Each entry says plainly what its control does not cover, because a control described only by what it prevents will be trusted with things it was never built for.
Two disciplines, and why the split is not cosmetic
The entries here fall into registry-level controls and registrar-level controls, with the DNS-layer safeguards grouped alongside the DNS-layer incidents so that the control and the failure it addresses sit next to each other.
The registry-level group is small, and its size is the point. There are very few safeguards that live above the registrar, they generally require out-of-band verification to release, and they are correspondingly inconvenient. That inconvenience is the security property, not a shortcoming of the implementation: a safeguard that can be lifted quickly by whoever holds the account credentials provides very little against the case where the credentials are the thing that was lost.
The registrar-level group is larger and covers the account itself — what authenticates a person into it, what it discloses, what codes it issues, and what it will tell you when something in it changes. That is where most domain portfolios actually live and where most of the practical work of holding a name is done.
The trade-offs are stated, not hidden
Some of these controls have real costs, and this reference states them. A control that fails closed protects the integrity of an answer by refusing to give a wrong one, which means a misconfiguration in that control takes the name off the air rather than degrading quietly. A control that removes information from the public record reduces exposure and simultaneously removes evidence a registrant may later need in order to demonstrate that the name was theirs. Neither of those is a reason to avoid the control. Both are reasons to adopt it deliberately, with the operational practice that goes with it.
A reference that only listed benefits would be a product page. The judgement about whether a trade-off is worth taking is yours to make and depends on the portfolio, but the trade-off itself is a fact about the mechanism and belongs here.
What the docket strip records
Beneath each control's heading is the same four-field strip used throughout this site: the governing policy or standard, the window, the layer, and the authority the other three were read from. For controls, the governing field frequently names a published technical standard rather than a consensus policy — several of these mechanisms are protocol features rather than contractual obligations, and the distinction matters, because a protocol feature is available only where a registry or provider has chosen to implement it.
Where no consensus policy governs a control, the strip says so rather than leaving the field blank or implying a rule. The window field, for a control, is usually a propagation or verification interval — the period during which a change is not yet in effect everywhere, or during which a release request is held. Those intervals are the difference between a control that is configured and a control that is actually protecting anything, and they are the part most often skipped.
What this category is not
It is not a product comparison. Where a control is offered by some providers and not others, that is described as a structural fact about the mechanism rather than as a recommendation, and no provider is rated. It is not an implementation manual: the specific steps vary by provider and by registry and would be stale almost immediately, so the entries describe what the control is, where it sits, and what has to be true for it to work. And it is not a services page — nothing here is for sale and no engagement is taken through this site.
How to read this index
If you are hardening a portfolio rather than responding to an incident, read by layer from the top down: the registry-level controls first, because they are the ones an account compromise cannot undo, then the registrar-level controls that govern the account itself, then the DNS-layer controls that constrain resolution and issuance. That order matches the order in which a failure becomes unrecoverable.
If you arrived here from an incident, follow the cross-links the other way. Each control names the failures it bears on, and each incident names the controls that would have changed its outcome. The portfolio security guide walks the same ground in the order you would actually do the work.