Every entry in this category describes a way that control of a domain name is lost. Not a threat in the abstract, and not a ranking of what is most dangerous: a specific failure mode, described from the record it changes. Some of them move the registration itself. Some leave the registration untouched and change what the name resolves to. One is not an attack at all — it is a calendar running out. And three are not failures of security in any technical sense, but disagreements about who was entitled to register the name in the first place.
Why these are grouped by layer, not by severity
A severity ranking would be the obvious way to organize this material and it would be close to useless. The severity of losing a domain name depends almost entirely on what the name is doing: the same unauthorized change is an inconvenience on a parked name and an emergency on the name that carries a company's mail. What does not vary is the layer the change happened on, and that is what determines everything you can actually act on — who holds the authoritative record, who is able to alter it, which policy governs the alteration, and how long the route back stays open.
So the entries are grouped into four disciplines. Theft and hijacking covers losses that move or alter the registration record: the sponsoring registrar changes, or the registrant does, or the account that controls both is no longer controlled by the person named in it. DNS-layer attacks covers losses where the registration is entirely intact and correct, and resolution has been subverted anyway — the delegation, the zone, or a record inside it. Expiry and lifecycle covers the one case where nobody did anything wrong except miss a date. Disputes and bad-faith registration covers names that were registered by someone else, lawfully at the registry, in circumstances a policy exists to unwind.
The three-word field at the top of every entry
Each incident page opens with a status before any prose: recoverable, disputed, or time-critical. That is a deliberate editorial commitment and it is the single most useful thing this site can tell someone who has arrived in the middle of an incident. Reference material in this field has a persistent habit of describing a mechanism for nine hundred words before telling you whether you are in a situation with a remedy, a situation that will be argued, or a situation with a deadline already running.
Recoverable means a defined route back exists and the mechanism is understood. It does not mean easy, cheap, or certain — it means the path is not in dispute. Disputed means the outcome turns on an adjudication rather than on a procedure: the name is held lawfully at the registry until a panel or a court says otherwise, and the route to it is adversarial by design. Time-critical means the useful actions and the useful evidence both decay quickly, and you should be doing something before you finish the page.
The same field appears as a chip on every card in this index, so the category can be scanned without opening anything. It is one field driving three surfaces, which is what keeps it honest — a status that only appeared in one place would drift.
What the docket strip under each heading is for
Directly beneath the heading of every entry is a strip carrying up to four values: the governing policy, the window, the layer, and the authority. This is the part of a security reference that is usually missing, and its absence is why so much writing in this field cannot be acted on.
The governing policy names the instrument that actually decides the question — a consensus policy, a registry service description, a published standard, or, in a few cases, an explicit statement that no consensus policy exists and practice varies by provider. That last case is not a gap in the research; it is the finding, and saying so plainly is more useful than implying a rule that nobody is bound by. The window names the clock: the period inside which a route stays open, a response is due, or a change can still be reversed. The layer names where the control point sits. The authority cites the document the other three came from, so you can check them rather than take them on trust.
What is not here
This category does not cover registrar-specific procedures, because they vary by provider and change without notice, and a reference that recorded them would be wrong within a year while still reading as authoritative. It does not rank providers or recommend products. It does not carry legal advice: several of these entries describe policies administered by dispute-resolution providers and enforced through counsel, and the correct response to most of them includes retaining a lawyer.
It also does not describe any engagement, matter or client. Domain recovery work is confidential and a great deal of it is pre-litigation. What can be described is the mechanism — what the policy says, what the clock is, what the record shows, and where the process reliably goes wrong — and that is what these entries do.
How to read this index
If something is happening right now, start from the status chip and find the entry that matches your situation, then follow it into the recovery guides rather than reading sideways across the category. If you are reading to understand the field rather than to solve a problem, the disciplines are the better order: theft first, because it is the case everything else is measured against, then the DNS layer, then lifecycle, then disputes, which are a different kind of problem wearing similar vocabulary.
Each entry cross-links to the controls that bear on it. That pairing is the point of splitting the site into two categories: an incident is only half of the subject, and the useful question is almost never "what is this attack called" but "what would have stopped it, and at which layer". The controls index answers the second half.