6 ms·

If you think about it what Google did was actually quite smart. By forcing HSTS for .dev they broke setups of people who hijacked a domain name they didn't own

by hannob 4y ago

If you think about it what Google did was actually quite smart. By forcing HSTS for .dev they broke setups of people who hijacked a domain name they didn't own and that wasn't made for that purpose (and, as others pointed out, there are TLDs reserved for testing that you can use). So they forced those people to fix their stuff. If they hadn't done that .dev probably would have gained the reputation of the TLD that doesn't work, because all kinds of people redirected it to some testing hosts.

sebstefan 4y ago
Why does that affect the .dev TLD specifically?
- acatton 4y ago
  Because Google manages the .dev TLD. https://en.wikipedia.org/wiki/.dev https://en.wikipedia.org/wiki/.dev It's their TLD, they do whatever they want.
- matharmin 4y ago
  Because many people (myself included) used .dev for internal testing domains before it was a TLD, either by specifying the domains in my hosts file, or with a local DNS server. Now i use .test for that, which is actually a reserved suffix that would never be a real TLD.
  - chatmasta 4y ago
    Just to expand on why you should use .test for this, it's a reserved TLD according to RFC 2606 [0] and should therefore be guaranteed never to be issued by any registrar. Alternatively, you could use any of the other 11 reserved TLDs: .测试, .परीक्षा, .испытание, .테스트, .טעסט, .測試, .آزمایشی, .பரிட்சை, .δοκιμή, .إختبار, .テスト e.g. we use `https://www.splitgraph.test https://www.splitgraph.test` for local development, which is nice because we avoid a whole class of "works in dev" bugs that you get with `http://localhost:3001 http://localhost:3001` For the certificate, we use a self-signed certificate signed by a root cert generated by mkcert [1] locally on each developer's machine (to avoid sharing a root cert that could be used to MITM each other). [0] https://en.wikipedia.org/wiki/.test https://en.wikipedia.org/wiki/.test [1] https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
    - RulerOf 4y ago
      I created a subdomain like local.example.com and pointed it at 127.0.0.1 in the DNS. I wanted to suggest using a .test domain but managing the hosts file is always really clunky, even with a slick tool like hostess[1]. 1: https://github.com/cbednarski/hostess https://github.com/cbednarski/hostess
  - qwertox 4y ago
    I have a shortname.cc domain which I use for testing. This allows me to issue Let's Encrypt certificates for *.shortname.cc, which includes local.shortname.cc. The internal DNS server masks the public one, so that I can assign local IPs at will, use HTTP or HTTPS at will, and when I'm outside of the network, the devices will contact the public DNS server and use the actual public IP of the network to access a limited set of servers (like ejabberd). These servers then stay accessible on the inside but through the local IPs, so that they don't have to leave the local network touching the edge router (which also solves some NAT issues on WebSocket connections).

by hannob 4y ago

sebstefan 4y ago

Why does that affect the .dev TLD specifically?

acatton 4y ago
Because Google manages the .dev TLD. https://en.wikipedia.org/wiki/.dev https://en.wikipedia.org/wiki/.dev It's their TLD, they do whatever they want.
matharmin 4y ago
Because many people (myself included) used .dev for internal testing domains before it was a TLD, either by specifying the domains in my hosts file, or with a local DNS server. Now i use .test for that, which is actually a reserved suffix that would never be a real TLD.
- chatmasta 4y ago
  Just to expand on why you should use .test for this, it's a reserved TLD according to RFC 2606 [0] and should therefore be guaranteed never to be issued by any registrar. Alternatively, you could use any of the other 11 reserved TLDs: .测试, .परीक्षा, .испытание, .테스트, .טעסט, .測試, .آزمایشی, .பரிட்சை, .δοκιμή, .إختبار, .テスト e.g. we use `https://www.splitgraph.test https://www.splitgraph.test` for local development, which is nice because we avoid a whole class of "works in dev" bugs that you get with `http://localhost:3001 http://localhost:3001` For the certificate, we use a self-signed certificate signed by a root cert generated by mkcert [1] locally on each developer's machine (to avoid sharing a root cert that could be used to MITM each other). [0] https://en.wikipedia.org/wiki/.test https://en.wikipedia.org/wiki/.test [1] https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
  - RulerOf 4y ago
    I created a subdomain like local.example.com and pointed it at 127.0.0.1 in the DNS. I wanted to suggest using a .test domain but managing the hosts file is always really clunky, even with a slick tool like hostess[1]. 1: https://github.com/cbednarski/hostess https://github.com/cbednarski/hostess
- qwertox 4y ago
  I have a shortname.cc domain which I use for testing. This allows me to issue Let's Encrypt certificates for *.shortname.cc, which includes local.shortname.cc. The internal DNS server masks the public one, so that I can assign local IPs at will, use HTTP or HTTPS at will, and when I'm outside of the network, the devices will contact the public DNS server and use the actual public IP of the network to access a limited set of servers (like ejabberd). These servers then stay accessible on the inside but through the local IPs, so that they don't have to leave the local network touching the edge router (which also solves some NAT issues on WebSocket connections).