RFC 5144: Domain Status Is Not Registration Approval

Summary

RFC 5144 defines a lightweight Domain Availability Check registry type within IRIS, using a strict subset of the fuller DREG model.
Its active and inactive states describe DNS publication, not whether a requester is entitled or able to register a name.
reserved explicitly means unavailable under normal registration procedures, even when a name is not active in DNS.
Dispute and five grace-period states show that one name can carry policy and lifecycle facts that a binary badge would erase.
Create, delete, renew, restore, transfer and update states can be qualified as pending or prohibited; naming an operation does not prove completion.
Actor, scope and substatus authority identify whose statement is being reported and where it applies.
lastDatabaseUpdateDateTime dates the source database, not the screen, API call or later commercial decision.
A registration reference points to a downstream registry, registrar or registrant service; it does not carry that service's authorization.
IRIS referrals can cross registry instances and types, while its XML layer supplies no authentication or privacy of its own.
IANA still lists DCHK's XML, S-NAPTR and BEEP identifiers, but identifier survival is not evidence of a live deployment.
RFC 5144 remains Proposed Standard, has one spelling erratum, and still refers to the now-obsolete Nameprep model for IDNs.
Leadership should require separate receipts for observation, authority, freshness, eligibility, command acceptance, committed mutation, DNS publication and user outcome.

The badge compressed away the reason

Suppose a high-volume availability service returns an RFC 5144 DCHK result for a name. The result contains <inactive>. The interface turns that into a green “available” badge. A procurement workflow immediately reserves budget, retires an existing name and announces a launch date.

The conversion is not supported by the protocol. In DCHK, inactive means unavailable through DNS. It says nothing about whether the name is reserved from ordinary registration. It says nothing about a dispute, an unexpired redemption period, the identity of the requester, the registrar's commercial policy or the registry's willingness to process a create command. The same result can carry the facts the badge omitted.

That is the useful tension in RFC 5144. The specification was explicitly designed to be lightweight and efficient for public-facing queries, yet its data model resists a careless yes/no interpretation. It gives a client a compact set of registry observations while preserving where a later decision must occur.

The protocol is not a shopping cart. It is a map of state.

“Active” belongs to DNS, not to ownership

RFC 5144 defines active as available through DNS, either by delegation or direct publication. It defines inactive as unavailable through DNS. The ordinary-language trap is immediate. Outside the specification, “active” may sound like a valid registration, and “inactive” may sound unclaimed. Inside the specification, the axis is publication.

A name can be absent from DNS and still be reserved. A deletion can be underway while a redemption opportunity remains. A transfer can be pending rather than finished. A policy rule can apply at one authority and not another. None of these combinations is mysterious once the fields are kept intact. They become mysterious only after a product renames an observation as a decision.

The reserved status is unusually candid: the domain is not available for registration under normal procedures. It is a separate field because DNS absence cannot carry that meaning. Dispute and grace-period statuses add other constraints. Add, renewal, auto-renewal, transfer and redemption periods describe lifecycle positions, not generic availability.

RFC 3915 makes that lifecycle concrete. A deleted name can pass through redemption and pending-delete states before it is purged and becomes available for re-registration. A query made during that process can be completely accurate and still be unusable as a forecast of what a later create request will do.

A status needs a speaker, a time and a scope

DCHK's status type contains more provenance than a badge usually displays. It may carry an applied date, service-ticket identifiers and natural-language descriptions. A substatus value is deliberately left to another specification, but it must identify the authority that defined it. The status may name its actor as the registry, registrar or registration service provider. It may identify its scope. For operational statuses, it may say whether the action is pending or prohibited.

These are not decorative metadata. They answer different questions.

Who made the statement? Which institution's policy does it express? At what layer is the action pending? What context limits the result? When was the status applied? Which ticket lets an operator reconstruct the event? Without those qualifiers, a client can turn “registrar transfer pending” into “the registry has transferred the name”, or turn “registry policy compliant in one scope” into “universally eligible”.

The most easily overlooked clock is lastDatabaseUpdateDateTime. It records the last actualization of the database that supplied the result. It is not necessarily the network response time. It is not the time the user opened a cached page. It is not the time money changed hands or a create command was submitted.

An assurance record therefore needs at least three clocks: source-state time, observation time and decision time. If a system overwrites them with one updated_at, it destroys the evidence needed to understand a race.

A reference is an instruction to ask again

The DCHK result can include a registration reference. When a registry returns it, the reference is intended to point downstream to a registrar or registrant service. That makes the availability service useful without forcing the public query tier to own every registration detail.

But a pointer has no transferable authority. The downstream service may require authentication, commercial eligibility, a valid account, local policy checks or payment. It may operate on a fresher database. It may reject a request that looked plausible at the public query tier.

IRIS itself reinforces the distinction. It supports entity references and search continuations that may cross registry types and instances. It also warns clients to follow a reference only once so that referral loops do not become endless queries. A successful traversal proves that a chain was navigable. It does not prove that every link described the same authority or that the final system accepted a mutation.

This is where a thin shared protocol is strongest. It can say where the next question belongs without pretending to answer it.

Authentication protects a conversation, not a business decision

RFC 5144 inherits security considerations from the IRIS core. RFC 3981 says the XML layer has no authentication or privacy facilities of its own and relies on the application transport. It also warns about replay-prone credentials when following referrals.

Even a fully authenticated transport would answer only one class of doubt: whether the client spoke securely to the expected service under the transport's model. It would not prove that the status was fresh, that its scope was understood, that the requester was eligible, or that a later create or transfer command committed.

This distinction is visible in EPP, the provisioning protocol family used as a supporting comparison. RFC 5731 says its <check> command provides a hint about whether an object can be provisioned, because provisioning requirements remain a matter of server policy. A transform can be processed and still remain pending; completion is a later state change with notification.

DCHK and EPP are not the same interface and the latter does not formally replace the former here. Their common lesson is narrower: query success, predictive availability and committed mutation are different receipts.

A standards label is not a deployment metric

RFC 5144 remains a Proposed Standard. IANA continues to list its dchk1 XML namespace and schema, its DCHK1 S-NAPTR application-service tag and its BEEP profile URI. Those entries are real. They show that protocol identifiers were assigned and remain catalogued.

They do not show how many servers answer DCHK today, which registries expose it, or whether a particular reply path is running. The source packet contains no deployment census, latency study or success-rate measurement. The Article therefore makes none of those claims.

The one verified erratum is modest: it corrects a misspelling of “Straightforward-NAPTR”. It changes no status semantics. A more consequential compatibility clue lies elsewhere. RFC 5144's IDN field points to Nameprep in RFC 3491. That document is obsolete, and RFC 5891 defines the later IDNA2008 protocol. RFC 5144 is not formally marked obsolete as a result, but an implementation cannot infer current IDN-policy compatibility from the old reference.

The principle is the same at two scales. A registry entry is evidence of assignment, not running code. A standards status is evidence of process, not present operational fitness.

The receipt ladder

An availability product that supports consequential decisions should preserve a ladder rather than a lamp.

First, record the normalized query and the authority asked. Second, retain the exact DCHK result and protocol version. Third, preserve the source database's actualization time separately from response and display times. Fourth, keep every status token with actor, disposition, scope, applied date, ticket, description and substatus authority. Fifth, record any downstream reference and the authority actually reached.

Only then begin the provisioning side: requester identity, eligibility, applicable policy, price, command submission, acceptance, pending review, committed registry mutation and resulting object state. DNS delegation or direct publication comes later. Recursive resolution and useful application behaviour are later still.

Each step can justify the next action. None should be promoted into proof of the steps below it.

This design also improves failure analysis. A stale DCHK database points to replication or publication. A fresh reserved result points to policy, not transport. A pending create points to workflow, not query parsing. A committed registration without DNS publication points to delegation. Successful resolution without application service points beyond DNS. The composite “available/unavailable” badge sends every failure to the wrong team.

The Name Was Inactive. It Still Was Not Yours to Register.

Why it matters

Summary

The badge compressed away the reason

“Active” belongs to DNS, not to ownership

A status needs a speaker, a time and a scope

A reference is an instruction to ask again

Authentication protects a conversation, not a business decision

A standards label is not a deployment metric

The receipt ladder

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing