1. Normalize the request
Prepare
Inputs are normalized, duplicate combinations are removed, and the domain and TLD limits for the current plan are applied before network requests begin.
Better domain decisions need more than a green badge.
axath brings idea generation, availability signals, shortlisting, project research and ongoing monitoring into one workflow, while keeping uncertainty and data handling visible.
591
extensions in the catalog
500–5,000
domains per check
4
independent data sources
4
honest result states
Keep the whole naming decision connected.
Finding an available domain is rarely one lookup. It is a sequence of generating, eliminating, comparing, documenting, and discussing candidates.
01
Generate
Explore your own candidates or use analog and AI generation to find additional naming directions.
Explore02
Check
Check candidates across the extensions that matter and keep ambiguous responses separate from confident results.
Explore03
Shortlist
Save the names worth comparing, including registered domains you may want to investigate on the aftermarket.
Explore04
Organize
Add finalists to projects, attach notes, import domain files, and share view-only research links.
Explore05
Monitor
Watch the names you own and the ones you want. Domain Hub records every registry and DNS change and emails you when something matters.
ExploreFast where possible, authoritative where necessary.
DNS and RDAP answer different questions. Clear DNS delegation is treated as registered, consistent NXDOMAIN responses are marked as appears available with manual verification advised, and ambiguous DNS responses continue to RDAP.
2. Read clear DNS signals
Pre-screen
An NS or SOA answer is strong evidence that a domain is delegated and registered. Consistent NXDOMAIN responses are shown as appears available with a manual-verification flag.
3. Send ambiguous results to RDAP
Verify
Timeouts, empty DNS answers, and other ambiguous cases are routed to the registry endpoint published through IANA or a narrowly verified registry-operated override. If no dependable RDAP source exists, the checker returns an uncertain result instead of guessing.
4. Preserve uncertainty
Report
The parser returns appears available, registered, unknown, or error. Rate limits, incomplete data, and contradictory signals are not silently converted into availability.
Why RDAP?
RDAP is the HTTPS and JSON-based successor to legacy WHOIS. axath uses the IANA DNS bootstrap to discover endpoints instead of maintaining a static list of registry ownership that can silently become outdated.
The bootstrap is cached in memory for 24 hours. Individual successful lookup results may also be held briefly in a bounded in-memory cache, while errors remain retryable.
| Capability | WHOIS | RDAP |
|---|---|---|
| Response | Unstructured text | Structured JSON |
| Transport | Port 43 | HTTPS |
| Discovery | Often manual | IANA bootstrap |
| Errors | Provider-specific text | HTTP status plus RDAP body |
| Internationalization | Inconsistent | Designed for internationalized data |
Four states, without false precision.
Appears available
RDAP returned a standards-shaped not-found response, or the DNS pre-screen consistently returned NXDOMAIN. DNS-only results are marked for manual verification, and the registrar remains the final confirmation point.
Registered
The checker found positive DNS delegation or a valid RDAP domain record. Published registration and expiration dates are shown when the registry provides them.
Unknown
The response was reachable but did not establish either state. Access may have been denied, the data may have been contradictory, or the body may not have been safely recognizable.
Error
The lookup failed because of a timeout, network problem, rate limit, or server failure. Error results are not cached as a registration verdict and can be retried.
Registrar confirmation still matters
Registration state can change between lookup and checkout, and public data may not reveal reserved, premium, or policy-restricted names. Confirm the final price and availability with a registrar before paying.
Four sources, each doing one job.
No single source can answer every question about a domain. Registration state, delegation, the full list of names in a zone, and what a name costs to keep are four different problems, and mixing them is how tools end up confidently wrong.
Per request, bootstrap cached 24h
RDAP registry data
The authoritative registration record: status codes, registrar, creation and expiry dates. Endpoints are discovered through the IANA bootstrap so the registry that actually operates each extension is queried directly, never an intermediary cache.
Per request
DNS over HTTPS
Two independent resolvers, Cloudflare and Google, answer the fast pre-screen and provide the record sets behind DNS monitoring. Using two means a single provider outage or a single inconsistent answer does not become your result.
Daily, 05:15 UTC per zone
ICANN CZDS zone snapshots
A daily authorized snapshot of the delegated names in each approved zone. Every download is validated on its gzip stream, byte size, and delegated-name count before it is promoted, the two newest good snapshots are retained, and a partial or malformed download never replaces a working one.
Daily, 03:30
Registrar pricing
Published first-year and renewal prices across registrars, so results carry the cheapest real renewal rather than a promotional teaser rate. Synced on its own schedule and independent of any availability lookup.
Built to record what changed, not just that something did.
Domains fail silently. Nothing tells you when a nameserver moves or a certificate lapses, so Domain Hub is designed around detecting change and keeping the evidence.
One record per domain, not per user
Domain Hub keeps a single shared registry record and one DNS snapshot per unique monitored domain. Ten people watching the same name produce one lookup, not ten, which is what makes monitoring at portfolio scale affordable.
Diffed, not just re-read
Each refresh compares the new record set against the stored one and ignores TTL-only churn. What gets recorded is the change itself, with the previous value beside the new one, so you can tell at a glance whether it was your own team.
Lifecycle, not just an expiry date
Registry refreshes write lifecycle transitions to their own event log. The Hub reads which phase a name is actually in, projects the release date, and narrows the estimate as each phase confirms.
Security observations
Alongside registry facts, each domain gets a live TLS certificate probe and an authoritative DNS consistency check across its nameservers. Disagreement between authoritative servers is a first-class monitoring event.
Durable retries, handled on our side
Work runs through a persistent job queue that retries four times. Beyond that, a database-backed counter backs the domain off to 1 hour, then 6, then a capped 24-hour cadence, and our own alerting reports it to us. A failed check is our job to fix, so the Hub keeps showing the last verified facts with the time they were checked instead of handing you an error.
Failures never overwrite facts
A lookup that fails preserves the previous known state. The Hub will tell you it could not confirm something before it will tell you something untrue.
One digest. Two lanes. Never noise.
Notifications are opt-in and arrive as one combined digest rather than one message per domain. Urgent and routine alerts travel in separate lanes, each capped at one message per day, so a routine summary can never swallow a registrar transfer or a nameserver change that happened an hour later.
No relevant event means no email. Archived and paused domains are excluded. Every message carries a direct unsubscribe link and one-click unsubscribe headers, and delivery logs record only operational metadata, never domains or message content.
| Lane | Trigger | Frequency |
|---|---|---|
| Urgent lane | Pending delete, redemption, or expiry within 7 days | At once for an incident, warnings at most daily |
| Routine lane | Expiry 8 to 30 days away | At most weekly |
| Routine lane | Other registry and DNS changes, monitoring failures | Your daily, weekly or monthly cadence |
| Always urgent | Registrar transfer, nameserver change, TLS expiry, authoritative DNS mismatch | Sent as found |
Scheduled workers
Monitoring work is swept into the queue every five minutes, digests are evaluated each morning, and zone and pricing syncs run overnight on their own timers. Each worker is a separate unit, so one failing job cannot stall the others.
Heartbeats and alerting
Every scheduled worker records a heartbeat. A missing or stale heartbeat, two consecutive health-check failures, a queue backend failure, a billing webhook error, or a certificate inside 14 days all raise an immediate operational alert.
Alerts carry no user data
Operational alerts never contain domains, prompts, user data, request bodies, provider payloads, credentials, or database error details. They carry the signal and nothing else.
What stays local, what is stored, and what leaves the server.
Account features and the operation of the service require some persistence, and pretending otherwise would be easier than it is honest. This is the actual model, row by row.
Browser preferences
Theme, preferred extensions, currency display, and similar interface preferences stay in browser storage on the current device.
Visitor shortlist
Anonymous visitors can keep a small shortlist in browser storage. Anonymous history is session-only and is not synced as a personal account history.
Account features
Signed-in history, shortlist items, projects, project domains, notes, and share-link records are stored in Supabase so they can sync across devices.
Aggregate check analytics
The service records aggregate counts such as batch size, result totals, selected TLDs, and duration. The analytics row does not store the raw domain names from the check.
Interest and abuse protection
Short-lived domain-interest signals use keyed hashes of domains and visitors. Anonymous quota and rate-limit records use pseudonymous identifiers rather than raw browser fingerprints.
Lookup providers
Checking necessarily sends the queried domain to DNS-over-HTTPS providers and RDAP registry or fallback endpoints. Those external services receive the lookup needed to answer the request.
Check the names you are considering.
No account is required to run a check. Create one only when you want synchronized research tools.