DC5 WHOIS

Check an AS_PATH against the published ASPA objects (RPKI attestations of which providers a network authorises), following the verification procedure of draft-ietf-sidrops-aspa-verification. The result is valid, invalid or unknown, with the reason and the first hop that broke the path. Use it to find out whether a path shows a route leak or an unauthorised provider. "Unknown" only means some network on the path published no ASPA; it is not a fault. Behavior: offline, answered from the local RPKI snapshot. The procedure is an Internet-Draft, not an RFC, and the neighbor-AS and AS_SET prerequisite checks of a real router are left out. Only the path is read; it is neither stored nor logged.

Check whether one domain or Web3 name is a visual look-alike (homograph): letters from different scripts mixed in one label, or every non-ASCII letter having a Latin twin, so раураl.com reads as paypal.com. Returns the scripts used and the Latin name it imitates. Use it to screen candidate or incoming names quickly (phishing triage, brand monitoring). lookup_target already includes this warning for the name it looks up, so there is no need to call both for one name. Behavior: offline and instant; no DNS, registry or network call. It catches script tricks only, not typos or digit swaps such as paypa1.com, so a clean result does not mean the domain is safe.

Grade one domain's email authentication and list every check: SPF (single record, the 10 DNS-lookup limit across includes, the all qualifier), DMARC (policy, inheritance from the organizational domain, pct, report addresses), MTA-STS, TLS-RPT, BIMI, DANE and null MX. The level is strong, fair, weak, no_mail (domain declares it sends no mail) or none (no MX, SPF or DMARC at all). Use it for questions about spoofing, deliverability or a DMARC rollout. lookup_target gives only the overall grade; this tool gives the status and a one-line finding for each check. Behavior: reads public DNS only and never connects to the domain's mail servers, so it cannot test SMTP TLS, certificates or whether a mailbox exists. Usually under 2 s.

Check one (prefix, origin AS) pair against the public records: RPKI route origin validation (RFC 6811), the routing registries (IRR route objects) and how many RIPE RIS peers see that origin for the prefix. Use it to answer whether an AS is authorised to originate a prefix, why a route may be dropped by networks that filter on RPKI, or whether a registry object matches an announcement. For everything about one prefix or AS use lookup_target instead. Behavior: offline, answered from local snapshots; the result lists only the datasets this instance has loaded. RPKI "invalid" can be a stale ROA and an IRR object is a claim, so neither is proof of a hijack or of authorisation. A prefix RIS does not see may still be announced to peers it does not have.

Facts about one top-level domain from local datasets: whether it is delegated in the root zone, its type (country-code or infrastructure when derivable), the registry's RDAP server, root-zone name servers, whether the root zone publishes a DS record (DNSSEC) and which DS algorithms, and any Web3 namespace that claims the same label (for example .eth, .crypto, .bnb, or a collision such as .xyz). Use it to answer where to send an RDAP query for a TLD, whether a TLD is signed, or whether a name under it could mean something else on a blockchain. For one domain use lookup_target instead. Behavior: offline and instant, answered from synced IANA and root-zone data; makes no network call. A field without data is omitted, never guessed. Registry operator and delegation date are not included.

List the local datasets and feeds behind lookup_target (RIR delegations, IANA, Public Suffix List, cloud / CDN ranges, Tor and Private Relay, reputation lists, GeoLite2) with state, record count, generation date and a stale flag. Use it to judge how current a reputation, RIR, cloud or geolocation answer is, or to explain why such a section is missing from a lookup (dataset not loaded or stale). Registry, DNS and Web3 data are fetched live and are not listed here. Behavior: takes no arguments and makes no external calls.

Look up up to 10 domains, IPs, CIDRs, ASNs or Web3 names in one call and get one short line per target (type, registrar and expiry, nameservers, network owner, origin AS, cloud, reputation, Web3 status) plus the same facts as structured fields and a details_url for each. Use it to triage a list, for example the domains in a phishing report or the IPs in a log excerpt. For the full fact sheet of one target use lookup_target. Behavior: each target is a live lookup like lookup_target and counts against the same rate limit, so a long list can hit it; targets that were refused say so and can be retried later. Up to 3 run at once, the whole call is cut off after about 22 s and targets that did not finish say so. One failing target does not fail the others.

Look up one domain, IP address, CIDR block, ASN (AS15169), EVM address (0x…) or Web3 name (ENS .eth, Unstoppable, SPACE ID .bnb, Handshake hns:) and get a compact fact sheet. Domains: registrar, dates, status, nameservers, DNS records, overall mail-security grade, third-party services seen in DNS, possibly dangling records. IPs, CIDRs and ASNs: network owner, origin AS, RIR, cloud / CDN provider, Tor or iCloud Private Relay tag, geolocation, abuse contact, local reputation. Web3 names: registration status, addresses, records, ENS expiry. A 0x EVM address: its ENS primary name on Ethereum, Base, Optimism, Arbitrum, Linea and Scroll (reverse lookup). A look-alike warning is added when the name uses deceptive letters. Use it first for any question about who owns, runs, hosts or registered something. Prefer check_mail_security when you need each email check rather than the grade, and check_lookalike to screen many names without network calls. Behavior: queries registries, DNS and (for Web3) blockchain RPC live, usually in 1-5 s, at most about 12 s. If one source fails, the rest is still returned and the failure is listed under errors. Reputation covers local blocklists only: no match is not a clean bill of health. Queries are not logged or stored. The result ends with details_url, the full page with every record and its provenance.