Open-Domain
Wildcard DNS for IP addresses. Free, stateless, open source.
Serving since 1 August 2026. Both suffixes resolve through the public DNS hierarchy. One caveat, stated plainly: they are answered by one resolver on one machine, so a failure there takes both down at once. A second nameserver in a separate location is the next piece of work.
If your use is production-critical today, nip.io and sslip.io have run this for over a decade on more machines than we have.
Open-Domain is a DNS service that, when queried with a hostname that has an IP address embedded in it, returns that IP address. Append .a-i.st to an IP and you have a working hostname — no signup, no API key, no dashboard, and nothing to wait for.
Every answer is computed from the query name itself. There is no database and no stored record: 203.0.113.10.a-i.st resolves to 203.0.113.10 because the name says so.
The service is designed around two domains, a-i.st and a-i.sh, which are interchangeable — the same name works under either. They are separate registrations, so a problem at one registry or registrar does not reach the other.
That protects against a registry problem and nothing else. Both suffixes are answered by one resolver on one machine today, so they fail together. Independent nameservers in separate locations are the next piece of work, and until they exist this is a single point of failure — which is the honest reason for the notice at the top.
The two names are also how the delegation holds itself up: a-i.st is served by ns1.a-i.sh and ns2.a-i.st, and so is a-i.sh. Each zone keeps one nameserver inside itself (resolved by a glue record at the registry) and one in the other zone, which satisfies the two-nameserver rule both registries impose without inventing a third domain.
Examples #
| Hostname | Resolves to | Notes |
|---|---|---|
| 203.0.113.10.a-i.st | 203.0.113.10 | dot separators (IPv4) |
| 203-0-113-10.a-i.st | 203.0.113.10 | dash separators — use this for wildcard TLS |
| 203.0.113.10.a-i.sh | 203.0.113.10 | the other domain, same answer |
| www.192.168.0.1.a-i.st | 192.168.0.1 | any prefix is ignored |
| www-192-168-0-1.a-i.st | 192.168.0.1 | prefix + dashes |
| 0a000001.a-i.st | 10.0.0.1 | hexadecimal notation (8 digits) |
| 2001-db8--1.a-i.st | 2001:db8::1 | IPv6 — always dashes, never dots |
| foo.bar.a-i.st | NXDOMAIN | no IP address in the name |
| example.com | REFUSED | outside our zones |
Try it:
dig +short 203.0.113.10.a-i.st
dig +short 203.0.113.10.a-i.sh
HTTPS #
A dotted name such as 1.2.3.4.a-i.st has too many labels for a single *.a-i.st wildcard certificate to cover. The dashed form collapses the IP into one label, so 1-2-3-4.a-i.st is matched by an ordinary wildcard certificate and HTTPS works normally. Let's Encrypt will not issue a certificate for a bare IP address, but it will for a hostname — which is what this gives you.
For agents and automated tools #
The hostname is a pure function of the IP: no lookup, no state, no registration step. An agent that has just been handed a public IP can construct its own address without asking anyone.
Machine-readable copies of everything here, cheaper to parse than this page: /llms-full.txt is a complete self-contained reference, /llms.txt is the short index, and every page has a Markdown mirror — /index.md and /abuse.md.
One caution that matters: do not put secrets in a hostname — every resolver along the path can log the names it sees. Trying the other suffix is worth a retry, but do not treat it as failover: one resolver answers both today, so when one is down the other is down with it.
Run your own #
Most people should use the hosted service — append the suffix and you are done. Running your own is a standing commitment: a domain you own, a host with a static public IPv4, UDP and TCP port 53 reachable, NS delegation with glue records, and someone keeping all of it alive. It is the right choice when your environment cannot depend on a third party, or when you need your own domain in the name. Otherwise the hosted service saves you the job — and the source below is here so that staying with it is a choice, not a trap.
The resolver is a zero-dependency Node program. One process can be authoritative for any number of zones:
git clone https://github.com/kwkuh/open-domain
cd open-domain
npm test
ZONES=example.dev,example.test \
PORT=15353 BIND=127.0.0.1 \
node src/server.js
dig +short -p 15353 @127.0.0.1 1.2.3.4.example.dev
Each zone gets its own SOA and apex, and the longest matching zone wins. To serve the public internet you need a host with a static IPv4 address and UDP and TCP port 53 reachable, then delegate NS and glue records to it. Configuration is all environment variables: ZONES, PORT, BIND, NS_HOSTS, APEX_IP, TTL, DEBUG.
Reliability #
This is community-run infrastructure offered as a public good, with no SLA. It is meant for development, previews, demos, CI, and giving ephemeral machines an address. It is not meant to sit in the critical path of a production system that depends on a free third party — for that, run your own from the source above, on a domain you control. That the code is MIT-licensed and trivially self-hostable is the point: there is nothing to be locked into.
Abuse #
A free wildcard DNS service gets misused, and we would rather hear about it. Report a hostname to abuse@open-domain.com and we will act on phishing, malware, and command-and-control. What we can do is stop an address from resolving under our suffixes; what we cannot do is remove content we never hosted, or tell you who used a name, because we keep no query logs. The abuse page explains both sides plainly, including how to reach the host directly — which is usually faster than reaching us.
Sponsor #
Open-Domain is free and intends to stay free. Running authoritative nameservers costs something; keeping the service stateless keeps that cost small, and sponsors cover the rest.