4 ms·

> 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 TL

> 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
        CydeWeys 9y ago
        Good points. I'd also say that, while having TLDs for testing usage is acceptable, there should never be any designed for production use as that would seemingly endorse the idea. The best practice (to use domains/subdomains that you own) should always be followed, and just because people do the wrong thing doesn't mean ICANN or the IETF should go out of their way to make the wrong thing easier to do.
- pmontra 9y ago
  Use service.internal.company.com instead and you'll be safe because all requests will go to your servers.
  - detaro 9y ago
    I don't understand your comment, that's on of the options I suggested?
CydeWeys 9y ago
I provided the answer in my previous comment that you quoted: "use subdomains of globally resolving domains", or alternatively, just use global domain names, e.g. company.com for external services and companyprod.com for internal services. Google uses a combination of all of the above. Domain names that only resolve internally are a security anti-pattern. You should have full authentication on all services, and not rely on simply being able to reach a service in order to grant access. See e.g. DNS rebinding as one attack vector that can really ruin your day if you don't do this.
- pmontra 9y ago
  There was a post a few days ago about a systemd resolv feature that resulted in (almost) permanently switching to the secondary DNS when the primary failed. The primary is an internal DNS resolving private domains. The secondary could be 8.8.8.8. It's easy to see what can go wrong if the private domain is somebody's else domain on the public internet. A kind of honeypot for any kind of web request.
  - JdeBP 9y ago
    Indeed. I wrote a Frequently Given Answer about it in 2003, years before systemd and years before the 2008 events mentioned elsewhere in this discussion. Because people were seeing exactly that. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam... I also wrote a Frequently Given Answer describing some more of the mistakes that people have made over and over in this, that one should learn from and not repeat. * http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
    - CydeWeys 9y ago
      I like the facts presented in your second link, but unfortunately the tone that it is written in means that it is unlikely to be received well by anyone it is linked to. Have you considered revising it?

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
      - CydeWeys 9y ago
        Good points. I'd also say that, while having TLDs for testing usage is acceptable, there should never be any designed for production use as that would seemingly endorse the idea. The best practice (to use domains/subdomains that you own) should always be followed, and just because people do the wrong thing doesn't mean ICANN or the IETF should go out of their way to make the wrong thing easier to do.
pmontra 9y ago
Use service.internal.company.com instead and you'll be safe because all requests will go to your servers.
- detaro 9y ago
  I don't understand your comment, that's on of the options I suggested?

CydeWeys 9y ago

I provided the answer in my previous comment that you quoted: "use subdomains of globally resolving domains", or alternatively, just use global domain names, e.g. company.com for external services and companyprod.com for internal services. Google uses a combination of all of the above. Domain names that only resolve internally are a security anti-pattern. You should have full authentication on all services, and not rely on simply being able to reach a service in order to grant access. See e.g. DNS rebinding as one attack vector that can really ruin your day if you don't do this.

pmontra 9y ago
There was a post a few days ago about a systemd resolv feature that resulted in (almost) permanently switching to the secondary DNS when the primary failed. The primary is an internal DNS resolving private domains. The secondary could be 8.8.8.8. It's easy to see what can go wrong if the private domain is somebody's else domain on the public internet. A kind of honeypot for any kind of web request.
- JdeBP 9y ago
  Indeed. I wrote a Frequently Given Answer about it in 2003, years before systemd and years before the 2008 events mentioned elsewhere in this discussion. Because people were seeing exactly that. * http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-same-service.html http://jdebp.eu./FGA/dns-client-all-proxies-must-provide-sam... I also wrote a Frequently Given Answer describing some more of the mistakes that people have made over and over in this, that one should learn from and not repeat. * http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html http://jdebp.eu./FGA/dns-use-domain-names-that-you-own.html
  - CydeWeys 9y ago
    I like the facts presented in your second link, but unfortunately the tone that it is written in means that it is unlikely to be received well by anyone it is linked to. Have you considered revising it?