5 ms·

Out of interest, how did this happen without any investigation into possible consequences etc? It’s a huge change that surely warranted special attention befor

Out of interest, how did this happen without any investigation into possible consequences etc? It’s a huge change that surely warranted special attention before making it happen?

CydeWeys 6y ago
It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we didn't anticipate how many people weren't following the best practices, but that would have been hard to determine prior to doing the thing anyway. There were also lots of people who had the mindset of "We won't change anything until it stops working", so in some sense a lot of it was unavoidable. See e.g.: https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet/issues/431 https://github.com/laravel/valet/issues/431 (note that Laravel users were responsible for a non-trivial fraction of the total problems experienced, and that we only discovered all this post-HSTS-preloading). The problem was repeatedly pointed out and the maintainers refused to fix it until it actually broke. So, inevitably, it broke, and then they fixed it.
- oauea 6y ago
  Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.
  - evolve2k 6y ago
    Basecamp’s Pow project comes to mind. It enables zero config local development configuration, whereby at the time it would make your locally running dev server available on .dev So instead of having to spin up a local server and then visiting say 127.0.0.1:3000, I could instead just visit myappname.dev and it would show me what would previously show on localhost or it would spin up a server first for that app then show it to me. They switched to .test in response to google’s change. Official site: https://pow.cx https://pow.cx Thread on change from .dev to .test https://github.com/basecamp/pow/issues/386 https://github.com/basecamp/pow/issues/386
    - colejohnson66 6y ago
      I just got an “untrusted connection” warning visiting pow.cx
      - evolve2k 6y ago
        Oh woops just habit to set https now. Page is from an earlier time when we didn’t mind static sites not being https. Visit http://pow.cx http://pow.cx
  - ChickeNES 6y ago
    This attitude is the reason I refuse to use Chrome and only recommend the alternatives.
  - CydeWeys 6y ago
    Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names. Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther down the line. That's why you shouldn't use fake domain names. This problem has been known since at least the 90s and is not a good habit to get into. Them now being real makes them actually more useful (and not reliant on potentially unsynced local-only config).
    - linsomniac 6y ago
      My problem was that it also broke properly configured domains. We have machines in xxx.dev.example.com (for example) that I used to rely on the resolver searching for, so I could just type "xxx.dev" and it would then know to try it with example.com banged onto the end. Then everything in .dev started resolving so my abbreviations started resolving to other hosts. I mean, I THINK this is "properly configured", but it also isn't a huge deal to avoid. Just was annoying when it started happening. Didn't FEEL like I was misconfigured. :-)
      - Kalium 6y ago
        If your machines started exhibiting behavior you didn't expect or intend from a configuration you believe to be proper, then something has gone wrong. It may be the system, it may be the configuration, and it may be your understanding of either. Or any combination. In this particular case it sounds like your resolver was set up to try an external resolution first and then append an internal domain if the external resolution failed. And as you say, this clearly worked just fine for a long, long time. Then it suddenly started failing one day, for reasons unrelated to anything you changed. At this point, most people would find it reasonable to blame the external change for breaking their fully functional, correctly working, "properly configured" setup. Some, perhaps contrarian or perhaps more cautious, would note that the "properly configured" approach only worked so long as external systems played ball. I think it might be the case that you were bitten by this assumption that seemed safe at the time, leading to the awkward and uncomfortable conclusion that your systems were indeed misconfigured.
ludamad 6y ago
I don't think fresh launches, even with bold new parameters, are always considered 'huge changes' in that sense. The fact that it could break local environment's was probably not even documented in those specific environments
- nitrogen 6y ago
  There was a time when the creation of a new TLD was unthinkable, so it seemed safe to use a domain syntax internally that was never going to become a public TLD. Then the TLD money grab happened and what was assumed to be safely isolated wilderness was sold out from under everyone.
  - CydeWeys 6y ago
    There never was such a time, and IANA never said "We won't make any more". TLDs have been continually created for at least the past two decades. Look up the history of e.g. .biz, .info, .museum, .aero, .mobi, .cat, .asia, all the various ccTLDs that are created as new countries form (.ss), etc. And none of that is even counting the new gTLD expansion round that kicked off in 2012.

Out of interest, how did this happen without any investigation into possible consequences etc? It’s a huge change that surely warranted special attention before making it happen?

CydeWeys 6y ago

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we didn't anticipate how many people weren't following the best practices, but that would have been hard to determine prior to doing the thing anyway. There were also lots of people who had the mindset of "We won't change anything until it stops working", so in some sense a lot of it was unavoidable. See e.g.: https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet/issues/431 https://github.com/laravel/valet/issues/431 (note that Laravel users were responsible for a non-trivial fraction of the total problems experienced, and that we only discovered all this post-HSTS-preloading). The problem was repeatedly pointed out and the maintainers refused to fix it until it actually broke. So, inevitably, it broke, and then they fixed it.

oauea 6y ago
Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.
- evolve2k 6y ago
  Basecamp’s Pow project comes to mind. It enables zero config local development configuration, whereby at the time it would make your locally running dev server available on .dev So instead of having to spin up a local server and then visiting say 127.0.0.1:3000, I could instead just visit myappname.dev and it would show me what would previously show on localhost or it would spin up a server first for that app then show it to me. They switched to .test in response to google’s change. Official site: https://pow.cx https://pow.cx Thread on change from .dev to .test https://github.com/basecamp/pow/issues/386 https://github.com/basecamp/pow/issues/386
  - colejohnson66 6y ago
    I just got an “untrusted connection” warning visiting pow.cx
    - evolve2k 6y ago
      Oh woops just habit to set https now. Page is from an earlier time when we didn’t mind static sites not being https. Visit http://pow.cx http://pow.cx
- ChickeNES 6y ago
  This attitude is the reason I refuse to use Chrome and only recommend the alternatives.
- CydeWeys 6y ago
  Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names. Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther down the line. That's why you shouldn't use fake domain names. This problem has been known since at least the 90s and is not a good habit to get into. Them now being real makes them actually more useful (and not reliant on potentially unsynced local-only config).
  - linsomniac 6y ago
    My problem was that it also broke properly configured domains. We have machines in xxx.dev.example.com (for example) that I used to rely on the resolver searching for, so I could just type "xxx.dev" and it would then know to try it with example.com banged onto the end. Then everything in .dev started resolving so my abbreviations started resolving to other hosts. I mean, I THINK this is "properly configured", but it also isn't a huge deal to avoid. Just was annoying when it started happening. Didn't FEEL like I was misconfigured. :-)
    - Kalium 6y ago
      If your machines started exhibiting behavior you didn't expect or intend from a configuration you believe to be proper, then something has gone wrong. It may be the system, it may be the configuration, and it may be your understanding of either. Or any combination. In this particular case it sounds like your resolver was set up to try an external resolution first and then append an internal domain if the external resolution failed. And as you say, this clearly worked just fine for a long, long time. Then it suddenly started failing one day, for reasons unrelated to anything you changed. At this point, most people would find it reasonable to blame the external change for breaking their fully functional, correctly working, "properly configured" setup. Some, perhaps contrarian or perhaps more cautious, would note that the "properly configured" approach only worked so long as external systems played ball. I think it might be the case that you were bitten by this assumption that seemed safe at the time, leading to the awkward and uncomfortable conclusion that your systems were indeed misconfigured.

ludamad 6y ago

I don't think fresh launches, even with bold new parameters, are always considered 'huge changes' in that sense. The fact that it could break local environment's was probably not even documented in those specific environments

nitrogen 6y ago
There was a time when the creation of a new TLD was unthinkable, so it seemed safe to use a domain syntax internally that was never going to become a public TLD. Then the TLD money grab happened and what was assumed to be safely isolated wilderness was sold out from under everyone.
- CydeWeys 6y ago
  There never was such a time, and IANA never said "We won't make any more". TLDs have been continually created for at least the past two decades. Look up the history of e.g. .biz, .info, .museum, .aero, .mobi, .cat, .asia, all the various ccTLDs that are created as new countries form (.ss), etc. And none of that is even counting the new gTLD expansion round that kicked off in 2012.