3 ms·

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 l

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).

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).