Hacker News Reader

Comment by Sylamore | Hacker News Reader

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

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

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.

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

[RFC 6762]: https://tools.ietf.org/html/rfc6762

[RFC 7686]: https://tools.ietf.org/html/rfc7686

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.

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/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.

The 1/8 IP block, unlike anything from RFC1918, was never supposed to be used by anybody internally. RFC1918 was published 22 years ago so people have had ample time to stop being foolish.

With a totally internal DNS setup it doesn't matter even if ICANN does decide to create a ".ars" TLD someday. In such a theoretical setup, your clients are all querying your own internal DNS servers, and you are not publishing or pushing anything to the root nameservers. Your use of internal hostnames and rDNS for ".ars" internally does not conflict with or hurt anybody's use of their own domains in the real-world .ars out on the public Internet, and neither does their use of the domain affect your non-internet-connected management network. There is no "stepping over other domains".

> In such a theoretical setup, your clients are all querying your own internal DNS servers, and you are not publishing or pushing anything to the root nameservers.

And in the usages of 1.1.1.1, no one was publishing anything on BGP or pushing it out to global routing tables. However, they were building their own infrastructure (and, in the case of consumer routers, their customers' infrastructure) on the assumption that this portion of the namespace would never refer to an external resource they'd actually want to access.

Similarly, if you use .ars, you're taking up that namespace from the perspective of your internal users. If at some point it turns out that there is some resource under that name that you want to access, you're going to have a hell of a time rebuilding your infrastructure to not use that name.

tl;dr don't use random names in a globally-managed namespace. Even if you're the only person seeing those name -> resource mappings, you can end up with inconsistencies between your own usage and the globally-managed version.

> Similarly, if you use .ars, you're taking up that namespace from the perspective of your internal users. If at some point it turns out that there is some resource under that name that you want to access, you're going to have a hell of a time rebuilding your infrastructure to not use that name.

No, you're not, because an internal management network does not have a gateway out to the internet. The management VRF does not talk to the global routing table. There would be no way to access a public .ars website even if you did not take its namespace.

If it is never going to be exposed to the public internet, you might as well use .com, then at least when it does get connected to the public internet you’ll get feedback that it is broken pretty quickly.

I think the risk in that case is that I, a cloud computing startup also called BurritoCorp, get .burritocorp registered as a real TLD to host my state-of-the-art cloud services that perfectly solve the peculiar infrastructure needs of on-demand Mexican food delivery consumer brands such as yours, but sadly you have to block the entire TLD to prevent collisions with your internal infrastructure, because when I first launched, I caused a four-hour outage for you.

Internally your OS resolver will be configured to point to a different DNS than anyone external to your network. You essentially have a private branch of the DNS at that point. The only real potential for conflict is when the FQDN of an internal server is the same as for an external server. In that case your internal DNS will serve up a record pointing to your internal server, and external users will get a record pointing to an external server. If staff want to order fresh burritos over the Burrito-over-TCP protocol that will have to use separate equipment. But nobody outside your intranet will ever see a name conflict.

I could see an IT department using these (misguidedly) for purely internal purposes: .cam .camera .coop .drive .equipment .institute .media .network .systems .wiki. These are now registered TLDs. You are begging for someone to misconfigure something if you use trivial TLD names internally.

Reply on news.ycombinator.com