6 ms·

The .dev TLD worked fine before it was bought. Now we have to use .test or .local. I don't get what Google thinks they'll get out of sponsoring putting sites u

by pluc 8y ago

The .dev TLD worked fine before it was bought. Now we have to use .test or .local. I don't get what Google thinks they'll get out of sponsoring putting sites under development online.

fastball 8y ago
Why do you need to use .test or .local? Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?
- bepvte 8y ago
  HSTS is required for .dev
  - fastball 8y ago
    Install a root cert? Takes 1 minute.
    - sascha_sl 8y ago
      Yeah sure takes one minute, one minute of wondering if you really wanna bash your head against a wall getting openssl to spit out an X509 cert and then some.
      - AckSyn 8y ago
        OpenSSL isn't that difficult to work with.
      - Spivak 8y ago
        Or use any of the million utilities for setting up a machine-local CA. mkcert is one.
        reaperducer 8y ago
        You mean wait six to eight months for the IT security department in another division of the company in another state to -maybe- approve my cert request. Not all web development is three guys on Linux laptops at WeWork.
        Spivak 8y ago
        Why would you need a real cert? This is for your local machine, right? Use the tool, generate a CA, important into Mozilla's trust store, and go nuts. I'm trying to imagine a webdev workflow where you couldn't get a machine-local CA working.
        Aeolun 8y ago
        No admin privileges to manipulate the certificate store is one.
        Spivak 8y ago
        You shouldn't need admin to add a CA to the Windows User Trusted Root Store. https://docs.microsoft.com/en-us/windows/desktop/seccrypto/system-store-locations https://docs.microsoft.com/en-us/windows/desktop/seccrypto/s...
        reaperducer 8y ago
        I do development. I do not use Windows.
        fastball 8y ago
        If you're a big org, presumably you could just get your org to just buy the TLD if it's that much trouble. Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
- deleted 8y ago
  [deleted]
jtreminio 8y ago
If you've any developers on your team that use MacOS, avoid .local since it does some listening on this for Bonjour: https://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-domains/ https://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-dom... I believe .localhost is the "official" recommended TLD for local development.
- Spivak 8y ago
  Way more things than MacOS use mDNS for service discovery. That TLD is reserved for that use.
- cpburns2009 8y ago
  According to RFC 2602 [1], > The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host. [1]: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606
  - ameliaquining 8y ago
    .test, .example, and .invalid are also reserved by the RFC and don't have this problem.
    - cpburns2009 8y ago
      > ".test" is recommended for use in testing of current or new DNS related code. This one looks the safest and least prone to confusion. > ".example" is recommended for use in documentation or as examples. > ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. Both of these look problematic from a terminology standpoint, not a technical one.
      - 8y ago
robjan 8y ago
It's always best to follow the RFCs [1] to avoid issues like this. ".dev" worked but it was never safe to use it. 1: https://tools.ietf.org/html/rfc2606#page-2 https://tools.ietf.org/html/rfc2606#page-2
solatic 8y ago
Why do you have to use either one of those? If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services. You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.
- reaperducer 8y ago
  Why do you have to use either one of those? I’m not the OP, but I’m in the same boat. Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.
byuu 8y ago
.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.) I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.
- eeeeeeeeeeeee 8y ago
  If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use? It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
  - byuu 8y ago
    I guess I just don't like multi-billion dollar companies coming in and dictating that I change my workflow for their cash grabs.
    - eeeeeeeeeeeee 8y ago
      Who bought it is irrelevant. It could have been released to the public in a similar way to .com and the same issue would remain. The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow. Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
      - CydeWeys 8y ago
        Thankfully RFC 2606 ensures that that will never happen.
        8y ago
bjt 8y ago
One company I worked at thought it would be a good idea to use .local for their global internal network. Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.
steventhedev 8y ago
Google weren't supposed to make it generally available. From their application[0]: > .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool. [0]: https://gtldresult.icann.org/applicationstatus/applicationdetails/1339 https://gtldresult.icann.org/applicationstatus/applicationde...

by pluc 8y ago

The .dev TLD worked fine before it was bought. Now we have to use .test or .local. I don't get what Google thinks they'll get out of sponsoring putting sites under development online.

fastball 8y ago

Why do you need to use .test or .local? Presumably you were already editing your hosts file or running your own DNS server in order to make .dev resolve for local development, which you can continue to do?

bepvte 8y ago
HSTS is required for .dev
- fastball 8y ago
  Install a root cert? Takes 1 minute.
  - sascha_sl 8y ago
    Yeah sure takes one minute, one minute of wondering if you really wanna bash your head against a wall getting openssl to spit out an X509 cert and then some.
    - AckSyn 8y ago
      OpenSSL isn't that difficult to work with.
    - Spivak 8y ago
      Or use any of the million utilities for setting up a machine-local CA. mkcert is one.
      - reaperducer 8y ago
        You mean wait six to eight months for the IT security department in another division of the company in another state to -maybe- approve my cert request. Not all web development is three guys on Linux laptops at WeWork.
        Spivak 8y ago
        Why would you need a real cert? This is for your local machine, right? Use the tool, generate a CA, important into Mozilla's trust store, and go nuts. I'm trying to imagine a webdev workflow where you couldn't get a machine-local CA working.
        Aeolun 8y ago
        No admin privileges to manipulate the certificate store is one.
        Spivak 8y ago
        You shouldn't need admin to add a CA to the Windows User Trusted Root Store. https://docs.microsoft.com/en-us/windows/desktop/seccrypto/system-store-locations https://docs.microsoft.com/en-us/windows/desktop/seccrypto/s...
        reaperducer 8y ago
        I do development. I do not use Windows.
        fastball 8y ago
        If you're a big org, presumably you could just get your org to just buy the TLD if it's that much trouble. Something tells me it's not actually that much trouble though, and people just like whining about minor inconveniences because it's the internet and they can.
deleted 8y ago
[deleted]

jtreminio 8y ago

If you've any developers on your team that use MacOS, avoid .local since it does some listening on this for Bonjour: https://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-domains/ https://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-dom... I believe .localhost is the "official" recommended TLD for local development.

Spivak 8y ago
Way more things than MacOS use mDNS for service discovery. That TLD is reserved for that use.
cpburns2009 8y ago
According to RFC 2602 [1], > The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. So it might work but it could be problematic if the intent is to use ".localhost" as a local network domain rather than just the local host. [1]: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606
- ameliaquining 8y ago
  .test, .example, and .invalid are also reserved by the RFC and don't have this problem.
  - cpburns2009 8y ago
    > ".test" is recommended for use in testing of current or new DNS related code. This one looks the safest and least prone to confusion. > ".example" is recommended for use in documentation or as examples. > ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. Both of these look problematic from a terminology standpoint, not a technical one.
    - 8y ago

robjan 8y ago

It's always best to follow the RFCs [1] to avoid issues like this. ".dev" worked but it was never safe to use it. 1: https://tools.ietf.org/html/rfc2606#page-2 https://tools.ietf.org/html/rfc2606#page-2

solatic 8y ago

Why do you have to use either one of those? If you're already running your own internal DNS servers (to serve .dev, .test, etc.) , then just buy a domain for your org for internal use (e.g. "<mycompany>-internal.<tld>" or "<mycompany>-private.<tld>", or if your company is "<mycompany>.com" then purchasing "<mycompany>.net" or similar), split-horizon so that queries from the Internet direct to some CDN-hosted static page saying "nothing to see here, internal use only, if you are an employee please VPN in" and internally you find the actual services. You never run the danger of your internal domain being unroutable (since you indisputably own it), none of the stuff on subdomains of your internal domain are internet-discoverable (since none of the internal services are exposed externally), you retain the flexibility of eventually making internal services Internet-routable when you get around to building out a BeyondCorp model (if you ever do), and it probably costs a negligible <$10/year in registration fees.

reaperducer 8y ago
Why do you have to use either one of those? I’m not the OP, but I’m in the same boat. Not every development environment, company, and set of IT/security policies are the same as yours. Just because you cannot envision the problem doesn’t mean the problem doesn’t exist.

byuu 8y ago

.test also works, but I like .dev more, so I have and continue to use .dev via hosts file (edit: hearing Firefox is doing the .dev HSTS preload as well, that's very disappointing to hear.) I do wish /etc/hosts accepted wildcards, though. It can be a touch annoying having to add a new rule every time I create a new subdomain.

eeeeeeeeeeeee 8y ago
If you like .dev so much instead of .test, why not use something like subdomain.[public-domain].dev.com for all of your dev use? It seems silly to continue using .dev, especially when this will now be a public and commonly used TLD. So now, if you're modifying .dev records for a local/private network, and then you or someone on that network attempts to go to a public website that is using the .dev TLD, it might not work, or you'll get a completely unexpected result. Doesn't seem worth that hassle.
- byuu 8y ago
  I guess I just don't like multi-billion dollar companies coming in and dictating that I change my workflow for their cash grabs.
  - eeeeeeeeeeeee 8y ago
    Who bought it is irrelevant. It could have been released to the public in a similar way to .com and the same issue would remain. The .dev TLD was never reserved for your dev use. If you had been doing it correctly and following the RFC, you wouldn’t have to change anything with your workflow. Now, if they ever release .test for public use then I’ll grab my pitchfork with you.
    - CydeWeys 8y ago
      Thankfully RFC 2606 ensures that that will never happen.
      - 8y ago

bjt 8y ago

One company I worked at thought it would be a good idea to use .local for their global internal network. Worked fine for Windows folks. Was an huge pain in the ass for anyone on a Mac (using Bonjour) or Linux machine (using Avahi). No auto discovery of printers.

steventhedev 8y ago

Google weren't supposed to make it generally available. From their application[0]: > .dev will operate as a closed gTLD. It will provide Google with the opportunity to differentiate and innovate upon its Google products and services through its use of the gTLD. This will promote competition in the gTLD space by inciting competitors to respond with improved gTLD operations, greater range and higher quality products and services, and⁄or the creation of their own respective gTLDs, to the benefit of all Internet users. Launching the proposed gTLD will also generate increased competition in the online marketplace by adding incremental availability to the second-level domain pool. [0]: https://gtldresult.icann.org/applicationstatus/applicationdetails/1339 https://gtldresult.icann.org/applicationstatus/applicationde...