Domain Transfer Lock Shown Off When Unknown

A domain's transfer lock was shown as OFF when the registry had not said

Fixed in 3.9.0 · Reported in #188 by @srinivasansanthosh · Module: Domains

---

The short version

When a registry answered a lookup with just active (or ok) and no transfer status, FreeITSM recorded the domain's transfer lock as OFF - a failing security check worth 12 points, and a place on the Transfer unlocked list. For a lot of country registries that was a false alarm: they answer active for every domain and never say whether a transfer lock is on, because they do not publish it.

The lock is now on only when the registry says so, off only when the registry would have said so, and not known otherwise - the reporter's request almost word for word: "OFF or ON should be used only when explicit information is available."

The same issue asked for the domain's cost centre to come from System → Cost centres - see Domains and Cost centres.

What you saw

A domain at a country registry (the reporter's were on a registry that only publishes active) showed:

• Transfer lock: Off, in red;
• a failing check, "Transfer lock is off", taking 12 points off its security score;
• a place on the register's Transfer unlocked view and the dashboard's attention list.

Nothing about the domain was actually known to be unlocked.

What was wrong

Registries describe a domain with EPP statuses - active/ok, client transfer prohibited, server delete prohibited and so on. domainDeriveFlags() reasoned:

if the reply uses EPP words at all, the lock is ON when a transfer-prohibited status is there, and OFF when it is not.

That is exactly right for generic TLDs (.com, .org, .app and the rest): ICANN's RDAP profile obliges their registries to publish every EPP status, so the absence of client transfer prohibited there really does mean the lock is off. RFC 8056 maps EPP's ok to RDAP's active, and for those registries active means "no prohibitions at all".

It is not right for country-code TLDs, which are not bound by ICANN's profile. Many answer active and nothing else. Absence of a status there is absence of information, not information.

The code already knew two exceptions - .uk (Nominet moves domains by registrar tag, so a lock usually "does not apply") and .de (DENIC's connect is not an EPP word, so the lock stays unknown). Every other country registry fell through to "off".

The fix

$transfer       = in_array('client transfer prohibited', $s, true) || in_array('server transfer prohibited', $s, true);
$anyProhibition = (bool)preg_grep('/^(client|server) \w+ prohibited$/', $s);
if ($transfer)                                                    $r['transfer_lock'] = true;
elseif ($anyProhibition || domainTldPublishesAllStatuses($name))  $r['transfer_lock'] = false;
else                                                              $r['transfer_lock'] = null;   // not known

OFF needs evidence that the registry would have shown a lock, one of:

• it is a generic TLD - domainTldPublishesAllStatuses(): longer than two letters, and not an IDN (xn-- can be a country code, so it is not assumed);
• the reply carries another prohibition - a registry that publishes delete prohibited but not transfer prohibited is telling you something.

Otherwise the lock is not known - the finding becomes the existing "The registry does not say whether transfers are locked", with its advice to check the registrar's control panel, and no points are lost.

.uk and .de behave exactly as before.

Nothing to do after upgrading

Each domain is re-read at its next lookup (the scheduled run, or Refresh), and the lock is worked out again from the statuses it already stores. A lock going from off to not known is not reported as a change - change detection deliberately treats known → unknown as a gap in knowledge, not an alert.

📁 Files changed

	File	Change
🟦	includes/domains/lookup.php	domainDeriveFlags() needs evidence for OFF; new domainTldPublishesAllStatuses()
🟩	tests/domain-transfer-lock.php	15 cases - the reported one, on/off/not known, .uk, .de, IDN, no name

How it was verified

php tests/domain-transfer-lock.php - 15 made-up registry replies, no network.

The control: the same test run against the code before the fix fails 5 cases, each one reporting false (off) where the answer is null (not known) - the reported bug, reproduced. After the fix all 15 pass, including .com with active only still reading as off (the warning that is worth keeping) and .co.uk still reading as not applicable.

Related pages

• Domains · Domains - Developer Guide
• Bugs resolved