While this is an interesting exploration of the history of the Internet, gTLDs, HSTS, and various other things, the story boils down to this: never make up an unregistered domain/TLD and assume it won't exist in the future; always use a reserved test domain/TLD from RFC 2606 (<a href="https://tools.ietf.org/html/rfc2606" rel="nofollow">https://tools.ietf.org/html/rfc2606</a>) or the updated RFC 6761 (<a href="https://tools.ietf.org/html/rfc6761" rel="nofollow">https://tools.ietf.org/html/rfc6761</a>): .test, .invalid, .example, or .localhost, depending on what semantics you need.
> <i>The other option is to change your .dev domain and never look back. But what domain could we migrate to? With the gTLD gold rush, is anything safe?</i><p>Just buy medium-devel.com or something and make it resolve to 127.0.0.1 in internal DNS. This gets you a couple of benefits:<p>- No one will ever take it from you<p>- You can configure it in external DNS if you'd like<p>- You can get a real, publicly-trusted SSL certificate for it, for free, because Let's Encrypt can resolve DNS challenges against it<p>(By the way, you want to get an SSL certificate for internal development, because of the policy - Chrome-initiated but now followed by the HTML standards folks in general - to require HTTPS for fancy new features like geolocation and service workers: <a href="https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features" rel="nofollow">https://www.chromium.org/Home/chromium-security/prefer-secur...</a> If you don't have HTTPS of some sort, you can't test these features locally.)
I absolutely hate this gTLD crap. The fact that companies can pick up any TLD on the global namespace is absurd. Even worse, the internet community never had a chance to object to these sales.<p>Something that pisses me off even more is that a few months back there was an IETF draft to specify the .home TLD to only resolve local network requests. It seemed pretty reasonable, but there was pushback and it was changed to home.arpa, since the .arpa TLD is already restricted. So big companies can pick up any TLD they want, but regular users will forever be forced to type in extra characters.
I had no idea you could buy gTLDs for internal company use. That’s outrageous, and ICANN should have rejected the application. I don’t mind the idea behind gTLDs, but the while thing has been handled pretty poorly.
Having read <a href="https://tools.ietf.org/html/rfc6761" rel="nofollow">https://tools.ietf.org/html/rfc6761</a>, I have a use-case which I've seen often but doesn't seem to be covered: What TLD should I use for internal, production domains? ie. names that are only resolvable within my network, but are definitely not "test" domains and calling them .test would generate confusion.<p>Mostly I tend to see companies either inventing an unregistered TLD, often using their own company name, or they use ".local", which can cause issues - some systems treat this name specially.<p>A third option would be putting all internal names under an "internal.yourcompany.com", but that's long and annoying.<p>Ideally I'd like to see a ".private" or ".internal" TLD recognised as special-use under the same semantics as ".test". Does anyone have any better option?
The article outlines two options. There is a third.<p>Lobby google through petitions and collective developer action to surrender their .dev TLD and create an RFC that makes it reserved for developer used, similarly to .example and .test.
I really enjoyed this piece. We don't use .dev on my team so it allowed me to read it as purely educational. And it really was informative and surprisingly entertaining!
Typical jerk move. This is not only taking the ball with you but closing the field and locking it requiring keys that only you have.<p>Not only is this problematic but so is HSTS, and the push for increasing reliance on CAs and in effect making self signed certs pointless.<p>The great concern for SSL by many people is simply ad supporting behavior masquerading as concern for privacy and state actors. Apparently ssl which is routinely mitm'd by small time corporations can protect privacy. Accept that with straight face while mitm vendors interests are paid attention to in standards meetings.<p>And Mozilla, the so called 'defender' cashing in on the public good will whenever it suits them conveniently caves in to Google at every opportunity.
Wow, is it so hard to use a self-signed in your local dev config for nginx/whatever? I have a bash script that auto-spins up a new dev environment ala: ng create something.dev apps/php/laravel/app/public -- auto makes a self-signed cert, reloads nginx, and should still work in new chrome, since it uses https.<p>Am I missing something or are they whining over nothing? I would get a little perturbed if only .dev domains show up if you're on a google ip or something, but for now, using https is totally do-able.
If Google is only using .dev internally, and there won't be any public .dev domains, then who cares? As long as my hosts file routes .dev to the proper localhost nooks and crannies, nothing changes.<p>Unless you've bound yourself to Big G's browser. We only use that for last-minute rendering tests because management doesn't trust it not to leak info back to Mountain View.<p>Also, does Medium have a minimum word requirement? For some reason Medium articles always seem unnecessarily extra large.
Rather than maintaining a list of HSTS websites which isn't cross-browser, why is there not an optional HSTS flag attached to the DNS response? I don't know anything about DNS requests, so changing the protocol in a backwards compatible way might be impossible, but that seems like a much better way to maintain that information than with a separate list.
Just use lacolhost.com:
<a href="https://news.ycombinator.com/item?id=13749515" rel="nofollow">https://news.ycombinator.com/item?id=13749515</a>
In my job we use our hostname.ourdomainname.com for internal things, so I don't see this problem as much. And it wont be accessible externally anyway.
We still have a huge number of the dev environments running on .dev, needless to say we were pretty pissed off when Google were able to buy the TLD to use as they wish. Anyway, not much we can do about it now other than start the process of setting up a new subdomain and reconfiguring all our CI/CD, Apps, Docs etc... I know we should have done it ages ago, there’s a ticket there for it... but resourcing.... <i>sigh</i>
"Like a small child, your operating system believes in "stranger danger" and doesn't trust self-signed certificates."<p>[ ] True [x] False<p>First, is it the OS that distrusts certificates, or is it the HTTP client?<p>Second, CA certificates such as the ones trusted by HTTP clients (contained in "browsers") are self-signed certificates.<p>Pre-installed CA certificates in corporate HTTP clients (e.g., Chrome, etc.) and CA certificates in downloadbale "bundles" available from corporations (e.g., Mozilla) are self-signed.
As much as I agree with not using a public TLD as a dev environment, why the fuck was google allowed to register and privately secure not one but several domains for their own private use? Fuck them. That shouldn't have been allowed, especially for a TLD that's well known to be heavily used.<p>I really dislike allowing domains to be used in such a way. It seems extremely short sighted.