Resources · 17

Govern domains and rehearse DNS recovery

Inventory domains, protect registrar access and test recovery of naming services.

Updated 7 November 2026 · 17 min

What this guide helps achieve

Identify holders and renewal dates
Protect access and transfers
Validate delegation
Rehearse DNS recovery

Quick check

Who holds each critical domain?
Is expiry monitored?
Who can change name servers?
Does DNSSEC validate after a change?
Are crisis contacts reachable outside the affected domain?

Step-by-step method

01
Inventory assets
List domains, critical subdomains, registrars, DNS providers, holders, business owners, renewal dates and dependent services.
Deliverable: owned and dated register.
02
Protect accounts
Review registrar accounts, multifactor authentication, recovery methods and rights to transfer or change domains. Assess available locks.
Deliverable: access and protection matrix.
03
Control changes
Record requests, approvals, change windows, prior state and checks after publication. Prepare rollback.
Deliverable: zone and delegation change procedure.
04
Validate resolution
Check authoritative servers, critical records and DNSSEC validation where enabled from several networks. Watch for delegation errors.
Deliverable: resolution and validation record.
05
Rehearse recovery
Simulate a faulty delegation or loss of provider access. Use out-of-band contacts and rehearse restoration in a controlled setting.
Deliverable: exercise report with times and blockers.
06
Maintain ownership
Review the register after transfers, provider changes, new services and administrator departures.
Deliverable: review schedule and decision log.

Management indicators

Indicator	What it measures	First action
Register coverage	Critical domains with verified holder and owner	Resolve orphaned assets
Protected access	Sensitive accounts checked and strongly authenticated	Reduce excess rights and weak recovery methods
DNS validation	Changes followed by resolution checks	Fix delegation and signing issues
Recovery time	Duration observed in an exercise	Remove blocking dependencies

Common pitfalls

Inventorying only the main domain
Equating a registrar lock with DNS availability
Changing DNSSEC without checking validation
Relying on an email address at the failed domain to recover an account

Frequently asked questions

Is a transfer lock enough?

No. It reduces some unauthorised changes, but registrar access, DNS zones and account recovery also need controls.

Does DNSSEC replace monitoring?

No. It checks signed answer integrity when validation is enabled; availability, delegation and changes still need monitoring.

When should recovery be repeated?

After significant changes to registrars, DNS providers, delegation or owners, and at a frequency suited to service criticality.

References: data, uses and limitations

Documentation reviewed on 2026-10-22.

References: data, uses and limitations
Source and purpose	Verified data or benchmark	How to use it	Limitation to retain
ICANN · Registration Data Lookup Consult available domain registration information.	RDAP is the registration data access protocol. ICANN Lookup provides access to available public registration data.	Keep the exact domain, consultation date and result. Distinguish registrar, technical service and the entity operating a website. Explore the method →	Data may be redacted or limited. Domain information alone cannot attribute content or an operation to a person.

Email security: identity, alignment and transport

Domain authentication, transport confidentiality and inbox placement are different questions. SPF, DKIM and DMARC inform domain identity; MTA-STS and DANE concern server-to-server connections; reports help observe failures. None of these signals proves a message is benign.

References and status checked on 2026-10-22.

Which mechanism answers which question?

Which mechanism answers which question?
Mechanism and source	What is checked	Where to find evidence	Limit to retain
SPF SPF · RFC 7208	Authorisation of the sending IP for the SMTP envelope domain; DMARC uses MAIL FROM.	The evaluated domain’s TXT record and receiver result. Evaluation allows 10 DNS-querying terms, rather than simply 10 network requests.	Forwarding may change the observed IP. Selecting multiple SPF records produces permerror; an SPF pass does not prove alignment with From.
DKIM DKIM · RFC 6376 DKIM cryptography · RFC 8301	Cryptographic verification of signed message parts for the signature’s d= domain.	DKIM-Signature, selector s=, domain d= and key under selector._domainkey. RFC 8301 requires RSA ≥ 1,024 bits, recommends ≥ 2,048 bits and excludes rsa-sha1.	A valid signature from another domain may not satisfy DMARC. Changes to signed parts can break verification; DKIM does not encrypt the message.
DMARC DMARC · RFC 9989	Links the visible From domain to at least one SPF- or DKIM-authenticated, aligned identifier.	The TXT policy discovered through _dmarc and trustworthy results produced at reception. Record alignment mode and the domain actually evaluated.	A pass neither guarantees delivery nor endorses content. Receivers retain local policy; DNS errors and non-conforming messages require separate handling.
DMARC aggregate / failure reports DMARC aggregate reports · RFC 9990 DMARC failure reports · RFC 9991	Observation of streams using the domain: aggregate statistics and, separately, details about failing messages.	rua / ruf destinations, covered period and received reports. Their formats are now specified in separate RFCs published in May 2026.	Missing reports do not prove no mail was sent. Detailed reports may expose message data; define suitable access, minimisation and retention.
MTA-STS MTA-STS · RFC 8461	Recipient-domain policy for SMTP TLS transport and expected MX hosts.	_mta-sts TXT, HTTPS policy at /.well-known/mta-sts.txt and certificate. Three modes: testing, enforce and none.	Applies to supporting servers and transport, without end-to-end encryption. Initial discovery and caching have their own limits.
TLS-RPT SMTP TLS Reporting · RFC 8460	Reporting of successful and failed TLS negotiation or validation between servers.	_smtp._tls TXT, reporting destinations and received JSON data, correlated with transport logs.	Observation does not enforce encryption. TLS reports and DMARC domain-identity reports describe different events.
DANE for SMTP DANE for SMTP · RFC 7672	TLS transport authentication using DNSSEC-protected TLSA records.	Validated DNSSEC chain, SMTP service TLSA record and a match with the presented certificate or key.	DNSSEC validation is required on this path. DANE does not validate From or replace SPF, DKIM and DMARC.
ARC ARC · RFC 8617	Carries authentication assessments along paths involving intermediaries.	ARC header sets, chain validation and a trust decision about intermediaries.	RFC 8617 is Experimental. ARC is not a trust framework and does not automatically make a message safe or deliverable.

DMARC in 2026: documentation changes

Reference: RFC 9989, published in May 2026, replaces RFC 7489 and RFC 9091. Aggregate and failure reporting are separated into RFC 9990 and RFC 9991.
Discovery and alignment: The specification defines DNS Tree Walk discovery. Do not infer organisational domains by naively retaining the final two labels.
Testing a deployment: pct is removed; the new t=y requests handling one level below the published failure policy: reject becomes quarantine, and quarantine becomes none. t=n is the default.
Interoperability: The standard advises against p=reject for general-purpose email domains. Inventory forwarding and mailing lists and check actual implementations before changing policy.

Publication of an RFC does not show that every provider already implements that version. Check documentation, observed results and exceptions in your own streams. These examples are educational and provide no ready-to-deploy DNS record. RFC 9989 →

Understand DMARC logic with a scenario

Simplified model: a conforming From message, an already discovered DMARC policy, one SPF MAIL FROM result and one examined DKIM signature. You supply alignment based on the evaluated domains and mode. The tool performs no DNS resolution or signature verification and predicts no delivery.

(SPF pass AND aligned) OR (DKIM pass AND aligned)

With multiple DKIM signatures, check each result / d= pair: one valid, aligned signature can suffice. Never combine one signature’s pass with an aligned domain from another failing signature. DNS discovery errors, absent policy and invalid From fields are outside this model. All choices stay in your browser.

Six educational cases, readable without JavaScript

Six educational cases, readable without JavaScript
Scenario	SPF: result / alignment	DKIM: result / alignment	Expected interpretation
Aligned SPF is sufficient	pass — authenticated Yes	fail — observed failure No	pass — at least one authenticated and aligned path The SPF path meets both conditions.
Aligned DKIM is sufficient	fail — observed failure No	pass — authenticated Yes	pass — at least one authenticated and aligned path The DKIM path meets both conditions independently of the other path in this model.
Two passes without alignment	pass — authenticated No	pass — authenticated No	fail — no authenticated and aligned path in this scenario Two third-party domains passing technically does not validate From.
Aligned domains, no authentication	fail — observed failure Yes	fail — observed failure Yes	fail — no authenticated and aligned path in this scenario A matching domain does not replace successful authentication.
Incomplete evidence	Result not supplied Alignment not supplied	fail — observed failure No	Undetermined — complete the observations Missing evidence on one path cannot be invented.
Proven DKIM, unknown SPF	Result not supplied Alignment not supplied	pass — authenticated Yes	pass — at least one authenticated and aligned path One complete positive result suffices even when the other path is unknown.

Prepare an actionable email review

Prepare an actionable email review
Stream	Evidence to correlate	Useful decision
Alerts, receipts and resets	Provider and From domain, envelope and DKIM identities, tracking ID, SMTP response and available delivery event.	Separate transport failure, authentication error and absence of reading. Define an alternative for a critical service.
Campaigns and newsletters	Domains and subdomains, alignment results, representative samples from every platform, withdrawal mechanism and stream-specific errors.	Repair the affected sending path before changing a global policy; do not equate authentication with recipient expectations.
Forwarding and mailing lists	Path before and after the intermediary, message changes, SPF/DKIM outcomes and ARC information when present.	Explain the observed break and local policy; do not assume a valid ARC chain compels acceptance.
Transport to MX hosts	Relevant MTA-STS policy or TLSA, certificates, DNSSEC validation for DANE, TLS reports and timestamped logs.	Associate failures with the relevant host and period. Test changes within authorised scope and retain rollback.

Continue with domain and DNS governance →

Primary sources and publication dates

Dates below identify RFC publication months, separately from the consultation date. Descriptions and cases are editorial summaries rather than complete normative extracts.

SPF · RFC 7208 · Proposed Standard · Publication : 2014-04
§3.2, §4.5, §4.6.4
DKIM · RFC 6376 · Internet Standard · Publication : 2011-09
§3, §6
DKIM cryptography · RFC 8301 · Proposed Standard · Publication : 2018-01
§3.1–3.2
DMARC · RFC 9989 · Proposed Standard · Publication : 2026-05
§4.4, §4.7, §4.10, §5.3.5, §5.4, appendix C
DMARC aggregate reports · RFC 9990 · Proposed Standard · Publication : 2026-05
§2–3
DMARC failure reports · RFC 9991 · Proposed Standard · Publication : 2026-05
§2–3; privacy considerations
MTA-STS · RFC 8461 · Proposed Standard · Publication : 2018-09
§3, §5, §10.2
SMTP TLS Reporting · RFC 8460 · Proposed Standard · Publication : 2018-09
§3–4
DANE for SMTP · RFC 7672 · Proposed Standard · Publication : 2015-10
§2, §3
ARC · RFC 8617 · Experimental · Publication : 2019-07
§2, §7, appendix A.2

security.txt and disclosure

Preserve contact scope when domains change

A migration, provider delegation or subdomain change can make a disclosure channel ambiguous. Domain governance should therefore include publication and review of security.txt.

Check each relevant host: a parent domain’s file does not automatically apply to its subdomains.
Compare Canonical URIs with actual retrieval and document provider redirects.
Review contacts, keys, policy and expiry when responsibility transfers; preserve older versions as history.

Read the security.txt reference and disclosure cases →

Sources checked on 2026-10-22 · IETF · RFC 9116 · §2.5, §3, §5

DNSSEC: distinguish signatures, delegation and caching

A DNSSEC signature authenticates DNS data through a chain of trust; it does not encrypt queries or certify the legal identity of a website operator. For a decision, distinguish observed data, the resolver obtaining it, the trust anchor and the checks actually performed.

Two IANA registries are included in a snapshot reviewed on 23 October 2026: 27 algorithm rows and 11 DS digest rows. Each code space runs from 0 to 255. Reserved and unassigned ranges remain present; 38 rows therefore do not mean 38 usable algorithms. Descriptions, ranges and four recommendation columns retain registry values.

One chain of trust, several checks

Starting point
A trust anchor configured and approved under validator policy.
Parent side
Authenticate parent keys, then the signature on the parent’s delegation DS RRset.
Matching
Match the DS digest to the corresponding child DNSKEY and authenticate the child DNSKEY RRset.
Requested data
Verify the RRSIG covering the requested RRset: names, class, covered type, keys and time interval.
Cache
Once the RRset is accepted as authentic, apply the TTL upper bound described in RFC 4035, among other checks.

Simplified learning diagram: multiple keys, signatures and denial-of-existence proofs can be involved. A DS is a key digest, not a signature of that key. Preserve each check’s scope.

Which fields must be connected before drawing a conclusion?

Which fields must be connected before drawing a conclusion?
Field	Useful interpretation	What it does not prove
DNSKEY · Flags	Key-role flags. Values 256 and 257 are not key sizes.	Their presence proves neither private-key protection nor chain validity.
DNSKEY · Protocol	RFC 4034 defines the value as 3.	This is not a TLS version.
DNSKEY / DS · Algorithm	Key algorithm identifier in DNS Security Algorithm Numbers.	The same number in Digest Type has a different meaning.
DS / RRSIG · Key Tag	A 16-bit value helping select candidate keys.	Key Tag is not unique: distinct keys can share that number.
DS · Digest Type / Digest	Digest selector and digest used to match a DNSKEY under the specified format.	Comparing only Key Tag and Algorithm verifies neither digest nor authenticity.
RRSIG · Inception / Expiration	Signature time bounds, distinct from TTL. Raw fields use 32-bit serial arithmetic.	A readable date or accurate clock does not replace cryptographic verification.
RRSIG · Original TTL	Signed value used to reconstruct data and bound caching.	A received TTL may already have decreased; it never extends the signature.

Read two code spaces and four separate recommendations

A DS key algorithm number and digest type are different fields. Use columns concern operational use; Implement concerns implementation support. Signing or Delegation is distinct from Validation. RFC 9904 replaces RFC 8624 for maintaining these recommendations and refers to the IANA registries.

An empty cell becomes “not specified”, never MAY by default. An IANA recommendation demonstrates neither software-version support nor a domain’s status. Draft references remain labelled as drafts. Assigning a number, including for ML-DSA-44, does not turn its DNSSEC reference into a final RFC or prove operational compatibility.

Documentary example: signature code 5 (RSA/SHA-1) has MUST NOT for Use for DNSSEC Signing and RECOMMENDED for Use for DNSSEC Validation in this snapshot. Do not collapse these columns into one green or red indicator. Examine the actual resolver policy and version separately.

These two integers are not domain names. The filter finds a row or range in each registry without DNS queries. It calculates no digest and validates no DS record.

Visible rows : 38 / 38

DNS Security Algorithm Numbers

IANA · 2026-08-10 · 27 Visible rows

DNS Security Algorithm Numbers · 2026-10-23
Code / description	Operational use · Use	Software support · Implement	References and scope
`0` Delete DS DELETE	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	Zone Signing: `N` rfc4034 proposed standard rfc4398 proposed standard rfc8078 proposed standard
`1` RSA/MD5 (DEPRECATED, see 5) RSAMD5	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `N` rfc3110 proposed standard rfc4034 proposed standard
`2` Diffie-Hellman DH	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	Zone Signing: `N` rfc2539 proposed standard
`3` DSA/SHA1 DSA	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc3755 proposed standard rfc2536 proposed standard Federal Information Processing Standards Publication (FIPS PUB) 186, Digital Signature Standard, 18 May 1994. Federal Information Processing Standards Publication (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. (Supersedes FIPS PUB 180 dated 11 May 1993.)
`4` Reserved	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc6725 proposed standard
`5` RSA/SHA-1 RSASHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc3110 proposed standard rfc4034 proposed standard rfc9905
`6` DSA-NSEC3-SHA1 DSA-NSEC3-SHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc5155 proposed standard
`7` RSASHA1-NSEC3-SHA1 RSASHA1-NSEC3-SHA1	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5155 proposed standard rfc9905
`8` RSA/SHA-256 RSASHA256	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MUST Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5702 proposed standard
`9` Reserved	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc6725 proposed standard
`10` RSA/SHA-512 RSASHA512	Use for DNSSEC Signing NOT RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing NOT RECOMMENDED Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc5702 proposed standard
`11` Reserved	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc6725 proposed standard
`12` GOST R 34.10-2001 (DEPRECATED) ECC-GOST	Use for DNSSEC Signing MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Signing MUST NOT Implement for DNSSEC Validation MUST NOT	Zone Signing: `Y` rfc5933 proposed standard https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic rfc9906
`13` ECDSA Curve P-256 with SHA-256 ECDSAP256SHA256	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MUST Implement for DNSSEC Validation MUST	Zone Signing: `Y` rfc6605 proposed standard
`14` ECDSA Curve P-384 with SHA-384 ECDSAP384SHA384	Use for DNSSEC Signing MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc6605 proposed standard
`15` Ed25519 ED25519	Use for DNSSEC Signing RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing RECOMMENDED Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc8080 proposed standard
`16` Ed448 ED448	Use for DNSSEC Signing MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation RECOMMENDED	Zone Signing: `Y` rfc8080 proposed standard
`17` SM2 signing algorithm with SM3 hashing algorithm SM2SM3	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc9563 informational
`18` ML-DSA-44 MLDSA44	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` draft-westerbaan-dnssec-mldsa-03 · Internet-Draft informational
`19-22` Unassigned	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry
`23` GOST R 34.10-2012 ECC-GOST12	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc9558 informational
`24-122` Unassigned	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry
`123-251` Reserved	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc4034 proposed standard rfc6014 proposed standard
`252` Reserved for Indirect Keys INDIRECT	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	Zone Signing: `N` rfc4034 proposed standard
`253` private algorithm PRIVATEDNS	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc4034 proposed standard
`254` private algorithm OID PRIVATEOID	Use for DNSSEC Signing MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Signing MAY Implement for DNSSEC Validation MAY	Zone Signing: `Y` rfc4034 proposed standard
`255` Reserved	Use for DNSSEC Signing Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Signing Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc4034 proposed standard

Source XML SHA-256: 5809e908acadd1113f2a877d14c83ecddd9621baa6d55dcecf7203e8d972aa15

Digest Algorithms

IANA · 2026-01-13 · 11 Visible rows

Digest Algorithms · 2026-10-23
Code / description	Operational use · Use	Software support · Implement	References and scope
`0` Reserved	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST NOT	rfc3658
`1` SHA-1	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST	rfc3658 rfc9905
`2` SHA-256	Use for DNSSEC Delegation RECOMMENDED Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MUST Implement for DNSSEC Validation MUST	rfc4509
`3` GOST R 34.11-94 (DEPRECATED)	Use for DNSSEC Delegation MUST NOT Use for DNSSEC Validation MUST NOT	Implement for DNSSEC Delegation MUST NOT Implement for DNSSEC Validation MUST NOT	rfc5933 https://datatracker.ietf.org/doc/status-change-gost-dnssec-to-historic rfc9906
`4` SHA-384	Use for DNSSEC Delegation MAY Use for DNSSEC Validation RECOMMENDED	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation RECOMMENDED	rfc6605
`5` GOST R 34.11-2012	Use for DNSSEC Delegation MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation MAY	rfc9558
`6` SM3	Use for DNSSEC Delegation MAY Use for DNSSEC Validation MAY	Implement for DNSSEC Delegation MAY Implement for DNSSEC Validation MAY	rfc9563
`7-127` Unassigned	Use for DNSSEC Delegation Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Delegation Not specified in this registry Implement for DNSSEC Validation Not specified in this registry
`128-252` Reserved	Use for DNSSEC Delegation Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Delegation Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc9904
`253-254` Reserved for Private Use	Use for DNSSEC Delegation Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Delegation Not specified in this registry Implement for DNSSEC Validation Not specified in this registry	rfc9904
`255` Unassigned	Use for DNSSEC Delegation Not specified in this registry Use for DNSSEC Validation Not specified in this registry	Implement for DNSSEC Delegation Not specified in this registry Implement for DNSSEC Validation Not specified in this registry

Source XML SHA-256: 87e51021198e634d4d960d339fbd307be71014616ef2f5a0273096a5cea260e8

Interpret a status without inventing attribution

Interpret a status without inventing attribution
Conceptual status	Interpretation	Conclusion limit
Secure	Chain and signatures authenticated under validator anchors and policy.	Does not establish truthful web content or a legitimate organisation.
Insecure	No known authenticatable chain in the described context.	Does not automatically mean an attack or absence of application transport encryption.
Bogus	A chain should be verifiable, but a check or required data fails.	Can result from error, corruption or attack; investigate the cause.
Indeterminate	Available information cannot determine whether a chain is expected.	Missing data must not be relabelled successful validation.

The AD bit conveys the answering resolver’s assertion. A client should rely on delegated validation only through a trusted resolver and an appropriate channel. Record resolver, time and query settings; a single response does not describe every vantage point.

Model a cache lifetime upper bound

This calculation applies only the cache upper bound in RFC 4035 §5.3.3, under the explicit assumption of an already authenticated RRset. It takes the minimum of both received TTLs, Original TTL and remaining lifetime. Time offsets are seconds from one shared observation instant: negative means past, positive means future.

Calculated upper bound under the stated assumption : 1800 seconds

This is an upper bound, not a mandatory cache lifetime or worldwide propagation delay. Local policy may retain data for less time. The tool verifies no signature, digest or delegation and assigns no Secure/Bogus status. No input is transmitted.

Fictional calculation cases, checkable without the tool

Fictional calculation cases, checkable without the tool
Assumption	Inputs: RRset / RRSIG / Original / Inception Δ / Expiration Δ (s)	Model result
Expiration is limiting	3600 / 7200 / 86400 / -7200 / 1800	1,800 s
Received TTL is limiting	300 / 7200 / 86400 / -7200 / 1800	300 s
Original TTL is limiting	3600 / 7200 / 60 / -7200 / 1800	60 s
Expiration at observation time	3600 / 7200 / 86400 / -7200 / 0	0 s
Signature not yet applicable	3600 / 7200 / 86400 / 60 / 1800	Not calculated: future inception
Signature already expired	3600 / 7200 / 86400 / -7200 / -1	Not calculated: past expiration
Zero TTL	0 / 7200 / 86400 / -7200 / 1800	0 s

For the first case: min(3,600, 7,200, 86,400, 1,800) = 1,800 seconds, or 30 minutes. Inception is already in the past. This describes fictional inputs, not a real domain or resolver.

Questions for a domain review

Does DNSSEC replace HTTPS or operator verification?

DNSSEC concerns DNS data authenticity and integrity. Application transport, certificates and operator identity answer different questions. Keep that evidence separate.

Why can two resolvers yield different observations?

Caches, time, policy, versions and data availability may differ. Compare dated observations and methods rather than merging them into a global result without analysis.

Does TTL tell when every visitor will see a change?

TTL bounds retention in a particular context. Caches, prior state and other dependencies prevent deriving a worldwide changeover time.

Protocol registry data: IANA / IETF, CC0 1.0, terms reviewed on 23 October 2026. CIE extraction includes DNS Security Algorithm Numbers and DS Digest Algorithms only, preserving ranges and missing values. Linked RFCs and other documents retain their own terms; no institutional logo is reproduced. Diagram, questions and numeric cases are CIE editorial work.

IANA · DNS Security Algorithm Numbers · Registry updated 2026-08-10
IANA · DS Digest Algorithms · Registry updated 2026-01-13
IETF · RFC 9904 · DNSSEC algorithm recommendation process · 2025-11 · replaces RFC 8624 · §2.1
IETF · RFC 4033 · DNSSEC introduction and requirements · 2005-03 · §2–5, §8.1
IETF · RFC 4034 · DNSSEC resource records · 2005-03 · §2–5, Appendix B · current algorithm status in IANA
IETF · RFC 4035 · DNSSEC validation and caching · 2005-03 · §4.3, §4.9.3, §5.3.1, §5.3.3
IETF · RFC 2181 · Time to Live · 1997-07 · §8
IANA / IETF · Protocol registry licensing terms · 2021-11-10 · CC0 1.0 for protocol registries; linked RFCs excluded

TLS certificates and open-source intelligence

Public certificates and domain inventories

A CT entry can reveal a name declared in a certificate. It supplements inventory without replacing registration data or dated DNS and TLS observations.

Retain the exact name and certificate fingerprint.
Distinguish named domains, wildcard patterns and actually observed hosts.
Review ownership and availability independently of CT history.

Read the CT dossier and dated log list →

Google Chrome · Certificate Transparency for Site Operators · Domain Privacy · consulted 2026-10-23

RDAP: registration, roles and redacted data

RDAP provides structured registration data for domains and Internet resources. In a domain review or OSINT investigation, a response is a registry observation obtained at a particular time and access level. Corroborate it with other evidence before drawing conclusions about an operator or organisation.

This dossier examines domain-class objects. The IANA vocabulary covers three cross-resource categories: 36 statuses, 12 event actions and 11 roles, or 59 values. Some also concern IP addresses or Autonomous System numbers; not all apply to domains. Snapshot checked on 23 October 2026; registry updated on 4 June 2025.

Who does what in an RDAP response?

Who does what in an RDAP response?
Actor or layer	Role to examine	Conclusion to avoid
Registry	Registration database for a namespace or resource space; identify the source used for the observation.	Treating the registry as the company publishing the website.
Registrar	Entity carrying the registrar role in the object’s context. A reseller may be represented separately.	Mistaking the registrar’s name for the registrant’s name.
Registrant	Entity designated as the registration holder; available data depends on the response and access rules.	Concluding there is no registrant because no contact is visible.
Contacts, proxy and suppliers	Read technical, administrative, abuse, proxy and reseller roles separately.	Turning a technical contact, proxy or supplier into a certain publisher identity.
DNS, TLS and hosting	Other dated technical observations to correlate; RDAP does not replace them.	Inferring a host, live service or editorial control from one registration datum.

IETF · RFC 9083 · RDAP JSON Responses · June 2021 · §§4–5, 9–10

Fictional empty cross-connect cabinet with amber and black cables beside a dark equipment aisle — Fictional empty cross-connect cabinet. This infrastructure illustration represents no real registrar, registrant or facility: technical relationships alone do not establish identity.

Four dates answer four different questions

Four dates answer four different questions
eventAction	Documentary meaning	Precaution
registration	Initial registration of the object according to the source.	Does not date company formation or the website’s first publication.
last changed	Last change to information in the object.	Does not alone demonstrate a transfer or change of registrant.
last update of RDAP database	Last synchronisation of the object’s information from the authoritative database.	Neither last changed nor the time you queried the service.
expiration / registrar expiration	Object expiry in the registry, or in the registrar’s system for registrar expiration.	Retain the exact label; an expiry value is not a promise that the domain will become available for registration.

IANA · RDAP JSON Values · Registry updated 2025-06-04 · consulted 2026-10-23

An absent field does not explain why it is absent

The RFC 9537 extension can explicitly signal redaction through a redacted member. Without that signal, an absent or empty field alone cannot distinguish unavailable data, access restrictions and other causes. Paths describe affected fields; a redaction declaration does not reveal their original contents.

An absent field does not explain why it is absent
Method	Principle	Cautious reading
removal	The field or object is removed; the default when method is omitted in this extension.	A pre-redaction path identifies the previous location, not a recoverable value.
emptyValue	A positional value is emptied, notably in certain jCard structures.	An empty string or null alone is not a redaction signal.
partialValue	Part of the value remains visible.	A published fragment does not automatically reconstruct the hidden portion.
replacementValue	Another value or property replaces the information.	A replacement contact must not be attributed to the registrant as certain personal data.

IETF · RFC 9537 · Redacted Fields in RDAP · March 2024 · §§3–5

Local RDAP reader

Paste a JSON response already obtained, or load a fictional case below. Reading stays in this page: no content submission, RDAP requests or persistent storage. Limit: 100 KiB encoded as UTF-8 and 400 total items across the collections read. Examples use names reserved for documentation.

The reader extracts selected root fields, roles of directly attached entities, top-level events and top-level redacted declarations. It does not traverse nested entities, read jCard names, execute JSONPath or validate the entire response against the RFCs or an ICANN profile. Dates remain as supplied; no chronology is inferred. Duplicate JSON properties are not detected; only the last value is retained.

An active status concerns the object in RDAP’s defined sense; it does not prove that a website responds over HTTP. delegationSigned is reported data, not a DNSSEC validation result. Values not listed in this snapshot are retained and labelled without a fraud verdict.

Eight fictional cases, also readable without JavaScript

Separate roles and four dates

Two entities carry different roles. The RDAP synchronisation date replaces neither the change date nor collection time.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Visible registrar, unpublished registrant

The published entity carries only the registrar role. An absent visible registrant role does not identify the holder; client hold does not prove fraud.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "client hold"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Redaction by removal

The redacted member declares removal of an administrative contact. The reader displays the path without evaluating it or attempting recovery.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Administrative contact in this fictional example"
            },
            "prePath": "$.entities[?(@.roles[0]=='administrative')]",
            "method": "removal"
        }
    ]
}

Empty jCard name value

The emptyValue signal concerns a jCard fn value. The reader shows the declaration; it neither resolves the path nor extracts jCard names.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        ""
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Registrant formatted name in this example"
            },
            "postPath": "$.entities[1].vcardArray[1][1][3]",
            "method": "emptyValue"
        }
    ]
}

Partially published address

The partialValue signal concerns a partly retained address. No full address or country of operation is inferred.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        "Example Holder"
                    ],
                    [
                        "adr",
                        [],
                        "text",
                        [
                            "",
                            "",
                            "",
                            "",
                            "Example Region",
                            "",
                            "Example Country"
                        ]
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Partial postal address in this example"
            },
            "postPath": "$.entities[1].vcardArray[1][2][3]",
            "method": "partialValue"
        }
    ]
}

Replacement contact

The replacementValue signal concerns a contact replaced by a fictional form URI. The URI is shown as text and is not visited.

{
    "rdapConformance": [
        "rdap_level_0",
        "redacted"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "active"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ],
            "vcardArray": [
                "vcard",
                [
                    [
                        "version",
                        [],
                        "text",
                        "4.0"
                    ],
                    [
                        "fn",
                        [],
                        "text",
                        "Example Holder"
                    ],
                    [
                        "contact-uri",
                        [],
                        "uri",
                        "https://contact.example/form"
                    ]
                ]
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    },
    "redacted": [
        {
            "name": {
                "description": "Email contact in this example"
            },
            "prePath": "$.entities[1].vcardArray[1][2]",
            "replacementPath": "$.entities[1].vcardArray[1][2]",
            "method": "replacementValue"
        }
    ]
}

Values outside the IANA snapshot

Custom values remain visible, labelled as absent from the local vocabulary’s three categories. They are not automatically treated as an error or attack.

{
    "rdapConformance": [
        "rdap_level_0"
    ],
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "handle": "DOMAIN-EXAMPLE",
    "status": [
        "example custom status"
    ],
    "events": [
        {
            "eventAction": "registration",
            "eventDate": "2020-01-15T10:00:00Z"
        },
        {
            "eventAction": "last changed",
            "eventDate": "2026-08-20T09:00:00Z"
        },
        {
            "eventAction": "last update of RDAP database",
            "eventDate": "2026-10-22T12:00:00Z"
        },
        {
            "eventAction": "expiration",
            "eventDate": "2027-01-15T10:00:00Z"
        },
        {
            "eventAction": "example custom event",
            "eventDate": "2026-10-22T12:10:00Z"
        }
    ],
    "entities": [
        {
            "objectClassName": "entity",
            "handle": "REGISTRAR-EXAMPLE",
            "roles": [
                "registrar",
                "example custom role"
            ]
        },
        {
            "objectClassName": "entity",
            "handle": "HOLDER-EXAMPLE",
            "roles": [
                "registrant"
            ]
        }
    ],
    "secureDNS": {
        "delegationSigned": true
    }
}

Null, empty and unexpected field types

status is null, entities is an empty array and events is a string rather than an array. These are distinguished without diagnosing a real domain.

{
    "objectClassName": "domain",
    "ldhName": "evidence.example",
    "status": null,
    "entities": [],
    "events": "not-an-array",
    "rdapConformance": []
}

Preserve a usable RDAP observation

Identify the source
Use an authoritative service and retain its URL. RFC 9224 bootstrap finds the longest label-wise match from right to left; it is not a substring search.
Record collection context
Keep requested name, returned name, UTC collection time, source, access conditions and notices or truncation. A public response need not represent all data held.
Compare comparable objects
Match names, handles, roles and dates while retaining their source. Registry and registrar responses can differ without demonstrating falsification.
Connect evidence without merging it
Corroborate RDAP with dated DNS, certificate and web-content observations. Attribute each observation separately and state unresolved hypotheses.

IETF · RFC 9224 · Authoritative RDAP Service · March 2022 · §§3–4, 7–9

IETF · RFC 7481 · RDAP Security Services · March 2015 · §§3–4

IANA vocabulary: three categories, 59 values

Definitions below are from the registry, in English, with references where present. A reference absent from the IANA record remains marked as such. The word administrative is both a role and a status: its category is part of its meaning.

role · 11

IANA · RDAP JSON Values · role · 2025-06-04
Value	Registry description	Reference
`registrant`	The entity object instance is the registrant of the registration. In some registries, this is known as a maintainer.	RFC9083
`technical`	The entity object instance is a technical contact for the registration.	RFC9083
`administrative`	The entity object instance is an administrative contact for the registration.	RFC9083
`abuse`	The entity object instance handles network abuse issues on behalf of the registrant of the registration.	RFC9083
`billing`	The entity object instance handles payment and billing issues on behalf of the registrant of the registration.	RFC9083
`registrar`	The entity object instance represents the authority responsible for the registration in the registry.	RFC9083
`reseller`	The entity object instance represents a third party through which the registration was conducted (i.e., not the registry or registrar).	RFC9083
`sponsor`	The entity object instance represents a domain policy sponsor, such as an ICANN-approved sponsor.	RFC9083
`proxy`	The entity object instance represents a proxy for another entity object, such as a registrant.	RFC9083
`notifications`	An entity object instance designated to receive notifications about association object instances.	RFC9083
`noc`	The entity object instance handles communications related to a network operations center (NOC).	RFC9083

event action · 12

IANA · RDAP JSON Values · event action · 2025-06-04
Value	Registry description	Reference
`registration`	The object instance was initially registered.	RFC9083
`reregistration`	The object instance was registered subsequently to initial registration.	RFC9083
`last changed`	An action noting when the information in the object instance was last changed.	RFC9083
`expiration`	The object instance has been removed or will be removed at a predetermined date and time from the registry.	RFC9083
`deletion`	The object instance was removed from the registry at a point in time that was not predetermined.	RFC9083
`reinstantiation`	The object instance was reregistered after having been removed from the registry.	RFC9083
`transfer`	The object instance was transferred from one registrar to another.	RFC9083
`locked`	The object instance was locked (see the "locked" status).	RFC9083
`unlocked`	The object instance was unlocked (see the "locked" status).	RFC9083
`last update of RDAP database`	An action noting when the information in the object instance in the RDAP database was last synchronized from the authoritative database (e.g. registry database).	No linked reference in this IANA record
`registrar expiration`	An action noting the expiration date of the object in the registrar system.	No linked reference in this IANA record
`enum validation expiration`	Association of phone number represented by this ENUM domain to registrant has expired or will expire at a predetermined date and time.	No linked reference in this IANA record

status · 36

IANA · RDAP JSON Values · status · 2025-06-04
Value	Registry description	Reference
`validated`	Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information.	RFC9083
`renew prohibited`	Renewal or reregistration of the object instance is forbidden.	RFC9083
`update prohibited`	Updates to the object instance are forbidden.	RFC9083
`transfer prohibited`	Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names.	RFC9083
`delete prohibited`	Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names.	RFC9083
`proxy`	The registration of the object instance has been performed by a third party. This is most commonly applied to entities.	RFC9083
`private`	The information of the object instance is not designated for public consumption. This is most commonly applied to entities.	RFC9083
`removed`	Some of the information of the object instance has not been made available and has been removed. This is most commonly applied to entities.	RFC9083
`obscured`	Some of the information of the object instance has been altered for the purposes of not readily revealing the actual information of the object instance. This is most commonly applied to entities.	RFC9083
`associated`	The object instance is associated with other object instances in the registry. This is most commonly used to signify that a nameserver is associated with a domain or that an entity is associated with a network resource or domain.	RFC9083
`active`	The object instance is in use. For domain names, it signifies that the domain name is published in DNS. For network and autnum registrations, it signifies that they are allocated or assigned for use in operational networks. This maps to the "OK" status of the Extensible Provisioning Protocol (EPP) .	RFC9083
`inactive`	The object instance is not in use. See "active".	RFC9083
`locked`	Changes to the object instance cannot be made, including the association of other object instances.	RFC9083
`pending create`	A request has been received for the creation of the object instance, but this action is not yet complete.	RFC9083
`pending renew`	A request has been received for the renewal of the object instance, but this action is not yet complete.	RFC9083
`pending transfer`	A request has been received for the transfer of the object instance, but this action is not yet complete.	RFC9083
`pending update`	A request has been received for the update or modification of the object instance, but this action is not yet complete.	RFC9083
`pending delete`	A request has been received for the deletion or removal of the object instance, but this action is not yet complete. For domains, this might mean that the name is no longer published in DNS but has not yet been purged from the registry database.	RFC9083
`add period`	This grace period is provided after the initial registration of the object. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the registration. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'addPeriod' status.	RFC8056
`auto renew period`	This grace period is provided after an object registration period expires and is extended (renewed) automatically by the server. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the auto renewal. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'autoRenewPeriod' status.	RFC8056
`client delete prohibited`	The client requested that requests to delete the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientDeleteProhibited' status.	RFC8056
`client hold`	The client requested that the DNS delegation information MUST NOT be published for the object. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'clientHold' status.	RFC8056
`client renew prohibited`	The client requested that requests to renew the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'clientRenewProhibited' status.	RFC8056
`client transfer prohibited`	The client requested that requests to transfer the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientTransferProhibited' status.	RFC8056
`client update prohibited`	The client requested that requests to update the object (other than to remove this status) MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'clientUpdateProhibited' status.	RFC8056
`pending restore`	An object is in the process of being restored after being in the redemption period state. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'pendingRestore' status.	RFC8056
`redemption period`	A delete has been received, but the object has not yet been purged because an opportunity exists to restore the object and abort the deletion process. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'redemptionPeriod' status.	RFC8056
`renew period`	This grace period is provided after an object registration period is explicitly extended (renewed) by the client. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the renewal. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'renewPeriod' status.	RFC8056
`server delete prohibited`	The server set the status so that requests to delete the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverDeleteProhibited' status.	RFC8056
`server renew prohibited`	The server set the status so that requests to renew the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'serverRenewProhibited' status.	RFC8056
`server transfer prohibited`	The server set the status so that requests to transfer the object MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverTransferProhibited' status.	RFC8056
`server update prohibited`	The server set the status so that requests to update the object (other than to remove this status) MUST be rejected. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping , Extensible Provisioning Protocol (EPP) Host Mapping , and Extensible Provisioning Protocol (EPP) Contact Mapping 'serverUpdateProhibited' status.	RFC8056
`server hold`	The server set the status so that DNS delegation information MUST NOT be published for the object. This maps to the Extensible Provisioning Protocol (EPP) Domain Name Mapping 'serverHold' status.	RFC8056
`transfer period`	This grace period is provided after the successful transfer of object registration sponsorship from one client to another client. If the object is deleted by the client during this period, the server provides a credit to the client for the cost of the transfer. This maps to the Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) 'transferPeriod' status.	RFC8056
`administrative`	The object instance has been allocated administratively (i.e., not for use by the recipient in their own right in operational networks).	No linked reference in this IANA record
`reserved`	The object instance has been allocated to an IANA special-purpose address registry.	No linked reference in this IANA record

IANA protocol registry data: CC0 1.0. Extraction is limited to status, event action and role; the source registry’s 30 other rows are not included. Scenarios and method are CIE synthesis, not data about real people or domains. Linked documents retain their own terms.

Source XML SHA-256: b24abf102b3c30b0a942668104df05aec3c479060ab58bb9c65287c1ce90171e

IETF · RFC 8056 · EPP/RDAP Status Mapping · January 2017 · §2

IANA · Protocol registry licensing terms · CC0 1.0 · consulted 2026-10-23

Official references

References consulted: 07/11/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.