This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet.

See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.

> This applies to every domain name though

Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.)

Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail.

Now, with the post-Google TLD changes, if you type one of those things, and the local DNS happens to not be configured properly (i.e., the resolve.conf 'search' options is not present), then strange things can happen.

Further, if you put "websrv01.dev" in a browser now, it may go off into the Internet and try to be clever about auto-complete instead of just doing a local query.

This applies to any TLD though, not just .dev and .prod, not just gTLDs generally, and not even just real TLDs (that's right, you could be using a fake TLD on an internal network somewhere and the "creation" of a domain on that fake TLD on that network could cause your previously working hostname shortcuts to start failing).

Relying on DNS search lists to find the right host is a bad security practice that has caused security incidents even outside the context of the creation of new TLDs. It's best to always use fully-qualified domain names. A lot of people responsible for implementing DNS search lists in the first place now regret having ever created them.

More info at https://www.icann.org/en/system/files/files/sac-064-en.pdf (particularly section 4.1.3 and the preceding logic leading up to it).

Which is one of the reasons I always insist our dev and prod teams use FQDNs (under domains the company owns) in all of their configurations.

In more dynamic environments, the config may have the domain as its own setting and each service as just the hostname, but the software must combine them before use, or better yet combine them in the config if variable expansion is possible in the config language they are using (ex: db_server="db-01.${domain}" with domain being defined near the top).