Slashdot Mirror
Wondering Why Your Internal .dev Web App Has Stopped Working? (theregister.co.uk)
Kieren McCarthy, writing for The Register: Network admins, code wranglers and other techies have hit an unusual problem this week: their test and development environments have vanished. Rather than connecting to private stuff on an internal .dev domain to pick up where they left off, a number of engineers and sysadmins are facing an error message in their web browser complaining it is "unable to provide a secure connection." How come? It's thanks to a recent commit to Chromium that has been included in the latest version of Google Chrome. As developers update their browsers, they may find themselves booted out their own systems. Under the commit, Chrome forces connections to all domains ending in .dev (as well as .foo) to use HTTPS via a HTTP Strict Transport Security (HSTS) header. This is part of Google's larger and welcome push for HTTPS to be used everywhere for greater security.
You don't own the .dev tld!
You don't own the .dev tld!
On a private network, yes, you do.
You don't own it on the Internet, but on your own network, you own every domain and TLD.
This isn't Google forcing you to be secure. Don't use a domain name you don't own.
On your own private network, you do own any domain name you want.
The name resolution protocols specifically allow this, and for good reasons.
.test is a better replacement, strictly speaking, since IETF has reserved that TLV (as well .example and .invalid).
Of course, it's pretty damn weird for a browser to hard bake assumption about TLD ownership and policy.
XML is like violence. If it doesn't solve the problem, use more.
Because you didn't use a reserved TLD you numpty. The same people probably use non-private subnets for their internal networks and then wonder why some websites that had the audacity to use that IP don't work...
While there are times where I would tend to agree this is not one of them. Responsibility is bidirectional.
Opening the TLD floodgates was a predictable, preventable disaster done entirely for selfish reasons at the expense of the network and all its users.
Allowing TLDs like ".dev" to be handed out in the first place was much worse. They knew or should have known how this was being widely used at the time and what the global implications would be yet like TLD floodgates $$$ wins the day.
Then Google was like...hey we own this TLD and we own a web browser so we'll just leverage our verticals to enforce arbitrary rules over what we own anyway that suits our specific needs.
This is a shining example of what happens when $$$ is allowed to trump reason and why allowing monopolies to get too powerful and start exerting ownership over more and more of the stack is a bad idea. They can and will do whatever they want simply because they can. They can't help themselves nor can they even understand that their needs and goals are not representative of the rest of the world.
Today it is HSTS tomorrow it is waking up to find browsers doing UDP with user land congestion algorithms configured to be twice as aggressive as TCP...oh wait.. that already happened...
This is of course true, but bad practice. I disagree with the idea of baking in this sort of thing into the browser software, however whenever you stray from officially reserved values, you can land in a world of pain.
For example, you use '.dev' for your internal sites. Sure, you control DNS and you can do that. Suddenly, a workstation needs access to something google is hosting on .dev. Suddenly, you have a self-inflicted wound because you didn't stick to private use reserved values, and you don't have a clean way out of reconciling this.
XML is like violence. If it doesn't solve the problem, use more.
And if *you* understood you would know .dev is a valid ICANN assigned TOLD not available for your internal use. You don't get to violate standards and then cry foul because the rest of the world follows them.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun