5 ms·

Google controls the .dev TLD. It has been delegated to them. They’re not using it randomly.

darklajid 9y ago
I feel you misunderstood the GP. Rewriting/expanding the statement using my words, this is what they said: "I don't know why people (developers) thought they could start using random TLDs for local/testing purposes". Yes, Google got the TLD and controls it now. The GP isn't criticizing Google (although I still think "we bought a TLD for internal use" is worth debating), they criticize people like the blog author for using 'random' (i.e. "not meant for that purpose") TLDs in their development process.
- deleted 9y ago
  [deleted]
tomjen3 9y ago
Yes and no - if I add it to my dns system, then my computer should use that as a basis. That is the entire point of DNS. The problem here is that Chrome works around that system, which causes pains for others.
- icebraining 9y ago
  DNS was always a system for fetching information from SRI's NIC official master database. It was never supposed to be itself a source of truth for everything related to a domain.
- CydeWeys 9y ago
  You shouldn't be locally rebinding domain names that exist on the global Internet. That is a recipe for disaster, as it makes your test suite and potentially even application logic dependent on your /etc/resolv.conf. It can cause spectacularly difficult-to-debug issues down the road as well as leaks of potentially confidential data (this is what ICANN's Controlled Interruption process was designed to mitigate). And you just can't expect other developers to have to change their DNS config just for tests to pass. The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606
  - chimeracoder 9y ago
    > The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606 Unfortunately, not one of those four is designed for the use case of "private domain, for use in production", which is pretty common for companies to use. .test is for "testing of current or new DNS related code" .example is for "documentation or examples" .invalid is for "online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid" .localhost is for the loopback (and using it otherwise breaks existing code) Nothing prevents the first three from being used for this purpose, but at best it's semantically awkward and jarring. What sysadmin wants services running on an internal VPN to use the TLD ".test" or ".example"?
    - detaro 9y ago
      So use the first option for production services. What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly.
      - chimeracoder 9y ago
        > What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly. No, but you do actually have to reserve the public domain, which can be inconvenient or undesirable for all sorts of reasons.
        CydeWeys 9y ago
        Not doing so is way worse though. You could be leaking all sorts of internal requests to a malicious attacker who does register that domain name.

I feel you misunderstood the GP. Rewriting/expanding the statement using my words, this is what they said: "I don't know why people (developers) thought they could start using random TLDs for local/testing purposes". Yes, Google got the TLD and controls it now. The GP isn't criticizing Google (although I still think "we bought a TLD for internal use" is worth debating), they criticize people like the blog author for using 'random' (i.e. "not meant for that purpose") TLDs in their development process.

deleted 9y ago
[deleted]

tomjen3 9y ago

Yes and no - if I add it to my dns system, then my computer should use that as a basis. That is the entire point of DNS. The problem here is that Chrome works around that system, which causes pains for others.

icebraining 9y ago
DNS was always a system for fetching information from SRI's NIC official master database. It was never supposed to be itself a source of truth for everything related to a domain.
CydeWeys 9y ago
You shouldn't be locally rebinding domain names that exist on the global Internet. That is a recipe for disaster, as it makes your test suite and potentially even application logic dependent on your /etc/resolv.conf. It can cause spectacularly difficult-to-debug issues down the road as well as leaks of potentially confidential data (this is what ICANN's Controlled Interruption process was designed to mitigate). And you just can't expect other developers to have to change their DNS config just for tests to pass. The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606
- chimeracoder 9y ago
  > The best practice for at least the past decade has been to either use subdomains of globally resolving domains that you own, or use one of the four testing TLDs specified in RFC 2606 that are guaranteed to never be delegated: https://tools.ietf.org/html/rfc2606 https://tools.ietf.org/html/rfc2606 Unfortunately, not one of those four is designed for the use case of "private domain, for use in production", which is pretty common for companies to use. .test is for "testing of current or new DNS related code" .example is for "documentation or examples" .invalid is for "online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid" .localhost is for the loopback (and using it otherwise breaks existing code) Nothing prevents the first three from being used for this purpose, but at best it's semantically awkward and jarring. What sysadmin wants services running on an internal VPN to use the TLD ".test" or ".example"?
  - detaro 9y ago
    So use the first option for production services. What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly.
    - chimeracoder 9y ago
      > What's so bad about service.company-internal.com? (or service.internal.company.com, but some people understandably prefer having them totally separated) You don't have to actually resolve the internal names publicly. No, but you do actually have to reserve the public domain, which can be inconvenient or undesirable for all sorts of reasons.
      - CydeWeys 9y ago
        Not doing so is way worse though. You could be leaking all sorts of internal requests to a malicious attacker who does register that domain name.