What WHOIS still tells you, and what it now hides

WHOIS used to tell you who owned a domain. Mostly it doesn't any more. What it still tells you is what state the domain is in, and when mail or a website breaks, that's the half you needed anyway.

Here's this site's own record, as the whois command returned it on 10 September 20261:

$ whois tamingdns.com
Domain Name: TAMINGDNS.COM
Registrar: Cloudflare, Inc.
Creation Date: 2026-04-21T13:56:46Z
Domain Status: clienttransferprohibited
Name Server: aiden.ns.cloudflare.com
Name Server: ariadne.ns.cloudflare.com
DNSSEC: signedDelegation
Registrant Name: DATA REDACTED
Registrant Organization: DATA REDACTED

No name. Every other line is useful, though. Say this domain emailed your finance team asking them to change banking details. The creation date is the line you'd want, because four months is young1. Yes, we know. We're working on it.

The WHOIS lookup on this site reads the same fields and puts the age, expiry and status codes in plain English18.

The names went for legal reasons, and the protocol changed too

There are two reasons the names went, one legal and one technical.

ICANN's Registration Data Policy says registries and registrars must redact personal data where the law requires it, and may redact it where they have "a commercially reasonable purpose to do so"2. That second clause is what lets a company's domain come back DATA REDACTED too.

The technical one is plumbing. Since 28 January 2025, RDAP (the Registration Data Access Protocol, which answers in JSON over HTTPS19) has been the definitive source for generic top-level domain registration data, "in place of sunsetted WHOIS services"3. The old port-43 whois command still answered for tamingdns.com on 10 September1. It just isn't the source of record any more for .com, .org and the other generic TLDs.

South African domains are the odd one out. .co.za sits under .za, a country-code TLD20, so ICANN's RDAP deadline doesn't cover it. On 10 September we couldn't find an RDAP server for it at all. rdap.registry.net.za says on its landing page that it serves .africa, and it returned 404 for osh.co.za and google.co.za. IANA's bootstrap file, the list RDAP clients use to find a TLD's server21, has no .za entry4.

Here's the difference side by side.

	WHOIS (port 43)	RDAP
What comes back	Human-readable text30	JSON19
How it travels	Plain TCP on port 4330	HTTPS19
Finding the right server	The protocol doesn't say30	IANA's bootstrap file21
.com, .org and other generic TLDs	Sunset as the source of record (still answers)3	The source of record since 28 January 20253
.co.za	Still the way in5	No server found on 10 September4
DNSSEC field	DNSSEC: signedDelegation	delegationSigned: true8

The old port-43 server at whois.registry.net.za still answers, and it says more than Verisign's does. For our own osh.co.za it returned Registrant Organization: Outsource House and pointed the email lines to the registrar instead5. Don't count on that line. google.co.za came back blank the same morning. Verisign's answer for tamingdns.com had no registrant lines at all, and the DATA REDACTED lines above came from Cloudflare's own server6.

Our take: stop reading WHOIS for a name. Read it for the seven problems below. For each one, a WHOIS field tells you where to look first.

"Who actually holds our domain?"

If whoever built your website also registered the domain, it may well sit in their account and not yours. When that person has moved on, start with the Registrar line. It names the registrar sponsoring the registration22, and that's who you phone.

On .co.za the Registrant Organization line can get you one step further. When it's filled in, it shows which company the domain was registered to5, before you pick up the phone. That changes the conversation you're about to have.

You edited the zone and nothing changed

You changed a record an hour ago and no resolver will give it back to you. Waiting won't fix it. Before you blame propagation, check which DNS host the registry delegates to.

Those are the Name Server lines. They're the delegation the registry holds22. If they name a different DNS host from the one you just logged in to, you've been editing a copy of the zone that nobody is asking. For osh.co.za on 10 September, the WHOIS nameservers matched what the .co.za servers themselves handed out7:

$ dig +noall +authority NS osh.co.za @ns.coza.net.za
osh.co.za.  7200  IN  NS  ns1.dns-parking.com.
osh.co.za.  7200  IN  NS  ns2.dns-parking.com.

Ask the parent, the way that query does, because a normal resolver might answer from the NS records inside your own zone instead23. The DNS lookup tool shows the NS records each of three public resolvers currently has cached, which is what those resolvers are telling everyone who asks them24.

The domain resolves for some people and fails for others

A DNSSEC mismatch after a DNS move is the one that eats afternoons. You move DNS hosting, the new host has every record, and some users can reach you while others get nothing.

Check the DNSSEC line. signedDelegation means the parent zone holds a DS record, which vouches for one specific signing key8. If your new DNS host doesn't sign with that key, validating resolvers can't build the chain of trust. RFC 4035 is strict about this. Unless the client explicitly asked for unchecked data, the resolver "MUST return RCODE 2", a server failure8. A resolver that doesn't validate hands the answer back anyway, which is what the +cd query below imitates. That's where "works for some people" comes from.

dnssec-failed.org is broken on purpose, and the name tells you what it does. Even the digest in its DS record, decoded from hex, reads "broken chain of trust send help!". Somebody had fun with that one. Here's what it gave us on 10 September9:

$ dig A dnssec-failed.org @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

$ dig +cd A dnssec-failed.org @8.8.8.8
dnssec-failed.org.  300  IN  A  96.99.227.255

$ whois dnssec-failed.org | grep DNSSEC
DNSSEC: signedDelegation

The A record is there. The +cd flag tells the resolver to skip validation8, and the answer comes straight back. The WHOIS line tells you the parent still expects signatures. The DS record lives in the parent zone, not in yours25, so you have two ways out. Get the old DS taken out of the parent, or get the new host signing with a key that matches it.

The DNSSEC checker walks the chain and tells you which link broke26. Our WHOIS tool works out its DNSSEC verdict from a live chain check, not from the registry's DNSSEC line18. If you want the registry's line, run the whois command.

The domain is fine and the registry has stopped publishing it

Every record in your zone is right, your DNS host is up, and nothing resolves. You'll suspect an outage at the DNS host. Look for clientHold or serverHold in the status lines first.

ICANN describes clientHold as telling the registry "to not activate your domain in the DNS and as a consequence, it will not resolve". It says it's "usually enacted during legal disputes, non-payment, or when your domain is subject to deletion"10. serverHold ends the same way, except the registry operator set it, not your registrar11. Either way, the fix is a phone call to the registrar10. Nothing in your zone needs changing.

These are the statuses this article cares about. ICANN's page has the rest10.

Status	Set by	What it means	What to do
clientTransferProhibited, clientDeleteProhibited, clientUpdateProhibited	Registrar	Transfers, deletes or updates are refused	Nothing. These are the locks you want17
clientHold	Registrar	The registry won't publish the domain, so it doesn't resolve	Call the registrar10
serverHold	Registry	Same result, set by the registry operator	Call the registrar11
pendingTransfer	Registry	Someone asked to move the domain to a new registrar	If it wasn't you, call the registrar now16
redemptionPeriod	Registry	Up for deletion, held for 30 days, and the registrar can still restore it	Call the registrar now1213
pendingDelete	Registry	On its own: redemption ended without a restore, and a purge is coming. Alongside redemptionPeriod, read that row	Call the registrar immediately to ask what's left12

An expired domain can still be in your SPF record

A domain named in your SPF record can expire while it's still named there. Once the registry purges it, anyone can register it.

For generic TLDs, a deleted domain sits in redemptionPeriod for 30 days. Then, "after five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration"12. During the redemption period, the registrar can still restore it13. Those numbers are ICANN's. .co.za sits under a country-code TLD20, so ask your registrar instead of assuming they're the same.

Your own domain lapsing is the obvious risk. The sneakier one is somebody else's domain lapsing while your DNS still names it. An SPF include: doesn't copy the other domain's record into yours. It checks that domain's live record every time, and a match there is a pass for you14.

So say include:old-newsletter-vendor.example is still sitting in your SPF and that vendor's domain expires. Whoever registers it next writes a record that authorises their servers to send as you. Same story for an MX host on a domain nobody renewed, because sending servers deliver to whatever host your MX record names27.

We don't have numbers on how often a lapsed include domain gets picked up by someone else. It's cheap to rule out anyway.

What to do: once a year, run WHOIS on every domain your SPF includes and every domain your MX hosts sit on. Read the expiry date and the status. Anything in redemptionPeriod or pendingDelete comes out of your DNS today.

Age is the line to read first on a stranger's domain

Here's a made-up example. Finance gets an invoice from northwind-traders.example asking for a change of bank details. The supplier you really deal with is northwindtraders.example, registered years ago. The lookalike was registered on Tuesday. You don't need to read anything else on the page.

Passing SPF, DKIM and DMARC won't save you here, because a lookalike domain can pass all three for itself. Authentication only proves which domain sent the message28. If it's fraud, report it to the registrar's abuse contact29. Our WHOIS tool pulls that contact from RDAP where the registry publishes one, for example [email protected] for tamingdns.com15.

On its own, a young domain proves nothing. This site was four months old when we ran that lookup. A new domain also starts with no sending history. The IP it sends from has a history of its own, and that's the half the self-hosting piece covers.

A transfer you didn't ask for is an emergency

pendingTransfer means a request to move your domain to another registrar is in progress. ICANN puts it plainly: "If you did not request to transfer your domain, you should contact your registrar immediately"16.

The status you want on your own domain is clientTransferProhibited. Ideally it sits next to clientDeleteProhibited and clientUpdateProhibited, which ICANN says "can help to prevent unauthorized transfers, deletions, or updates to your domain"17. Both tamingdns.com1 and osh.co.za5 carry the transfer lock. Neither has the other two.

Run your own domain through WHOIS now. Then do every domain named in your SPF record.

Sources checked

1. This site's own registration record, read 10 September 2026: creation date 2026-04-21, registrar Cloudflare, signedDelegation, registrant fields redacted. Excerpted to the lines shown. Source: whois tamingdns.com ↩
2. Registries and registrars “MUST” redact personal data where applicable law requires it and “MAY” where they have a commercially reasonable purpose (§9.2.1). Read 10 September 2026. Source: ICANN Registration Data Policy ↩
3. “As of 28 January 2025, the Registration Data Access Protocol (RDAP) will be the definitive source for delivering generic top-level domain name (gTLD) registration information in place of sunsetted WHOIS services.” Source: ICANN: Launching RDAP; Sunsetting WHOIS ↩
4. Checked 10 September 2026: the landing page at rdap.registry.net.za reads “This facility serves the following zones: .africa”; /rdap/domain/osh.co.za and /rdap/domain/google.co.za returned RDAP error 404 while registry.africa returned 200; the IANA bootstrap file had no service entry for za or co.za. Source: IANA RDAP bootstrap (dns.json) · curl https://rdap.registry.net.za/rdap/domain/osh.co.za ↩
5. ZACR port-43 answer for osh.co.za, read 10 September 2026: Registrant Organization: Outsource House, Registrant Email: Please contact the RDDS service of the listed Registrar…, Domain Status: clientTransferProhibited, created 2009-04-16. Source: whois -h whois.registry.net.za osh.co.za ↩
6. The same query for google.co.za, 10 September 2026, returned an empty Registrant Organization: line. Verisign's port-43 answer for tamingdns.com contained no registrant lines; the registrar's own server, queried directly, returned Registrant Name: DATA REDACTED. Source: whois -h whois.registry.net.za google.co.za · whois -h whois.verisign-grs.com tamingdns.com · whois -h whois.cloudflare.com tamingdns.com ↩
7. Delegation for osh.co.za read at the .co.za parent, 10 September 2026; it matched the WHOIS Name Server lines. Source: dig +noall +authority NS osh.co.za @ns.coza.net.za ↩
8. “If the validation was being done to service a recursive query, the name server MUST return RCODE 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set.” (§5.5) RCODE 2 is “server failure” (§3.2.2). The DS record “refers to a DNSKEY RR by storing the key tag, algorithm number, and a digest of the DNSKEY RR” (RFC 4034 §5). The CD bit is the “Checking Disabled” bit, “controlled by resolvers” (RFC 4035); dig +cd sets it. RDAP's counterpart to the WHOIS signedDelegation value, delegationSigned, is “true if there are DS records in the parent” (RFC 9083 §5.3); on 23 October 2026 whois tamingdns.com printed DNSSEC: signedDelegation beside DNSSEC DS Data: 2371 13 2 554B7BE7…, the DS that dig DS tamingdns.com returns. Source: RFC 4035 §5.5 · RFC 4034 §5 · RFC 9083 §5.3 ↩
9. Three commands run 10 September 2026: SERVFAIL without +cd, an A record with it, and signedDelegation in WHOIS. The domain's DS digest, 62726F6B656E20636861696E206F662074727573742073656E642068656C7021, decodes from hex to “broken chain of trust send help!” (dig +cd +short DS dnssec-failed.org @8.8.8.8). Source: dig A dnssec-failed.org @8.8.8.8 · dig +cd A dnssec-failed.org @8.8.8.8 · whois dnssec-failed.org ↩
10. clientHold: “This status code tells your domain's registry to not activate your domain in the DNS and as a consequence, it will not resolve. It is an uncommon status that is usually enacted during legal disputes, non-payment, or when your domain is subject to deletion. Often, this status indicates an issue with your domain that needs resolution. If so, you should contact your registrar to resolve the issue.” The page groups the codes under “Server Status Codes are Set by Your Domain's Registry” and “Client Status Codes are Set by Your Domain's Registrar”. Source: ICANN: EPP Status Codes ↩
11. serverHold: “This status code is set by your domain's Registry Operator. Your domain is not activated in the DNS.” … “you should contact your registrar to request more information.” Source: ICANN: EPP Status Codes ↩
12. redemptionPeriod: “Your domain will be held in this status for 30 days. After five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration.” pendingDelete on its own “indicates that your domain has been in redemptionPeriod status for 30 days and you have not restored it within that 30-day period”, and “If you want to keep your domain name, you must immediately contact your registrar to discuss what options are available.” Read again 23 October 2026. Source: ICANN: EPP Status Codes ↩
13. During the redemption period “A <restore> operation can be requested using the extended EPP <update> command.” (§2) Source: RFC 3915 §2 ↩
14. “The ‘include’ mechanism triggers a recursive evaluation of check_host()”, and if it returns match, “include or +include produces a ‘pass’ result”. Source: RFC 7208 §5.2 ↩
15. This site's WHOIS tool, run against tamingdns.com on 10 September 2026, returned [email protected] as the abuse contact. The checker reads that field from the abuse entity in an RDAP response (WhoisChecker.php). Source: this site's WHOIS lookup, tamingdns.com ↩
16. pendingTransfer: “This status code indicates that a request to transfer your domain to a new registrar has been received and is being processed. If you did not request to transfer your domain, you should contact your registrar immediately”. Source: ICANN: EPP Status Codes ↩
17. “Asking your registrar to enact status restrictions, like clientTransferProhibited, clientDeleteProhibited, and clientUpdateProhibited, can help to prevent unauthorized transfers, deletions, or updates to your domain.” Source: ICANN: EPP Status Codes ↩
18. What this site's WHOIS tool shows, checked against its code and a live run on 10 September 2026: WhoisChecker.php maps each EPP status to a plain-English sentence and computes age and days to expiry (osh.co.za came back “17 years, 4 months”); tools/whois.php runs DnssecChecker for its DNSSEC card and never reads the registry's DNSSEC field. Source: app/lib/WhoisChecker.php · tools/whois.php ↩
19. RDAP responses are “JSON data structures representing registration information” (RFC 9083, abstract), and “Clients and servers MUST support HTTPS” (RFC 7480 §4.1). Source: RFC 9083 · RFC 7480 §4.1 ↩
20. IANA's root zone database lists .za with the category “Country-code top-level domain”. Read 23 October 2026. Source: IANA: .za delegation record ↩
21. The bootstrap method is how a client finds “which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names” (abstract). Source: RFC 9224 ↩
22. A registry's domain record carries “the fully qualified names of the delegated host objects or host attributes (name servers) associated with the domain object” and “the identifier of the sponsoring client”, the registrar. Source: RFC 5731 §3.1.2 ↩
23. Resolvers rank “The authoritative data included in the answer section of an authoritative reply” above “Data from the authority section of a non-authoritative answer”, and a parent “should not return authoritative answers for queries related to names in another zone, which includes the NS” records at a zone cut (§6.1), so the child zone's own NS records outrank the parent's referral. Source: RFC 2181 §5.4.1 · §6.1 ↩
24. The DNS lookup tool's own description: “What you see is what that resolver currently has cached for your domain.” Source: app/views/tools/dns-lookup/intro.php ↩
25. “The DS RR appears only on the upper (parental) side of a delegation, and is authoritative data in the parent zone.” Source: RFC 4034 §5 ↩
26. The DNSSEC checker's own description: it “walks the chain of trust from the root zone down to your name”, and “If the chain breaks anywhere, the report names the step that failed.” Source: app/views/tools/dnssec/intro.php ↩
27. To deliver, a sending server resolves the recipient domain and “The lookup first attempts to locate an MX record associated with the name.” Source: RFC 5321 §5.1 ↩
28. “DMARC validates the authorized use of the Author Domain” by requiring it to share an Organizational Domain with, or be identical to, an Authenticated Identifier (§4.4). A lookalike that sends from its own domain and authenticates that domain passes. RFC 9989 obsoletes RFC 7489. Source: RFC 9989 §4.4 ↩
29. RDAP's registered abuse role: “The entity object instance handles network abuse issues on behalf of the registrant of the registration.” (§10.2.4) Source: RFC 9083 §10.2.4 ↩
30. “A WHOIS server listens on TCP port 43 for requests from WHOIS clients” (§2), and “The protocol delivers its content in a human-readable format” (§1). The RFC defines no way to find which server to ask; read in full on 23 October 2026. Source: RFC 3912 ↩

Check what WHOIS says about your domain today.