4 ms·

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

by 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.
    - CydeWeys 6y ago
      And also, from a larger standpoint, we have a choice of two mutually exclusive options here. It comes down to either (a) freezing the TLD hierarchy in place and never creating any new ones (e.g. not even for a new country, or .mars or whatever), or (b) not retaining indefinite backwards support for multi-label DNS search lists when they happen to collide with new TLDs. I would argue that, of the two options, option B is the less onerous one, and less restrictive on the future growth of the Internet. It's not that hard to set up some aliases to be able to SSH quickly into the right hosts without having to manually type out longer paths.

by oauea 6y ago

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.
  - CydeWeys 6y ago
    And also, from a larger standpoint, we have a choice of two mutually exclusive options here. It comes down to either (a) freezing the TLD hierarchy in place and never creating any new ones (e.g. not even for a new country, or .mars or whatever), or (b) not retaining indefinite backwards support for multi-label DNS search lists when they happen to collide with new TLDs. I would argue that, of the two options, option B is the less onerous one, and less restrictive on the future growth of the Internet. It's not that hard to set up some aliases to be able to SSH quickly into the right hosts without having to manually type out longer paths.