4 ms·

.local implies multi-cast DNS, you can't get a signed certificate for .local from any major certificate vendor either. See: http://www.mdmarra.com/2012/11/why-

.local implies multi-cast DNS, you can't get a signed certificate for .local from any major certificate vendor either. See: http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in...

walrus01 8y ago
To avoid stupid software breakage you should never use .local for anything. Choose any other TLD for internal use, doesn't matter what it is, as long as it isn't a real TLD that exists in the new gTLD and ccTLD system. On a large scale for all internal stuff you are going to have your own, internal root and intermediate CA. The root CA signs the intermediate CA, the intermediate CA then signs SSL/TLS certificates for your internal infrastructure things. As an example for a mid sized ISP with such a setup, the internal ticket portal for the NOC is accessible only while physically in the office or when on the VPN, speaks TLS1.2 only to standard web browser clients, and its URL is https://portal.tickets.burrito https://portal.tickets.burrito where the "burrito" is obviously not the real name, I've changed it for this example, but the choice of TLD in your own internal DNS infrastructure is totally arbitrary. Then the individual clients all have the public certs for the internal corporate root and intermediate CA installed in them, so that they trust certificates signed by the internal CA. If you're big enough to care about having a serious multi-state-scale intranet, you probably don't want to be reliant upon external CAs to sign your stuff. Having your own internal CAs lets you do a lot of other things as well, without additional cost, such as sign per-client-device certificates as well.
- enzanki_ars 8y ago
  Please do not suggest people use TLDs that are not a part of the gTLD, ccTLD, sTLD, or any other TLD system. Just because they are not used now does not mean they will never be used. We just saw the effects of that with 1.1.1.1 DNS system, where people assumed it would never be used, and when it does, now things break. Currently, the only reserved TLDs are: - [RFC 6761] example - [RFC 6761] invalid - [RFC 6761] localhost - [RFC 6761] test - [RFC 6762] local - [RFC 7686] onion With the exception of localhost, local, and onion, these can be used without any worry about future use. Any others should be considered real TLDs and not be used unless you actually own the domain name under that TLD. [RFC 6761]: https://tools.ietf.org/html/rfc6761 https://tools.ietf.org/html/rfc6761 [RFC 6762]: https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762 [RFC 7686]: https://tools.ietf.org/html/rfc7686 https://tools.ietf.org/html/rfc7686
  - walrus01 8y ago
    First, you're absolutely correct that people should not just choose random TLDs and attempt to use them. But I think you misunderstand me: I'm talking about doing purely internal DNS for things in private IP space that will never touch the internet. IP space that will never be announced to BGP peers and is thoroughly firewalled off from the Internet. Let's say I have an ISP named Burrito Corporation. I want to uniquely address equipment in my private management IP space VRF and have a proper hostname for every piece of equipment, both for "forward" and rDNS. It's a pretty common setup to have internal BIND servers which are authoritative master/slave for the TLD .burritocorp , which also have an ACL allowing the internal IP space (10/8, etc) to query them. Then set up all internal DNS stub resolvers/client devices to query those servers. Now I have a core POP in Toronto and I've decided to use airport codes for site names, so the internal management IP interfaces for things at that site might get a hostname which is hierarchically contained under yyz01.ca.burritocorp It is unlikely in the extreme that ICANN is ever going to create a TLD named "burritocorp". I am not suggesting that people go and try to use self-created TLDs for things that have real world IPs in the global BGP4 routing table. See section 6.1 of RFC6761.
    - enzanki_ars 8y ago
      I understand, but 1.1.1.1 was used by people for internal use, for example as a default for portals on wifi routers. Because of that, now anyone that wants to use the 1.1.1.1 DNS server can not when they are on wifi routers that use that IP as the traffic does not go where it was intended. For example, my username is enzanki_ars. Let's say I set up enzanki.ars at home as a host for an in home only server. Now let's say that a new country registers .ars as a new TLD, for example Argentina as ARS is the ISO 4217 currency code for the Argentine peso. Now I am stepping over someone else's TLD, an someone could even register enzanki.ars before me and start using it. My personal policy is "just because you can doesn't mean you should." If I wanted to disrespect the process we have in place to prevent people from stepping over other people's domains, I would have set up enzanki.ars already. Until then, 192.168.0.0/16 is how I reference my hosts at home. Edit: See also: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp... for an up to date list of special use domains. "home.arpa." was recently assigned as one, and I may start using that one at home.

walrus01 8y ago

To avoid stupid software breakage you should never use .local for anything. Choose any other TLD for internal use, doesn't matter what it is, as long as it isn't a real TLD that exists in the new gTLD and ccTLD system. On a large scale for all internal stuff you are going to have your own, internal root and intermediate CA. The root CA signs the intermediate CA, the intermediate CA then signs SSL/TLS certificates for your internal infrastructure things. As an example for a mid sized ISP with such a setup, the internal ticket portal for the NOC is accessible only while physically in the office or when on the VPN, speaks TLS1.2 only to standard web browser clients, and its URL is https://portal.tickets.burrito https://portal.tickets.burrito where the "burrito" is obviously not the real name, I've changed it for this example, but the choice of TLD in your own internal DNS infrastructure is totally arbitrary. Then the individual clients all have the public certs for the internal corporate root and intermediate CA installed in them, so that they trust certificates signed by the internal CA. If you're big enough to care about having a serious multi-state-scale intranet, you probably don't want to be reliant upon external CAs to sign your stuff. Having your own internal CAs lets you do a lot of other things as well, without additional cost, such as sign per-client-device certificates as well.

enzanki_ars 8y ago
Please do not suggest people use TLDs that are not a part of the gTLD, ccTLD, sTLD, or any other TLD system. Just because they are not used now does not mean they will never be used. We just saw the effects of that with 1.1.1.1 DNS system, where people assumed it would never be used, and when it does, now things break. Currently, the only reserved TLDs are: - [RFC 6761] example - [RFC 6761] invalid - [RFC 6761] localhost - [RFC 6761] test - [RFC 6762] local - [RFC 7686] onion With the exception of localhost, local, and onion, these can be used without any worry about future use. Any others should be considered real TLDs and not be used unless you actually own the domain name under that TLD. [RFC 6761]: https://tools.ietf.org/html/rfc6761 https://tools.ietf.org/html/rfc6761 [RFC 6762]: https://tools.ietf.org/html/rfc6762 https://tools.ietf.org/html/rfc6762 [RFC 7686]: https://tools.ietf.org/html/rfc7686 https://tools.ietf.org/html/rfc7686
- walrus01 8y ago
  First, you're absolutely correct that people should not just choose random TLDs and attempt to use them. But I think you misunderstand me: I'm talking about doing purely internal DNS for things in private IP space that will never touch the internet. IP space that will never be announced to BGP peers and is thoroughly firewalled off from the Internet. Let's say I have an ISP named Burrito Corporation. I want to uniquely address equipment in my private management IP space VRF and have a proper hostname for every piece of equipment, both for "forward" and rDNS. It's a pretty common setup to have internal BIND servers which are authoritative master/slave for the TLD .burritocorp , which also have an ACL allowing the internal IP space (10/8, etc) to query them. Then set up all internal DNS stub resolvers/client devices to query those servers. Now I have a core POP in Toronto and I've decided to use airport codes for site names, so the internal management IP interfaces for things at that site might get a hostname which is hierarchically contained under yyz01.ca.burritocorp It is unlikely in the extreme that ICANN is ever going to create a TLD named "burritocorp". I am not suggesting that people go and try to use self-created TLDs for things that have real world IPs in the global BGP4 routing table. See section 6.1 of RFC6761.
  - enzanki_ars 8y ago
    I understand, but 1.1.1.1 was used by people for internal use, for example as a default for portals on wifi routers. Because of that, now anyone that wants to use the 1.1.1.1 DNS server can not when they are on wifi routers that use that IP as the traffic does not go where it was intended. For example, my username is enzanki_ars. Let's say I set up enzanki.ars at home as a host for an in home only server. Now let's say that a new country registers .ars as a new TLD, for example Argentina as ARS is the ISO 4217 currency code for the Argentine peso. Now I am stepping over someone else's TLD, an someone could even register enzanki.ars before me and start using it. My personal policy is "just because you can doesn't mean you should." If I wanted to disrespect the process we have in place to prevent people from stepping over other people's domains, I would have set up enzanki.ars already. Until then, 192.168.0.0/16 is how I reference my hosts at home. Edit: See also: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml https://www.iana.org/assignments/special-use-domain-names/sp... for an up to date list of special use domains. "home.arpa." was recently assigned as one, and I may start using that one at home.