4 ms·
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 t
by 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 agoFirst, 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 agoI 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 agoThe 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".
- azernik 8y ago> 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.