Look up any domain. See who owns it, when it expires, and how it's locked down.

A single lookup unifies three previously separate calls — RDAP for registration data, DNS for nameserver resolution, and an AI layer that turns raw fields into plain-language insight. Six dimensions are returned:

A WHOIS or RDAP record is the closest thing a domain has to a public birth certificate. Age, ownership, lock posture, and DNSSEC together answer questions that nothing else on the open web can:

• Is this domain old enough to trust? Domains under 90 days old account for the majority of phishing and malware infrastructure. Registration date is the single fastest screen for new threats.
• Is it locked against hijack? A domain without transfer and update locks can be socially engineered away from its owner. Server-side locks (set by the registry) are stronger than client-side ones.
• Who actually controls it? Registrar IANA ID, abuse contact, and nameserver provider together reveal the operational owner — even when WHOIS contact data is redacted under GDPR.
• Is DNS tamper-resistant? Unsigned domains are vulnerable to cache poisoning and DNS spoofing. DNSSEC presence is now a baseline for any production property handling sensitive data.

RDAP (Registration Data Access Protocol) is ICANN's structured JSON successor to legacy WHOIS. It's machine-parseable, standardized, and supported by every gTLD registry since 2019. We query it first; if the TLD doesn't yet support RDAP, we fall back to port-43 WHOIS and normalize.

• Stage 1 — Resolve the authoritative RDAP endpoint Look up the TLD's RDAP server from the IANA bootstrap file, then query the registry directly. For .com, that's rdap.verisign.com.
• Stage 2 — Fetch the domain record Pull registration events, status codes, registrar entity, abuse contact, DNSSEC delegation data, and the nameserver list.
• Stage 3 — Resolve nameserver IPs For each authoritative nameserver, issue A and AAAA queries with TTL capture. Identical IPs across nameservers usually indicate an Anycast network.
• Stage 4 — Normalize and de-redact Where contact fields are redacted under GDPR/RDPP, surface the abuse contact (which must remain public per ICANN policy) so you always have a reachable point of contact.
• Stage 5 — Run AI analysis Feed the structured record to the analyzer. Returns five insight cards covering longevity, security, registrar, DNSSEC, and nameserver topology.

{
  "domain": "cloudflare.com",
  "tld": "com",
  "details": {
    "dates": {
      "creationDate":  "2009-02-17T22:07:54.000Z",
      "expiryDate":    "2033-02-17T22:07:54.000Z",
      "updatedDate":   "2024-01-09T16:45:28.000Z"
    },
    "registrar": {
      "name":     "Cloudflare, Inc.",
      "ianaId":   "1910",
      "abuseContact": {
        "email": "[email protected]",
        "phone": "+1.6503198930"
      }
    },
    "status": [
      "client delete prohibited",
      "client transfer prohibited",
      "client update prohibited",
      "server delete prohibited",
      "server transfer prohibited",
      "server update prohibited"
    ],
    "dnssec": {
      "signed":  true,
      "dsData": [{ "keyTag": 2371, "algorithm": 13, "digestType": 2 }]
    },
    "nameServers": [
      { "name": "ns3.cloudflare.com" },
      { "name": "ns4.cloudflare.com" },
      { "name": "ns5.cloudflare.com" },
      { "name": "ns6.cloudflare.com" },
      { "name": "ns7.cloudflare.com" }
    ],
    "source": "rdap"
  },
  "AiAnalysis": {
    "analysis": [ /* 5 insight cards */ ]
  }
}

Status codes (formally, EPP codes) describe the lifecycle and security state of a domain. Codes prefixed with `client` are set by the registrar and can be lifted by the account holder. Codes prefixed with `server` are set by the registry — only the registry operator (e.g., Verisign for .com) can lift them. Server codes are strictly stronger.

• clientDeleteProhibited / serverDeleteProhibited The domain cannot be deleted via the standard delete command. Most well-managed domains carry at least the client variant to prevent accidental loss.
• clientTransferProhibited / serverTransferProhibited The domain cannot be transferred to another registrar. The single most important lock against domain hijacking — turn it on for every domain you own.
• clientUpdateProhibited / serverUpdateProhibited Contact info, nameservers, and DNSSEC records cannot be modified. Common on production domains to prevent unauthorized nameserver changes.
• clientHold / serverHold The domain is suspended from DNS resolution — it won't resolve in the public DNS until the hold is lifted. serverHold often indicates a registry-level dispute, abuse complaint, or unpaid renewal.
• pendingTransfer A transfer to a new registrar is in flight. Resolves within 5–7 days unless cancelled by the registrant or rejected by the losing registrar.
• pendingDelete / redemptionPeriod The domain is being wound down. redemptionPeriod is the 30-day grace window during which the original owner can still recover the domain (usually for a steep fee).
• autoRenewPeriod The domain just auto-renewed. The registrant has a 45-day window during which the renewal can be reversed for a full refund.
• ok / active No restrictions are in place. Counter-intuitively, this is the weakest security posture — anyone with registrar credentials can modify or transfer the domain immediately.

DNSSEC adds cryptographic signatures to DNS records so resolvers can detect tampering. The `signed` flag, DS records, key tag, and algorithm together describe the domain's posture:

• signed: true DNSSEC is fully deployed and the parent zone holds a matching DS record. Validating resolvers will reject any forged response for this domain.
• signed: false DNSSEC is not deployed. The domain is vulnerable to DNS spoofing and cache-poisoning attacks. Adoption is still below 10% across .com — but mandatory for finance, healthcare, and government properties.
• DS record The Delegation Signer record published at the parent zone (e.g., .com). It cryptographically links the parent to the child's DNSSEC keys.
• keyTag A short integer identifying the specific DNSKEY (e.g., 2371 in the sample). Unique per zone, used by resolvers to match a signature to its key.
• algorithm 13 (ECDSA P-256 / SHA-256) Modern recommended algorithm. Small signatures, fast verification, well-supported. The current default for new DNSSEC deployments.
• algorithm 8 (RSA / SHA-256) Older but still widely used. Larger signatures and slower verification than ECDSA, but compatible with every validating resolver in existence.
• digestType 2 (SHA-256) The hash algorithm used to fingerprint the DNSKEY inside the DS record. SHA-256 is current best practice; SHA-1 (digestType 1) is deprecated.

Raw RDAP responses are dense, technical, and contextless — fine for machines, hostile for humans. The AI layer reads the structured record and returns five plain-language observations covering the dimensions a human domain analyst would check first.

{
  "title":  "Robust Domain Security Status",
  "value":  "All Client/Server Transfer, Delete, Update Prohibited",
  "insight": "The domain exhibits a comprehensive suite of security locks (client/server delete prohibited, transfer prohibited, update prohibited). This robust protection prevents unauthorized modifications, transfers, or deletions, signifying a high security posture and strong control over the domain."
}

Every field on this page is available as JSON. The free tier is rate-limited per IP and suitable for ad-hoc lookups. For monitoring, portfolio audits, or CI use, request an API key.

curl https://api.domainscan.in/v1/lookup?domain=cloudflare.com

const res = await fetch(
  'https://api.domainscan.in/v1/lookup?domain=cloudflare.com'
);
const report = await res.json();

const ageYears =
  (Date.now() - new Date(report.details.dates.creationDate)) /
  (365.25 * 24 * 3600 * 1000);

console.log(report.details.registrar.name, ageYears.toFixed(1));
// "Cloudflare, Inc." 16.0

{
  "domain": "string",
  "tld":    "string",
  "details": {
    "dates": {
      "creationDate":    "ISO 8601",
      "expiryDate":      "ISO 8601",
      "updatedDate":     "ISO 8601 | null",
      "transferDate":    "ISO 8601 | null",
      "lastRDAPUpdate":  "ISO 8601"
    },
    "registrar": {
      "name":         "string",
      "ianaId":       "string",
      "whoisServer":  "string | null",
      "url":          "string | null",
      "abuseContact": { "email": "string", "phone": "string" }
    },
    "contacts": {
      "registrant":     "object | null (often redacted)",
      "administrative": "object | null",
      "technical":      "object | null",
      "billing":        "object | null"
    },
    "status":  ["EPP status code"],
    "dnssec":  {
      "signed":  "boolean",
      "dsData":  [{ "keyTag": "number", "algorithm": "number", "digestType": "number", "digest": "hex string" }],
      "keyData": []
    },
    "nameServers": [
      { "name": "string", "ipv4": ["string"], "ipv6": ["string"] }
    ],
    "source": "rdap | whois"
  },
  "AiAnalysis": {
    "domain":   "string",
    "analysis": [
      { "title": "string", "value": "string", "insight": "string" }
    ]
  }
}

Six patterns we see most often:

• What's the difference between WHOIS and RDAP? WHOIS is the legacy protocol — plain text, port 43, no standardized format, every registry returns slightly different fields. RDAP is the modern replacement — JSON over HTTPS, formally specified by ICANN, with stable field names. All gTLDs and most ccTLDs now support RDAP. This tool queries RDAP first and falls back to WHOIS only for the handful of TLDs that don't yet support it.
• Why is the registrant contact info hidden? Since GDPR (2018) and ICANN's Registration Data Policy (RDPP, 2024), most personal contact fields in WHOIS are redacted by default for individual registrants. The abuse contact at the registrar level remains public per ICANN policy — that's your reachable channel for any takedown, dispute, or security report.
• What does "clientTransferProhibited" mean? Your registrar has set a lock that prevents the domain from being transferred to another registrar. It's the single most important lock against domain hijacking. To transfer the domain elsewhere, you (or an attacker) would first need to remove this flag via your registrar account — which is exactly the friction it's designed to create.
• How do I know if a domain is for sale? A domain lookup alone doesn't tell you — there's no "forSale" field in WHOIS or RDAP. But common signals are present: a parking-page nameserver (e.g., parked on Sedo, Afternic, DAN.com), recent registration with a single-page site, or registrant identity matching a known domain broker.
• Why does cloudflare.com use ns3–ns7.cloudflare.com instead of generic DNS? Branded nameservers are typical for companies that operate their own DNS infrastructure at scale. In Cloudflare's case, all five nameservers resolve to the same Anycast IP range — meaning queries are routed to the geographically nearest node, not to a specific physical server. It's a sign of operational sophistication, not a configuration anomaly.
• What is DNSSEC and should I enable it? DNSSEC adds cryptographic signatures to DNS records, so resolvers can detect if a response has been tampered with in transit. Enabling it requires registrar support plus a DS record published at your parent zone. For most production properties — anything handling auth, payments, or sensitive data — it's now baseline. For a marketing site, it's nice-to-have but not critical.
• How accurate is the AI analysis? The insights are generated from structured RDAP/DNS fields, so the underlying facts are exact. The interpretation layer is opinionated — it flags older domains as more reputable, server-side locks as stronger, branded nameservers as a sophistication signal. These are well-accepted heuristics, but they're heuristics. The raw data is always exposed in the Raw Data tab if you want to draw your own conclusions.
• How often does WHOIS/RDAP data update? Each lookup queries the authoritative registry in real time — no caching, no scraped databases. The `lastRDAPUpdate` field tells you when the registry itself last refreshed its record (typically within minutes of any registrar-side change). Historical WHOIS snapshots are a separate dataset and aren't covered by this tool.