How-to

Registrar Locks, DNSSEC and security.txt: A Domain Hygiene Checklist

Published September 29, 2026 · 8 min read · By the Attack Surface Scan team

TL;DR

Most domain security advice is about what the domain points at. This checklist is about the registration itself, where a single support ticket can undo everything else. Turn on the three client locks (clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited), and ask about registry lock for domains that would hurt to lose. Treat broken DNSSEC (a DS record with signatures that do not validate) as an outage, and missing DNSSEC as a hardening item. Publish /.well-known/security.txt per RFC 9116, and remember its Expires field is required. Then watch all of it, because locks get removed for a transfer and never put back.

Why registration hygiene matters

A domain hijack does not need access to your servers. Whoever controls the registration controls the nameservers, and whoever controls the nameservers controls where your website, API and mail go. The CoW Swap incident in April 2026 is a clean example: attackers took over the domain through the registration process, changed DNS and served a malicious clone, with the backend never touched. The controls in this checklist are the ones that make that kind of takeover slow, noisy or impossible.

1. Registrar locks (EPP status codes)

Registries and registrars communicate through EPP, and a domain's EPP status codes are public: you can read them through RDAP, the structured successor to WHOIS. ICANN's guide to EPP status codes explains each. The three that matter for security are set by your registrar at your request:

Status	What it does	Why you want it
`clientTransferProhibited`	Tells the registry to reject transfers to another registrar	The main defense against a domain being moved away through a compromised registrar account or a social-engineered request
`clientUpdateProhibited`	Tells the registry to reject updates to the domain	Stops nameserver and contact changes without an extra unlock step
`clientDeleteProhibited`	Tells the registry to reject deletion	Stops accidental or malicious deletion

Why the transfer lock matters most. Once a domain has moved to a registrar the attacker controls, getting it back means a dispute between registrars that can take a day or more, and meanwhile your DNS answers for them. A transfer lock does not make that impossible (someone with your registrar account can remove it), but it adds a step, and the step is visible.

Registry lock goes further. The corresponding server*Prohibited statuses are set by the registry, not the registrar, and ICANN notes that server codes take precedence over client codes. Some registries sell registry lock services that set them at the registrant's request, and removing them typically requires an out-of-band confirmation between the registrar and the registry. For a primary brand or payments domain, that is worth paying for.

Caveats. Some country-code registries do not support client locks at all, and some registrars apply locks by default while others do not. Check the actual RDAP status rather than the registrar's dashboard wording ("Domain Lock", "Transfer Lock" and "Registrar Lock" often mean only the transfer lock).

2. Watch for lock changes, not just lock state

The common failure is not a domain that was never locked. It is a lock removed for a legitimate transfer, a registrar migration or a DNS change, and never reapplied. A one-time audit misses this. What you want is a change alert: a transfer lock disappearing is either planned work or the first step of a hijack, and you want to know which on the day it happens.

Attack Surface Scan reads lock status from RDAP on apex scans and nightly. It raises dns.transfer-lock-missing (medium), dns.update-lock-missing (low) and dns.delete-lock-missing (low), treats a registry-side server*Prohibited lock as locked, and records every change as domain.lock_changed: critical when the transfer lock is removed, so it is sent to your alert channels immediately. Registration expiry is read from RDAP too, with warnings at 60, 30, 14 and 7 days, because an expired domain is the simplest hijack of all (see how expired domains get resold).

3. DNSSEC: missing versus broken

DNSSEC lets resolvers verify that DNS answers were signed by the zone's owner. A parent zone publishes a DS record that anchors your zone's keys; validating resolvers follow that chain and reject answers that do not verify. The two failure states are very different:

Missing (no DS record at the parent): the zone is unsigned. Resolvers cannot detect forged answers, but everything resolves. This is a hardening item, and whether it is worth doing depends on your DNS provider's support and your appetite for key management.
Broken (a DS record exists but validation fails): validating resolvers treat the answers as bogus and return a failure. For every user behind one, which includes the large public resolvers, your domain simply stops resolving. This is an outage, and it is usually self-inflicted: a move to a new DNS provider that left the old DS record at the registrar.

Checking this correctly means asking a validating resolver, then confirming that the same query succeeds with checking disabled (so the failure really is validation, not a down nameserver). Attack Surface Scan does exactly that through Google and Cloudflare DNS-over-HTTPS, and only raises dns.dnssec-broken (high) when a second resolver confirms it, so a resolver hiccup never reads as broken DNSSEC. dns.dnssec-missing is low. Full detail is on Domain registration hygiene.

The provider-move rule: when changing DNS providers on a signed zone, either move the keys properly or remove the DS record at the registrar first and wait for its TTL to expire. Never change nameservers while a DS record points at keys the new provider does not have.

4. security.txt, per RFC 9116

RFC 9116 defines a small text file at /.well-known/security.txt that tells a researcher how to report a vulnerability to you. It must be served over HTTPS, and exactly two fields are required:

Contact: an email address (as a mailto: URI), a web form or a phone number.
Expires: the date after which the file's contents should be considered stale. It must appear exactly once, and the RFC recommends keeping it less than a year in the future.

Contact: mailto:security@example.com
Expires: 2027-09-01T00:00:00Z
Policy: https://example.com/security-policy
Preferred-Languages: en

The Expires field is where most files go wrong. A file published two years ago with a one-year expiry is telling researchers not to trust it, and the RFC itself says that having no file may be preferable to having stale information. Put the renewal in the same calendar as your certificate and domain renewals.

Attack Surface Scan checks the apex for headers.missing-security-txt (info) and headers.security-txt-expired (low), which fires when Expires has passed, is missing or cannot be parsed. CIS Controls v8 safeguard 16.2 asks for a way for external parties to report vulnerabilities, and this file is the standard way to provide one.

5. Everything else on the checklist

Registrar sprawl. Domains spread across several registrars, some on a former employee's card, are how renewals and locks get missed. Consolidate, and put renewals on a company account with more than one admin.
Registrar account security. Locks can be removed by anyone who can sign in: use strong multi-factor authentication and restrict who has access.
CAA records to limit which CAs can issue for the domain, and SPF, DKIM and DMARC to stop spoofing.
Dangling records from decommissioned services (subdomain takeover).
Weak certificate signatures. A leaf certificate signed with SHA-1 or MD5 on a public host is usually an old appliance nobody has looked at in years.

The checklist

Transfer, update and delete locks on every registrable domain; registry lock on the ones that matter most.
An alert when any lock is removed, and when registration expiry approaches.
DNSSEC either working or deliberately off; never a stale DS record.
/.well-known/security.txt with Contact and a future Expires, renewed on a schedule.
Registrations consolidated, on a company account with MFA.

Every one of these is visible from public data, which means an attacker can check them too. Registration checks run on every plan.

Frequently asked questions

What does clientTransferProhibited mean?

It is an EPP status code, set by your registrar, that tells the registry to reject any request to transfer the domain to another registrar. It is what most registrars call "domain lock" or "transfer lock", and it is the main safeguard against a domain being moved away through a compromised account or a social-engineered request.

What is the difference between a registrar lock and a registry lock?

A registrar lock uses the client*Prohibited statuses, which your registrar sets and can remove when you (or someone with your account) ask. A registry lock uses the server*Prohibited statuses set by the registry itself, which take precedence and typically need an out-of-band confirmation to remove. Registry lock is a paid service offered by some registries and registrars.

Is missing DNSSEC a vulnerability?

It is a missing hardening control rather than an open hole: resolvers cannot detect forged answers, but the domain works. Broken DNSSEC is far more urgent, because validating resolvers refuse to resolve the domain at all.

Is the Expires field in security.txt required?

Yes. RFC 9116 makes Contact and Expires the only required fields, and Expires must appear exactly once. The RFC recommends setting it less than a year in the future so the file does not go stale.

Sources

Get told the day a lock comes off

Attack Surface Scan reads your registrar locks, registration expiry, DNSSEC and security.txt from public data, and sends a critical alert when a transfer lock is removed. 7-day trial, no card required.

Start your 7-day trial