3 ms·

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 domai

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 https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.

throw0101a 6y ago
> 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.
- CydeWeys 6y ago
  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 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).

throw0101a 6y ago

> 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.

CydeWeys 6y ago
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 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).