8 ms·

A lot of people learned this the hard way when Google bought and later enabled permanent HSTS for the .dev domain (prior to actually publicly releasing it) in C

A lot of people learned this the hard way when Google bought and later enabled permanent HSTS for the .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments. As mentioned above, it should have been .test

CydeWeys 6y ago
The HSTS preloading fortunately ended up being an unintentional additional type of Controlled Interruption period, which was a good thing in the end. It would've been a lot worse if, one day, your fake domain names are resolving locally, and then literally the next day it's now a real domain name that's resolving remotely, with who knows what result. This at least forced people to address it well in advance of domain names potentially resolving globally. https://www.icann.org/resources/pages/name-collision-2013-12-06-en https://www.icann.org/resources/pages/name-collision-2013-12... https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html
- owl57 6y ago
  Sounds like it could be intentional. — We bought .dev, now what we do with all those people in the wild misusing it? — Well, most of them misuse it with our browser, let's break at least their hacks early and loudly.
  - CydeWeys 6y ago
    It was unintentional. Source: The horse's mouth. I'm the guy who came up with the idea of launching .dev and .app as HTTPS-only TLDs, and I'm the one who had them added to the HSTS preload list.
    - jbrooksuk 6y ago
      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
    - akritrime 6y ago
      How do we know you are the right horse? Sorry, just watched `/the social dilemma` and now I am skeptical of all information on the internet.
      - CydeWeys 6y ago
        If you give me your email I can send you a message from my _lastname_@ work address, which you can then match up with published media I've done under my name, e.g. https://www.youtube.com/watch?v=kBkX30Cj7Bw https://www.youtube.com/watch?v=kBkX30Cj7Bw and https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... Or you can look at the matching username on GitHub ( https://github.com/CydeWeys https://github.com/CydeWeys ) and see that I'm a member of the Google org and owner of the Nomulus repo ( https://github.com/google/nomulus/graphs/contributors https://github.com/google/nomulus/graphs/contributors ), the software running our TLD registry and which was announced here: https://opensource.googleblog.com/2016/10/introducing-nomulus-open-source.html https://opensource.googleblog.com/2016/10/introducing-nomulu... Or I could just dig out my GPG key and sign a message. So I respect your healthy skepticism, but I promise I'm really me, and not just someone pretending to be me! And I'll also note that, in all my time on HN, I've never once seen someone pretending to be anyone they weren't, at least not on seasoned accounts like mine. You can go back through my 5 years of comments on here, and every time I say I'm a specific person out there in the real world, it's always the same consistent person.
        akritrime 6y ago
        I actually confirmed your GitHub before I made the previous comment. It was just a frivolous reply that I found funny but HN didn't. Tough crowd. But I really, really appreciate your reply, thanks for taking your time to prove your identity. Hopefully I didn't waste too much of your Sunday morning.
        CydeWeys 6y ago
        My experience here is that humor (especially deadpan) tends to land very poorly on HN, both because people are never contextually expecting it and because they tend to downvote it when they do recognize it, as they dislike perceived low effort comments that they don't feel are meaningfully contributing to the discussion (i.e. adding noise, not signal). HN may as well put "Don't try to be funny" in the FAQ, because it almost never works out.
    - hmcamp 6y ago
      @Cydeweys, I respect this level of candidness
dmd 6y ago
I own "dev.host" and we get a ton of interesting traffic.
Hamuko 6y ago
Can't wait for .internal to be registered so that my internal DNS breaks.
- samoa42 6y ago
  should have used .local
  - detaro 6y ago
    Not really. .local is often tied to zeroconf/mDNS and doesn't work reliably over traditional DNS on all platforms.
    - nitrogen 6y ago
      mDNS is actually pretty nice on controlled networks, so if you want .local use mDNS.
- jeroenhd 6y ago
  The only proper way to do internal DNS is to register a domain. Even a free one will do. The more people follow decent practices at home, the fewer businesses will accidentally break because on of the admins thought it'd be alright because it works for them at home. If you set your DNS domain correctly you can also save yourself some typing effort because DNS will automatically append the network name (so you can http://test http://test instead of http://test.internal http://test.internal or http://test.hamu.co http://test.hamu.co). As an added bonus, you can get valid TLS certificates for your internal network devices without messing with a certificate authority of your own!
  - Hamuko 6y ago
    I do have a domain but I don't want to enter my private IP addresses on a public DNS. Hence I just have server.internal to point to the correct IP address on my local DNS server and have service1.server.com, service2.server.com, etc. all just CNAME to server.internal.
throw0101a 6y ago
> .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments. Yeah, except it broke more than that. A lot of folks use/d ".dev" and and ".prod" as internal sub-domains in their actually-owned domain (dev.example.com, prod.example.net). For convenience you could however use the resolve.conf's "search" option to simply things, so at the CLI one could type "ssh webserv01.dev" and the resolver would would then append the company's domain to get the FQDN for the query. Except once Google made their changes "webserv01.dev" now could go out to the Internet—especially if you had it in a browser and it tried to be "clever".
- CydeWeys 6y ago
  This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet. See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.
  - throw0101a 6y ago
    > This applies to every domain name though Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.) Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail. Now, with the post-Google TLD changes, if you type one of those things, and the local DNS happens to not be configured properly (i.e., the resolve.conf 'search' options is not present), then strange things can happen. Further, if you put "websrv01.dev" in a browser now, it may go off into the Internet and try to be clever about auto-complete instead of just doing a local query.
    - CydeWeys 6y ago
      This applies to any TLD though, not just .dev and .prod, not just gTLDs generally, and not even just real TLDs (that's right, you could be using a fake TLD on an internal network somewhere and the "creation" of a domain on that fake TLD on that network could cause your previously working hostname shortcuts to start failing). Relying on DNS search lists to find the right host is a bad security practice that has caused security incidents even outside the context of the creation of new TLDs. It's best to always use fully-qualified domain names. A lot of people responsible for implementing DNS search lists in the first place now regret having ever created them. More info at https://www.icann.org/en/system/files/files/sac-064-en.pdf https://www.icann.org/en/system/files/files/sac-064-en.pdf (particularly section 4.1.3 and the preceding logic leading up to it).

CydeWeys 6y ago

The HSTS preloading fortunately ended up being an unintentional additional type of Controlled Interruption period, which was a good thing in the end. It would've been a lot worse if, one day, your fake domain names are resolving locally, and then literally the next day it's now a real domain name that's resolving remotely, with who knows what result. This at least forced people to address it well in advance of domain names potentially resolving globally. https://www.icann.org/resources/pages/name-collision-2013-12-06-en https://www.icann.org/resources/pages/name-collision-2013-12... https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html

owl57 6y ago
Sounds like it could be intentional. — We bought .dev, now what we do with all those people in the wild misusing it? — Well, most of them misuse it with our browser, let's break at least their hacks early and loudly.
- CydeWeys 6y ago
  It was unintentional. Source: The horse's mouth. I'm the guy who came up with the idea of launching .dev and .app as HTTPS-only TLDs, and I'm the one who had them added to the HSTS preload list.
  - jbrooksuk 6y ago
    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
  - akritrime 6y ago
    How do we know you are the right horse? Sorry, just watched `/the social dilemma` and now I am skeptical of all information on the internet.
    - CydeWeys 6y ago
      If you give me your email I can send you a message from my _lastname_@ work address, which you can then match up with published media I've done under my name, e.g. https://www.youtube.com/watch?v=kBkX30Cj7Bw https://www.youtube.com/watch?v=kBkX30Cj7Bw and https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s... Or you can look at the matching username on GitHub ( https://github.com/CydeWeys https://github.com/CydeWeys ) and see that I'm a member of the Google org and owner of the Nomulus repo ( https://github.com/google/nomulus/graphs/contributors https://github.com/google/nomulus/graphs/contributors ), the software running our TLD registry and which was announced here: https://opensource.googleblog.com/2016/10/introducing-nomulus-open-source.html https://opensource.googleblog.com/2016/10/introducing-nomulu... Or I could just dig out my GPG key and sign a message. So I respect your healthy skepticism, but I promise I'm really me, and not just someone pretending to be me! And I'll also note that, in all my time on HN, I've never once seen someone pretending to be anyone they weren't, at least not on seasoned accounts like mine. You can go back through my 5 years of comments on here, and every time I say I'm a specific person out there in the real world, it's always the same consistent person.
      - akritrime 6y ago
        I actually confirmed your GitHub before I made the previous comment. It was just a frivolous reply that I found funny but HN didn't. Tough crowd. But I really, really appreciate your reply, thanks for taking your time to prove your identity. Hopefully I didn't waste too much of your Sunday morning.
        CydeWeys 6y ago
        My experience here is that humor (especially deadpan) tends to land very poorly on HN, both because people are never contextually expecting it and because they tend to downvote it when they do recognize it, as they dislike perceived low effort comments that they don't feel are meaningfully contributing to the discussion (i.e. adding noise, not signal). HN may as well put "Don't try to be funny" in the FAQ, because it almost never works out.
  - hmcamp 6y ago
    @Cydeweys, I respect this level of candidness

dmd 6y ago

I own "dev.host" and we get a ton of interesting traffic.

Hamuko 6y ago

Can't wait for .internal to be registered so that my internal DNS breaks.

samoa42 6y ago
should have used .local
- detaro 6y ago
  Not really. .local is often tied to zeroconf/mDNS and doesn't work reliably over traditional DNS on all platforms.
  - nitrogen 6y ago
    mDNS is actually pretty nice on controlled networks, so if you want .local use mDNS.
jeroenhd 6y ago
The only proper way to do internal DNS is to register a domain. Even a free one will do. The more people follow decent practices at home, the fewer businesses will accidentally break because on of the admins thought it'd be alright because it works for them at home. If you set your DNS domain correctly you can also save yourself some typing effort because DNS will automatically append the network name (so you can http://test http://test instead of http://test.internal http://test.internal or http://test.hamu.co http://test.hamu.co). As an added bonus, you can get valid TLS certificates for your internal network devices without messing with a certificate authority of your own!
- Hamuko 6y ago
  I do have a domain but I don't want to enter my private IP addresses on a public DNS. Hence I just have server.internal to point to the correct IP address on my local DNS server and have service1.server.com, service2.server.com, etc. all just CNAME to server.internal.

throw0101a 6y ago

> .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments. Yeah, except it broke more than that. A lot of folks use/d ".dev" and and ".prod" as internal sub-domains in their actually-owned domain (dev.example.com, prod.example.net). For convenience you could however use the resolve.conf's "search" option to simply things, so at the CLI one could type "ssh webserv01.dev" and the resolver would would then append the company's domain to get the FQDN for the query. Except once Google made their changes "webserv01.dev" now could go out to the Internet—especially if you had it in a browser and it tried to be "clever".

CydeWeys 6y ago
This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet. See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.
- throw0101a 6y ago
  > This applies to every domain name though Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.) Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail. Now, with the post-Google TLD changes, if you type one of those things, and the local DNS happens to not be configured properly (i.e., the resolve.conf 'search' options is not present), then strange things can happen. Further, if you put "websrv01.dev" in a browser now, it may go off into the Internet and try to be clever about auto-complete instead of just doing a local query.
  - CydeWeys 6y ago
    This applies to any TLD though, not just .dev and .prod, not just gTLDs generally, and not even just real TLDs (that's right, you could be using a fake TLD on an internal network somewhere and the "creation" of a domain on that fake TLD on that network could cause your previously working hostname shortcuts to start failing). Relying on DNS search lists to find the right host is a bad security practice that has caused security incidents even outside the context of the creation of new TLDs. It's best to always use fully-qualified domain names. A lot of people responsible for implementing DNS search lists in the first place now regret having ever created them. More info at https://www.icann.org/en/system/files/files/sac-064-en.pdf https://www.icann.org/en/system/files/files/sac-064-en.pdf (particularly section 4.1.3 and the preceding logic leading up to it).