What WHOIS still tells you, and what it now hides

WHOIS mostly stopped telling you who owns a domain. It still tells you what state the domain is in, and when mail or a website breaks, the state is the half you needed.

Here is 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. But every other line is useful. If this domain emailed your finance team asking to change banking details, the creation date would be the most important line on the page, because four months is young1. We know. We are 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

Registrant names left WHOIS for one legal reason and one technical one. 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 other change is plumbing. Since 28 January 2025, RDAP (the Registration Data Access Protocol, which answers in JSON over HTTPS19) is 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. For .com, .org and the other generic TLDs it is no longer the source of record.

South African domains are the odd one out. .co.za sits under .za, a country-code TLD20, so ICANN's RDAP deadline does not cover it, and on 10 September we could not find an RDAP server for it at all. rdap.registry.net.za says on its landing page that it serves .africa and 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. The old port-43 server at whois.registry.net.za still answers, and it says more than Verisign's. For our own osh.co.za it returned Registrant Organization: Outsource House and withheld only the email addresses5. Do not count on that line. google.co.za came back blank the same morning, and Verisign's answer for tamingdns.com had no registrant lines at all. 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, each of which a WHOIS field answers faster than anything else.

"Who actually holds our domain?"

If the person who built your website also registered the domain, it may well sit in their account rather than yours. When that person has moved on, the Registrar line is where you start, because it names the registrar sponsoring the registration22, and that registrar is who you phone.

On .co.za the Registrant Organization line can go one step further. It tells you whether the domain was registered to your company or to someone else's5 before you pick up the phone, and that changes the conversation you are about to have.

You edited the zone and nothing changed

The symptom is a record you changed an hour ago that no resolver will return. The false trail is propagation, and waiting will not fix it.

Look at the Name Server lines first. They are the delegation the registry holds22. If they name a DNS host other than the one you just logged in to, you edited 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.

Asking the parent directly is the check, because a normal resolver may 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 everyone else is being told24.

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 a specific signing key8. If your new DNS host does not sign with that key, validating resolvers cannot build the chain of trust. RFC 4035 is strict about it. Unless the client explicitly asked for unchecked data, the resolver "MUST return RCODE 2 (server failure)"8. A resolver that does not validate hands the answer back regardless, which is what the +cd query below imitates. That is where the "works for some people" comes from.

dnssec-failed.org is a test domain whose name says what it does. Even the digest in its DS record, decoded from hex, reads "broken chain of trust send help!". 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 for dnssec-failed.org exists. 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 is stored in the parent zone, not in yours25, so either the old DS comes out of the parent or the new host signs with a key that matches it. The DNSSEC checker walks the chain and tells you which link broke26. Our WHOIS tool shows a DNSSEC verdict of its own, from a live chain check, rather than the registry's DNSSEC line18. The whois command shows that line.

The domain is fine and the registry has stopped publishing it

Every record in your zone is correct, your DNS host is up, and nothing resolves. The false trail is an outage at the DNS host. Look for clientHold or serverHold in the status lines.

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

An expired domain can still be in your SPF record

A domain named in your SPF record can expire while it is 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. Until the purge the registrar can still restore it13. Those lengths come from ICANN. .co.za sits under a country-code TLD20, so ask your registrar rather than assume they match.

Your own domain lapsing is the obvious risk. The quieter one is somebody else's domain lapsing while it is still named in your DNS. An SPF include: does not copy the other domain's record into yours. It evaluates that domain's live record every time, and a match there is a pass for you14. So if include:old-newsletter-vendor.example still sits in your SPF and that vendor's domain expires, whoever registers it next writes a record that authorises their servers to send as you. The same goes for an MX host on a domain nobody renewed, because sending servers deliver to whatever host your MX record names27.

We have no numbers on how often a lapsed include domain gets re-registered by someone else. It is 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, and read the expiry date and status. Anything in redemptionPeriod or pendingDelete comes out of your DNS today.

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

An illustrative case: finance gets an invoice from northwind-traders.example asking for a change of bank details. The supplier you actually deal with is northwindtraders.example, registered years ago. The lookalike was registered on Tuesday. Nothing else on the page needs reading.

Passing SPF, DKIM and DMARC does not help here, because a lookalike domain can pass all three for itself. Authentication proves which domain sent the message, not that it is the domain you meant28. If it is fraudulent, the registrar's abuse contact is where the report goes29. Our WHOIS tool pulls it from RDAP where the registry publishes one, for example [email protected] for tamingdns.com15.

A young domain proves nothing on its own. This site is four months old. A new domain also starts with no sending history. The IP it sends from has a history of its own, and that is the half the self-hosting piece covers.

A transfer you did not 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 alongside 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 carries the other two.

Run your own domain through WHOIS now, then 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. — 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. — 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.” — 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. — 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. — 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. — 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. — dig +noall +authority NS osh.co.za @ns.coza.net.za ↩
8. “If the CD bit is set, the name server side SHOULD return the data from the BAD cache; if the CD bit is not set, the name server side MUST return RCODE 2 (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. — RFC 4035 §3.2.2 · RFC 4034 §5 ↩
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). — 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.” — 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.” — 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.” — ICANN: EPP Status Codes ↩
13. During the redemption period “A <restore> operation can be requested using the extended EPP <update> command.” (§2) — 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”. — 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). — 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”. — 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.” — 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. — 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). — RFC 9083 · RFC 7480 §4.1 ↩
20. IANA's root zone database: “Delegation Record for .ZA (Country-code top-level domain)”. Read 10 September 2026. — 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). — 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. — 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. — 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.” — 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.” — 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.” — 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.” — 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. — 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) — RFC 9083 §10.2.4 ↩

Check what WHOIS says about your domain today.