[JoshTriplett]

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 (https://tools.ietf.org/html/rfc2606) or the updated RFC 6761 (https://tools.ietf.org/html/rfc6761): .test, .invalid, .example, or .localhost, depending on what semantics you need.

[borkabrak]

This.. seems to resolve every issue I might have otherwise had with the story, including the impulse to yell at Google about it, but the author himself makes a fair case for not doing that.

It turns out that part of the way the internet is declared to work includes reserved TLDs to be used for testing. So the burden of responsibility for avoiding a situation such as the article describes lies on the developer to use one of those reserved TLDs instead of ".dev", which anyone could (and now, has) come to control.

[NSAID]

Yeah, fake domain names and TLDs are an issue with Microsoft sysadmins in regards to .local. I aggressively move environments away from using anything half-baked like ".dev.", and while some people like ".local", I'm not a fan. Ignore the spec at your own peril.

https://en.wikipedia.org/wiki/.local#Microsoft_recommendatio...

[AnkhMorporkian]

This might seem prophetic or cocky, but I've used a random b64 TLD for years that I expand with a macro. After we expanded past countries on the TLDs, I just figured that any short (or even sensible) TLD would eventually be taken, and I didn't want that to break any of my tests that had hardcoded domains (as rare as those are.)

[gruez]

to be fair, before icann introduced the gtld program, it was a fair assumption that there wouldn't be a .dev tld.

[cls59]

But also, the folks at medium made that assumption long after RFC 2606 had established a "right answer" for which tld to use when testing.

[gruez]

i think i wasn't being clear with my initial comment. it's a "fair assumption" in the same way that it's a fair assumption that emails can be validated with the regex

    [a-zA-Z0-9\.]+@[a-zA-Z0-9]+\.[a-zA-Z0-9]+

sure, it breaks for gmail aliases (with +), isn't RFC compliant, and the proper regex is a google search away, but it's understandable why that was chosen. same with .dev domains. yeah, you probably should have looked for a reserved tld, but why do that when .dev already didn't exist, and it didn't look like icann was going to delegate that any time soon?

see also: https://hn.algolia.com/?query=falsehoods%20programmers%20bel...

[kijeda]

These don't strike me as comparable scenarios.

In the case of .dev, it didn't even appear in the weeds of usage when the DNS root servers were measured for traffic to identify potential new TLDs usage conflicts in the real world (e.g. https://www.icann.org/en/system/files/files/name-collision-0... p22). Even if .dev were in significant usage, that traffic was not reaching the domain name system. The complaint seems to be fundamentally to be about the pre-loaded configuration of Chrome, not the DNS.

In the case of your regex, it would breaks millions of production domains in used today and fail in a wide variety of scenarios. It is only understandable in the context of someone who hasn't done any cursory research into the topic.

[ChrisSD]

To be honest, programmers should be more aware than most that the spec will change and previously "fair" assumptions won't hold.

[dragonwriter]

The spec hadn't changed though; RFC 2606 has been around since 1999.

An implementation policy that is overtly not a stable specification changed.

Using “test" at some level of the domain name, including the top level if desired, has been the documented correct and safe answer for a long time, and .dev has always been an unnecessarily risky hack. (Amusingly, everyone else doing that hack got screwed because Google was using it as well and realized that if it didn't take control of the TLD and manage it to support it's pre-existing internal use, it ran the risk of someone else doing that.)