tldx: bulk domain availability checks over RDAP, DNS and WHOIS

What tldx actually solves for naming work

Checking one domain by hand is trivial. Checking the cross product of five keywords, three prefixes, four suffixes and six TLDs is not, and that is the shape of the problem tldx targets. The README frames it as brainstorming: "tldx helps you brainstorm available domain names fast." The input is a keyword, or several, and the output is candidate domains marked available or not.

The people this fits are developers and founders running a naming pass, and anyone scripting that pass. A single call like `tldx openai -p get,use -s ly,hub -t com,io,ai --only-available` produces the combinations and filters them down to the available ones as they stream in, which is the loop most people end up writing by hand in a shell script with `whois` and `sleep`.

It is not a registrar. It does not reserve, price or purchase anything, and it does not tell you whether a name is legally usable. Treat the output as a shortlist generator, not a decision.

How the availability check is wired: RDAP first, WHOIS and DNS alongside

The repository description names three lookup paths: RDAP, DNS and WHOIS. The dependency list backs that up. `go.mod` requires `github.com/openrdap/rdap v0.10.1` for RDAP queries, plus `github.com/likexian/whois v1.15.7` and `github.com/likexian/whois-parser v1.24.21` for WHOIS and its parsing. The README's feature list says checks run concurrently over RDAP and that results stream as they are found, which is why output appears line by line rather than in one block at the end.

That concurrency is the main reason this beats a naive loop. A shell loop over hundreds of candidates is serial, and each lookup waits on a registry server. tldx fans the checks out and prints each result when it lands.

There is a hard ceiling on expansion. The README states that patterns expanding to more than 500,000 combinations are skipped, so `tldx '[a-z]{5}' --regex` is not something the tool will attempt. That limit is a deliberate guard against a regex that would otherwise spawn an unbounded number of network calls.

Installing tldx and running a first filtered check

The README has an Installation section but the excerpt here does not include the commands, so the concrete install steps are not something I can reproduce. Go to that section of the repository README, or the release page for v1.6.0, for the current method.

Once installed, the shortest useful invocation is a single keyword against one TLD, which prints one line per candidate. The README gives this exact example:

tldx google
❌ google.com is not available

The next step is the one most people actually want: permutations plus a filter, so only names worth pursuing are printed.

tldx openai -p get,use -s ly,hub -t com,io,ai --only-available

The README shows output lines such as `getopenaily.com is available` and `useopenaihub.io is available`. Note the exit code documented in the usage text: `2` is returned when `--only-available` is set and nothing available is found. That makes the command usable in a script or CI step without parsing output.

For a reusable shortlist, set a default preset so you do not retype TLDs every run:

tldx preset default nordic

The README states this writes to `~/.config/tldx/config.toml`. Presets are created with `tldx preset add myteam com io ai`, listed with `tldx preset list` and removed with `tldx preset remove myteam`.

Regex expansion and the 500,000 combination ceiling

The `--regex` flag changes the meaning of the keyword argument: each keyword becomes a pattern, and every string it expands to is checked. The README's example is all three-letter .com domains:

tldx '[a-z]{3}' --regex --tlds com --only-available

Patterns compose with prefixes and suffixes, so `tldx '[a-z]{2}' --regex --prefixes my,get --tlds app --only-available` checks every two-letter combination under both prefixes on `.app`. That is 26 squared times two, which is small, but the same syntax with a wider character class or a longer quantifier grows multiplicatively and quickly runs into the documented 500,000 limit.

The practical consequence: regex mode is for bounded, deliberate sweeps, not for exploring an open-ended space. If you want everything under a TLD, the tool will refuse rather than hammer registries. That is the right default, but it means you should size the pattern before you run it, not after.

Output formats, streaming and where the pipeline breaks

The `-f` flag takes `text`, `json`, `json-stream`, `json-array`, `csv`, `grouped` or `grouped-tld`. For interactive use, text with color is fine and `--no-color` exists for logs. For anything downstream, `json-stream` is the interesting one: it matches the streaming behaviour of the checks, so a consumer can process results as they arrive instead of waiting for the whole run. `csv` and `json-array` suit a spreadsheet or a one-shot parse.

The `grouped` and `grouped-tld` formats exist because a flat list of a few hundred domains is hard to read; grouping by keyword or by TLD is a presentation choice, not a data one.

Where this breaks down is coverage. RDAP is not uniformly deployed across every TLD, and the README does not document a fallback table or a per-TLD coverage list. The presence of WHOIS dependencies in `go.mod` suggests WHOIS is used somewhere in the lookup path, but the README excerpt does not spell out the order of precedence or what happens when RDAP has no endpoint for a TLD. If a check comes back unavailable for an obscure ccTLD, confirming it against the registry directly is the safe move.

For-sale detection, presets and the config file

Two features go beyond plain availability. The first is RFC 10023 for-sale detection: `--for-sale` checks taken domains for a `_for-sale` TXT record, and `--only-for-sale` narrows output to taken domains advertised for sale. That is a different question from "is this free", and it is the one people ask after a shortlist comes back fully taken. Not every registrar or owner publishes such a record, so an empty result means "none found this way", not "nothing is for sale".

The second is presets. Built-ins include `all`, `cheap`, `popular`, `tech` and `geo`, and the README shows `tldx preset list` printing each with its TLDs. Custom presets are stored in `~/.config/tldx/config.toml`, the same file that holds the default preset. The README notes the config file can also carry your usual flags, which is the mechanism for making `tldx mystartup` behave consistently across a team without a wrapper script.

Defaults set this way are global to the user, not per-project. If two projects want different TLD sets, you are switching the default or passing `--tld-preset` explicitly each time.

tldx versus a scripted whois loop

The obvious alternative is a shell loop over `whois` or `dig`, and the difference is not cosmetic. A serial loop against a few hundred candidates is slow and gets rate-limited, because each lookup blocks and there is no concurrency control beyond whatever you write. tldx runs checks concurrently over RDAP, which is a structured, HTTP-based protocol with machine-readable responses, and streams results.

The second difference is input handling. A shell loop needs you to generate the candidate list yourself, which means writing the prefix, suffix and TLD cross product by hand or with a nested loop. tldx does that expansion internally, including regex patterns and presets, and it reads keywords from a file or stdin with `-i`, where `-` means stdin. That matters when the keywords come from another tool.

The trade-off is transparency. With a whois loop you see exactly which server answered and what it said. With tldx you get a verdict line, and when a verdict looks wrong you have to go to the registry yourself to find out why.

MCP, maintenance and licence

The `tldx mcp` command starts an MCP server over stdio, built on `github.com/mark3labs/mcp-go v0.58.0`. The README describes it as a server for AI agents. The practical effect is that an agent can call tldx as a tool instead of shelling out and parsing text, which is the reason to care about it.

On maintenance: the repository is not archived, and the last push was on 2026-09-07. Releases are frequent enough to matter, with v1.6.0 on 2026-08-13, v1.5.0 on 2026-06-03 and v1.4.0 on 2026-05-24. Releases are cut with semantic-release, configured in `package.json` alongside `@semantic-release/changelog` and `@semantic-release/git`, so `CHANGELOG.md` is generated rather than hand-written. The build uses GoReleaser (`.goreleaser.yml`) and the module declares `go 1.26.0`, so building from source requires a Go toolchain at least that new.

Licence is Apache-2.0, in both the repository metadata and `package.json`. That is a permissive licence with an explicit patent grant and a requirement to preserve notices; it is not legal advice, and if you redistribute a modified binary you should read the terms yourself. The `package.json` is only the release tooling, not a Node runtime dependency, so you do not need Node to use tldx.

Editorial conclusion

Adopt tldx if you generate name candidates faster than you can check them by hand: the permutation flags, regex expansion, presets and JSON or CSV output cover a naming sprint well, and the MCP server fits agent workflows. Do not adopt it as a registrar-side availability oracle or as a trademark screen; RDAP reflects registry data, not purchase eligibility, and the README does not document any legal or trademark check. Before relying on a result, verify the specific TLD you care about is covered by RDAP, and confirm the candidate at your registrar before you commit to a name.

Frequently asked questions

Official sources

1. brandonyoungdev/tldx on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases