Use .test for controlled testing, .example or example.com for documentation, .invalid when a name must visibly fail, and .localhost for loopback use. These four TLDs were reserved specifically to prevent test code and examples from colliding with real public domains.
Why invented test endings are dangerous
A made-up suffix is not necessarily unused forever. A team might configure service.internal, shop.dev or demo.app on a private resolver and assume it can never exist publicly. If the same ending is delegated in the global DNS—or already is—queries can leak outside the test network, certificates can be requested for the wrong namespace and users can reach someone else's site.
RFC 2606 solves that collision problem by permanently reserving four names for explicit purposes. The later special-use framework in RFC 6761 records how applications and resolvers should handle several of them. IANA's live Special-Use Domain Names registry is the current machine-oriented reference.
The four reserved top-level names
| Name | Intended use | Good example | Do not assume |
|---|---|---|---|
| .test | Testing DNS-related code and configurations | api.project.test | Public DNS or trusted TLS will be provided automatically |
| .example | Documentation and illustrative names | store.example | A production web service will exist |
| .invalid | A name intended to be clearly invalid | missing.invalid | Every tool will fail in exactly the same way |
| .localhost | Loopback host naming | app.localhost | All subdomain and certificate behavior is identical across stacks |
How to choose the right reserved name
Use .test for an environment you control
.test is the best semantic match for integration labs, local DNS zones, examples that demonstrate resolver configuration and non-public application environments. Reservation prevents future public delegation, but it does not create records. Your hosts file, container resolver, local DNS server or testing framework still has to map the name.
Use example domains in anything another person may copy
Documentation should normally use example.com, example.net, example.org or a label under .example. IANA maintains the three second-level names for exactly this purpose and states that they are not available for registration or transfer. Readers can safely recognize them as placeholders, and pasted sample code does not send traffic to an unrelated registrant.
Use .invalid to demonstrate failure
.invalid is for a string that should be unmistakably non-working: form-validation examples, negative tests and documentation explaining error paths. It expresses intent better than a random misspelling of a real TLD. A test should still assert the application's expected outcome, because browsers, resolvers and libraries may surface failure with different error messages.
Use localhost for loopback, not a shared staging service
localhost is special because name-resolution libraries are expected to map it to loopback. It is appropriate for a process on the same machine. A service that teammates, CI runners or mobile devices must reach is not “local” to all of them; give that environment controlled DNS under a reserved test zone or a subdomain you own.
Related names people often confuse
| Name | Status | Use |
|---|---|---|
| .local | Special-use, not one of RFC 2606's four | Multicast DNS; avoid using it as an ordinary private DNS suffix |
| home.arpa | Special-use name | Locally served naming in residential home networks |
| .onion | Special-use name | Tor onion services, not the public DNS root |
| .internal | Do not infer safety from the word | Check current standards and local architecture before adopting |
| .dev | Real delegated gTLD | Public developer sites; HTTPS is required by HSTS preload |
| .app | Real delegated gTLD | Public applications; also HSTS-preloaded |
When an owned domain is better
Reserved names are excellent for isolated tests, but a realistic public staging environment may need trusted certificates, third-party OAuth callbacks, email validation, public webhooks or access from devices outside the private resolver. In that case, use a subdomain of a domain the organization controls—such as staging.example-owned-domain.com—and protect it with authentication and access controls.
Ownership gives the team real DNS and certificate control. The trade-off is operational: test endpoints can be discovered, indexed or attacked unless robots directives, authentication and network policy are configured correctly. Never rely on an obscure hostname as the only security boundary.