test
example
invalid
localhost
local
localdomain
domain
lan
home
host
corp
0. https://www.ietf.org/archive/id/draft-chapin-rfc2606bis-00.h...https://datatracker.ietf.org/doc/html/rfc2606#page-2 https://datatracker.ietf.org/doc/html/rfc6761
You are probably safe using names like .lan and .corp but they are not currently protected by standard in the way example is.
".test" is recommended for use in testing of current or new DNS related code.
".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain that are sure to be invalid and which it is obvious at a are invalid.
The ".localhost" TLD has traditionally been statically defined in DNS implementations as having an A record pointing to the back IP address and is reserved for such use. Any other use conflict with widely deployed code which assumes this use.
[0] https://datatracker.ietf.org/doc/html/rfc2606https://en.wikipedia.org/wiki/List_of_Internet_top-level_dom...
"ICANN/IANA has created some Special-Use domain names which are meant for special technical purposes. ICANN/IANA owns all of the Special-Use domain names."
A large percentage of people following the examples will use them verbatim.
Had a case recently where someone was setting up a postgres container and the example was something like:
docker run --name some-postgres -e POSTGRES_PASSWORD=mysecretpassword -d postgres
You guessed it, "mysecretpassword" ended up being the password. And the service predictably got compromised, because that example was one that was pretty high up in seasrch results for "how to run postgres in docker" and attackers probing for port 5432 will try "mysecretpassword."Another one is can we please stop posting code examples that are illustrating some language feature or how to do thing X in language Y, where the code has a footnote "this isn't secure, don't do this in production code." That footnote will be ignored. If you're going to bother answering a question, answer it with a proper implementation and not something that is a gaping code injection vulnerability.
1. Software is coded to recognize "stupid example values" and prohibit them with an error or at least throw some pretty obvious warnings.
2. Such software also has a rarely-used but documented option to bypass the above checks.
For example, the PostgreSQL server might refuse to allow any DB user to have a password which begins with "password", returning a "Pick A Real One" error.
However somebody somewhere will always need the "don't do that" option: The more different libraries and services you bring together, the more likely there will be either false-alarms or outright conflicts between different example-blocker schemes.