Investigating a Domain: WHOIS, RDAP, DNS Records, and Certificate Transparency

BY DR. LELAND W. SMITH

A domain name is often the most durable artifact in an investigation. Websites change, social accounts disappear, but domain registrations, DNS records and certificates leave traces in public systems that are designed to be queried. Used well, these sources can tell you when infrastructure was set up, how it is configured, and what else may sit alongside it. Used carelessly, they produce confident conclusions that do not survive scrutiny. This guide covers the four main public sources for domain research, what each can and cannot tell you, and how to combine them.

The four sources at a glance

• Registration data (WHOIS and RDAP) describes who registered the domain, through which registrar, and when. Since 2018, much of the personal detail is redacted.
• DNS records describe how the domain currently works: where its website is hosted, where its email goes, which servers are authoritative for it.
• Historical DNS describes how those records looked in the past, as observed by third parties.
• Certificate Transparency logs record the TLS certificates issued for a domain and its subdomains, which often reveals names and dates that are not visible anywhere else.

No single source is enough. The value comes from cross-checking them against each other and against the content of the site itself.

Registration data: WHOIS, RDAP and what changed

Classic WHOIS

WHOIS is a decades-old query protocol, documented in RFC 3912, that returns free-text records about a domain. A typical record includes the registrar, creation date, last updated date, expiry date, nameservers, domain status codes and, historically, the registrant's name, organization, address, email and phone number.

The format was never standardized. Every registry and registrar returned slightly different text, which made automated parsing unreliable.

The effect of GDPR

When the EU General Data Protection Regulation took effect in May 2018, ICANN adopted a temporary specification that led registrars for generic top-level domains to redact personal data from public registration records. That approach was later replaced by ICANN's Registration Data Policy. In practice, most records for individuals now show "REDACTED FOR PRIVACY" or similar in place of names, addresses and phone numbers. The registrant's state or province and country, and sometimes the organization name, often remain visible. Contact is typically routed through a web form or an anonymized relay email.

Separately, many registrants pay for or receive a free privacy or proxy service, which replaces their details with those of the service. Redaction and proxy services are not signs of wrongdoing. They are the default for a large share of legitimate domains.

Country-code domains such as .uk, .de or .au are governed by their own registries and policies, which vary considerably in what they publish.

RDAP

The Registration Data Access Protocol (RDAP) is the structured replacement for WHOIS. It returns JSON over HTTPS, with standard field names, and supports differentiated access, so authorized parties can in principle see more than the public. The core specifications include RFC 9082 for queries and RFC 9083 for responses.

For generic top-level domains, ICANN's contracts with registries and registrars stopped requiring the legacy WHOIS service from 28 January 2025, and RDAP became the authoritative source of registration data. Many WHOIS services still answer, but when the two disagree, rely on RDAP.

The easiest way to query RDAP without code is ICANN's own lookup tool at lookup.icann.org. It follows the referral from the registry to the registrar and shows both records. Regional internet registries such as ARIN and RIPE NCC also provide RDAP for IP address allocations, which tells you which organization holds a block of addresses.

Reading a registration record

Even redacted records carry useful fields:

• Creation date. When the current registration began. If a domain lapsed and was re-registered, this date reflects the new registration, not the domain's first use.
• Updated date. Changes for many routine reasons, including renewals, nameserver changes and registrar updates. Do not read much into it alone.
• Expiry date. A one-year registration on a domain claiming to be an established business is worth noting, though plenty of legitimate firms renew annually.
• Registrar. Useful for patterns across related domains and for knowing where to send an abuse report.
• Nameservers. Often the most useful field for pivoting, because they show which DNS provider the domain uses.
• Status codes. Standard codes such as clientTransferProhibited are routine. Codes such as serverHold or clientHold usually mean the domain has been suspended and will not resolve.

DNS records: how the domain works today

DNS is the public directory that maps names to services. You can query it with dig on Linux and macOS, or nslookup or PowerShell's Resolve-DnsName on Windows. For example, dig example.com MX +short returns the mail servers for a domain.

Record types worth checking

• A and AAAA: the IPv4 and IPv6 addresses where the domain's web service is reached.
• CNAME: an alias pointing one name at another, common for subdomains hosted on third-party platforms. A CNAME to a known platform tells you which service hosts that page.
• MX: the servers that receive email for the domain. A domain with no MX record cannot normally receive mail, which matters if it is being used to send invoices that invite replies.
• NS: the authoritative nameservers. Should match the registration record.
• TXT: free-text records, often holding SPF policies, DMARC policies (at _dmarc.example.com), and domain verification tokens for services such as search consoles, email platforms or office suites. A verification token tells you the owner set up a particular service, though usually not which account.
• SOA: the start-of-authority record, including a contact email field that is often a generic address at the DNS provider.
• CAA: lists which certificate authorities are permitted to issue certificates for the domain.
• PTR (reverse DNS): maps an IP address back to a name, using dig -x. Often shows the hosting provider's generic name for the server.

CAA evidence worksheet: permission is not attribution

CAA describes certificate-issuance policy, not domain ownership or website trustworthiness. RFC 8659, sections 1, 3 and 4, distinguishes current authorization from past issuance: today's records cannot establish what was permitted when an older certificate was issued.

Read the whole applicable record set. issue authorizes an issuer; issuewild takes precedence for wildcard requests when present. iodef supplies a reporting destination, not issuer authorization. A missing CAA answer at one hostname is not the end of the check: the lookup follows aliases and searches successive parent names until it finds a record set or reaches the root. A query error is not evidence of an empty record set.

For an authorized domain review, keep these fields in your evidence log:

• Question: which exact hostname and certificate type are you assessing, and why does that matter to the investigation?
• Observation: UTC collection time, queried name, resolver, response status, returned owner names, TTLs and complete CAA values. Preserve the full response rather than only a screenshot of one issuer.
• Lookup path: distinguish the requested hostname from aliases and the parent name supplying the applicable policy. Label an incomplete lookup as incomplete.
• Comparison: record the certificate's issuer, names and validity interval separately, with its source. Keep the certificate observation time separate from the DNS collection time.
• Assessment: state the supported finding, alternative explanations and the missing evidence needed to resolve them.

Hypothetical example: a researcher sees one issuer in a current CAA response and a different issuer on an older certificate. The worksheet should say, “The current policy and the observed certificate name different issuers; historical policy has not been established.” It should not say, “The certificate was fraudulently issued.” Before escalating the discrepancy, seek dated policy evidence and check that both observations concern the same name and certificate type.

Two domains naming the same issuer do not, by that fact alone, establish common control. Treat a shared issuer as context rather than an attribution link. Do not contact an iodef destination merely to test it, and exclude reporting contact details from public notes unless they are necessary to the finding.

Before closing: can another analyst reproduce the lookup, see which policy applied, and distinguish observation from inference? Use the practical evidence-log guide to retain the supporting record.

Shared infrastructure

Most websites today sit on shared hosting, cloud platforms or content delivery networks. When a domain sits behind a CDN such as Cloudflare, its A records point to the CDN's addresses, which are shared by a very large number of unrelated sites. Even without a CDN, a single shared hosting server can carry hundreds or thousands of domains. Two domains resolving to the same IP address is therefore weak evidence of a connection, unless the address is dedicated and the hosting context supports it.

Historical DNS: useful but partial

Current DNS shows today's configuration. To see how a domain was configured last year, you need historical data. That comes mainly from passive DNS: datasets built by recording the answers that participating resolvers and sensors observe over time. Commercial services such as SecurityTrails and DomainTools offer historical DNS and WHOIS, and VirusTotal shows observed resolutions for domains and IPs.

Treat historical DNS with care:

• It is a sample, not a record. A resolution only appears if someone queried the name through an observed resolver. Low-traffic domains may have large gaps.
• Dates are first-seen and last-seen, not exact start and end times.
• Coverage differs by provider. Two services can show different histories for the same domain. Note which one you used.
• Re-registration resets context. A domain that expired and was bought by someone else will have a history that spans two unrelated owners.

The Wayback Machine complements historical DNS by showing what the website looked like at different dates, which can help you spot changes of ownership or purpose.

Certificate Transparency: the overlooked source

Certificate Transparency (CT), originally specified in RFC 6962, requires publicly trusted certificate authorities to log the certificates they issue in append-only public logs. Major browsers will not trust most publicly issued certificates unless they have been logged. The result is a large, searchable record of certificates for domains and subdomains.

The free service crt.sh lets you search these logs. Entering a domain returns certificates naming it. Searching with a wildcard pattern such as %.example.com returns certificates for its subdomains.

What CT can tell you

• Subdomains that are not linked anywhere, such as staging, mail, portal or vpn.
• Timing. The first certificate often appears within hours or days of a site going live, which can date infrastructure more precisely than the registration date.
• Issuing authority, which can hint at the hosting platform, since many platforms obtain certificates automatically from a particular authority.
• Other names on the same certificate. A certificate covering several unrelated domains suggests they were set up together, though some hosting platforms bundle customer names onto shared certificates.

What CT cannot tell you

A logged certificate proves that a certificate authority issued a certificate for a name. It does not prove the name ever resolved, that a site was served, or who requested it. Wildcard certificates such as *.example.com hide individual subdomain names. Certificates from private, internal authorities are not logged at all. Also note that you are seeing the subdomain names only, so treat them as leads, not as a map of the organization.

A worked example

Suppose a staff member at a small accounting firm forwards you an email asking clients to "update their payroll details" at northfield-payroll.example, a name similar to the firm's real domain. The firm has asked you to assess the domain so it can warn clients and report it. That is a defensive, authorized purpose.

Registration. An RDAP lookup shows the domain was created eight days ago, registered for one year, with registrant details redacted and a country listed that differs from the firm's location. The nameservers belong to a large DNS provider.

Current DNS. The A record points to an address in the documentation range for this example, 203.0.113.40. Reverse DNS returns a generic hostname for a budget hosting provider. There is an MX record pointing to a mainstream email service, and a TXT record containing an SPF policy that authorizes that service. There is no DMARC record.

Certificate Transparency. crt.sh shows the first certificate for the domain issued six days ago, along with a second certificate for login.northfield-payroll.example and secure.northfield-payroll.example. A search for other domains on the same certificates returns nothing further.

Historical DNS and archives. Passive DNS has only two observations, both in the last week. The Wayback Machine has no captures before this month.

Assessment. You can state with high confidence that the domain was registered very recently, was configured to send and receive email, and has subdomains named in a way consistent with credential collection. You cannot state who registered it. You note that the IP address is on shared hosting, so other domains on it are not evidence of common ownership. You recommend the firm report the domain to the registrar's abuse contact, warn clients, and publish a DMARC policy on its own real domain.

What you cannot conclude

• Ownership from redacted records. A privacy service or redaction tells you nothing about who is behind a domain.
• Common control from a shared IP address, especially on CDNs and shared hosting.
• Common control from a shared registrar or DNS provider. The largest providers serve millions of customers.
• Continuous ownership from a domain's age. Expired domains are routinely re-registered by new owners.
• Malice from configuration alone. New domains, one-year registrations and privacy services are normal. They raise questions that the content and context must answer.
• Completeness of historical data. Gaps in passive DNS reflect coverage, not inactivity.

Ethics and legality

Querying public registration data, DNS and CT logs is lawful and routine. The line is crossed by what you do next. Do not scan, probe or attempt to log into hosts you discover, including subdomains found in CT logs, unless you are authorized to test them. Respect the terms of service of commercial data providers, particularly limits on bulk queries. Registration data that is still visible for individuals is personal data, so collect only what your question requires. Requests for redacted registration data should go through the registrar's or ICANN's formal disclosure process, with a legitimate basis, not through pretexting.

Checklist

• State the question and confirm an authorized purpose.
• Pull RDAP data and record creation, expiry, registrar, nameservers and status codes.
• Query current A, AAAA, CNAME, MX, NS, TXT, SOA and CAA records, plus reverse DNS on key IPs.
• Check whether the IP addresses belong to a CDN or shared host before treating them as pivots.
• Search CT logs for the domain and its subdomains, and note first-issuance dates.
• Review historical DNS and archived pages, recording which provider you used.
• Check for re-registration before treating domain age as meaningful.
• Write findings with confidence levels and list what you cannot conclude.
• Do not probe or access discovered hosts without authorization.