8 ms·

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

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.
        chimeracoder 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. It is, but again, it doesn't help that none of the reserved TLDs actually address the primary use case here for a lot of companies. We can both agree that the companies should be registering their private domains, but clearly most aren't, and there's no reason they shouldn't have a free, reserved-for-private use space that does address it.
        JdeBP 9y ago
        Actually, there are at least two reasons, which are in boldface in the Frequently Given Answer that I have already mentioned. * http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html

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.
      - chimeracoder 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. It is, but again, it doesn't help that none of the reserved TLDs actually address the primary use case here for a lot of companies. We can both agree that the companies should be registering their private domains, but clearly most aren't, and there's no reason they shouldn't have a free, reserved-for-private use space that does address it.
        JdeBP 9y ago
        Actually, there are at least two reasons, which are in boldface in the Frequently Given Answer that I have already mentioned. * http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html