If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services.
You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
> The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host.
An internal network might not be a LAN - for example, it might be a company's entire internal infrastructure spread over three offices and a datacenter with VPN.
Plus "DNS related code" can be stretched pretty far to "code that uses DNS." so it's the one I prefer.
The only thing I wish was easier was having a TLD for network local names but not link-local names. I typically just buy a name for that but it seems clunky since any in-use name that uses public DNS TLDs I feel ought to be DNS server independent.
.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.)
I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use?
It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
Who bought it is irrelevant. It could have been released to the public in a similar way to .com and the same issue would remain.
The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow.
Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
One company I worked at thought it would be a good idea to use .local for their global internal network.
Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
Google weren't supposed to make it generally available. From their application[0]:
> .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool.
Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
Yeah sure takes one minute, one minute of wondering if you really wanna bash your head against a wall getting openssl to spit out an X509 cert and then some.
You mean wait six to eight months for the IT security department in another division of the company in another state to -maybe- approve my cert request.
Not all web development is three guys on Linux laptops at WeWork.
If you're a big org, presumably you could just get your org to just buy the TLD if it's that much trouble.
Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
I don't get what Google thinks they'll get out of sponsoring putting sites under development online.