ICANN Reserves .Internal For Private Use at the DNS Level (theregister.com)
62
The Internet Corporation for Assigned Names and Numbers (ICANN) has agreed to reserve the .internal top-level domain so it can become the equivalent to using the 10.0.0.0, 172.16.0.0 and 192.168.0.0 IPv4 address blocks for internal networks. From a report: Those blocks are reserved for private use by the Internet Assigned Numbers Authority, which requires they never appear on the public internet. As The Register reported when we spotted the proposal last January, ICANN wanted something similar but for DNS, by defining a top-level domain that would never be delegated in the global domain name system (DNS) root.
Doing so would mean the TLD could never be accessed on the open internet -- achieving the org's goal of delivering a domain that could be used for internal networks without fear of conflict or confusion. ICANN suggested such a domain could be useful, because some orgs had already started making up and using their own domain names for private internal use only. Networking equipment vendor D-Link, for example, made the web interface for its products available on internal networks at .dlink. ICANN didn't like that because the org thought ad hoc TLD creation could see netizens assume the TLDs had wider use -- creating traffic that busy DNS servers would have to handle. Picking a string dedicated to internal networks was the alternative. After years of consultation about whether it was a good idea -- and which string should be selected -- ICANN last week decided on .internal. Any future applications to register it as a global TLD won't be allowed.
Doing so would mean the TLD could never be accessed on the open internet -- achieving the org's goal of delivering a domain that could be used for internal networks without fear of conflict or confusion. ICANN suggested such a domain could be useful, because some orgs had already started making up and using their own domain names for private internal use only. Networking equipment vendor D-Link, for example, made the web interface for its products available on internal networks at .dlink. ICANN didn't like that because the org thought ad hoc TLD creation could see netizens assume the TLDs had wider use -- creating traffic that busy DNS servers would have to handle. Picking a string dedicated to internal networks was the alternative. After years of consultation about whether it was a good idea -- and which string should be selected -- ICANN last week decided on .internal. Any future applications to register it as a global TLD won't be allowed.
Been using .internal for years (Score:1)
Glad ICANN formalized it.
It's about time (Score:5, Informative)
It was great that .local was already here, but since that's been usurped by mDNS (and Apple products calling it Bonjour), you really didn't have anything conflict-free. mDNS is not centralized, so hosts just pick their own name. It's true that they are supposed to automatically resolve conflicts when hostnames already exist, though.
Re: (Score:1)
Re: (Score:2)
I've been using .local, didn't really know I'd been doing it wrong all this time.
Re: (Score:2)
I think that's what everyone was doing.
Re:It's about time (Score:5, Informative)
The .local domain is official. It's one of many that were reserved for special by IETF decades ago.
It's been extended a bit and is now in RFC6762 [rfc-editor.org] which is part of the reason for another TLD. While they're defined to be link-local addresses, quite a few big groups have adopted it. Apple uses it for Bonjour. AT&T uses it for residential services, etc. The unfortunate side effect is that if you need something then you'll discover .local is already in use.
That RFC even talks about the need: "We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose: .intranet. .internal. .private. .corp. .home. .lan." This adoption of .internal is one from the list.
Re: (Score:2)
Thank you, I was just going to check. I felt like I was being gaslight by TFA or was in some sort of a time loop and was just going to look for that RFC.
I'm pretty sure it was even discussed in a college course I had decades ago.
Re: (Score:2)
Re: (Score:3)
From RFC6762, as linked in the post I am referencing:
From "Section 3 Multicast DNS Names" of that RFC I quote:
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). The design rationale for using a fixed multicast address instead of selecting from a range of multicast addresses using a hash function is discussed in Appendix B. Implementers MAY choose to look up such names concurrently via other
Re: (Score:2)
Wait, didn't we already have .local for that? Or is that not official and just what absolutely everyone uses?
.local is for multicast only. It can't traverse subnets. That's why there was a need for another one, something you can use in your organisation with a controlled DNS.
Re: (Score:2)
Finally (Score:2)
We've been doing this for years ICANN LANAs, nice for you to finally wake up.
Re: (Score:3)
I'm not a fan of gTLD's in general, but I see no evidence that Amazon didn't follow the same process everyone else does. Anyone can apply, but they have to show they can run their own registrar. The applications are posted publicly within 2 weeks of the application window and anyone can contest them (ex. trademark claims). There are huge fees as well (the 2011 FAQ lists the evaluation fee as USD$185,000). They do not have to allow for second-level registrations.
More info: https://newgtlds.icann.org/en/... [icann.org]
FA
Re: (Score:2)
It's not anti-competitive. If anything, it's purely competitive. They got there first and paid the fees, and will continue to pay outlandish fees. You want to get in on it? Go ahead!
Was there a public auction?
Yes. And you can contest that gTLD if you'd like, though I doubt you have standing to do so.
"there will be no resellers in .book and there will be no market in .book domains."
Which is even covered in the ICANN FAQ for gTLD's - that's perfectly acceptable according to the established rules. Amazon didn't make those rules, BTW.
If I had my druthers, there would be no new gTLD's at all. Thankfully, you can run you
Re: (Score:2)
If there is a "fee" of 185k, then anyone can't do it.
Re: (Score:2)
If there is a "fee" of 185k, then anyone can't do it.
With that logic, there is nothing that "anyone" can do. People swimming underwater can't breath the free air. That's silly reductionism.
Anyone that meets the qualifications for a gTLD can get one. That includes being able to prove you can fully support being a registrar, which is also something not everyone can do, but they're not restricting things to secret deals between companies and stuff, which is what the OP was implying ("Why was Amazon allowed to seize the .book domain..?"). They weren't given any s
Re: (Score:2)
.bük
Re: (Score:2)
What is the use-case for this? In theory, software that wants a domain name should accept an address literal of the form [ip4-or-ip6-addr]. And I can't see this being useful for other than A records; what would "mx-0-my.mail.server.com.literal" even mean?
Re: (Score:3)
Re: (Score:2)
No, I meant the use case of the comment I was replying to where the poster wanted something like a-192.168.0.1.literal to synthesize DNS records on the fly.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Technically in-addr.arpa works for this, except the zone files don't have A records. You'd have to implement lookups elsewhere. I don't know of a huge number of places where an IP address won't work as a hostname.
an 8 letter TLD? might as well type the whole IP. (Score:5, Insightful)
I appreciate them finally reserving something, but they could have picked a shorter option.
Re: (Score:2)
Re: (Score:2)
Not the whole reason, but a sizable part of it, and likely the one/primary reason when initially conceived.
They're also extremely useful for hosting multiple short URL domains on a single host with a single IP address, for segregating resources and obscuring where they're located, somewhat. And, due to their registered nature (unlike IPs), they're a means to at least assure a baseline of authenticity of the information coming or going. Eg. if an IP in my logs has a proper reverse lookup, it helps authentici
Re: (Score:2)
Eg. if an IP in my logs has a proper reverse lookup, it helps authenticity of said requests.
Not really. I have a fixed IP address with my ISP, and there's a web form where I can set the reverse lookup of said IP to anything I want.
Yes, it's best current practice to verify FCrDNS [wikipedia.org] but it doesn't offer any real assurances of authenticity.
Re: (Score:2)
It's a lot harder to remember a bunch of IP addresses ...
IDK, those IPv6 ones are pretty easy. :-)
Re: (Score:2)
Yea, like .int
/trolling
Re: (Score:2)
Yea, like .int
And .float for DHCP addresses. :-)
Re: (Score:2)
I appreciate them finally reserving something, but they could have picked a shorter option.
".lan" works for me and is only 3 letters. It's been working for a few years already.
Re: (Score:2)
It's likely for IPv6 - where typing out the IP is going to be difficult especially if you don't have a nice prefix. Since memorization of IPv6 addresses is more difficult, DNS is expected to be used to help out.
Thus, it probably is easier to remember printer.internal than whatever IP your printer has. IPv6 is designed to have multiple IP addresses - you have local network fe80/16 which is a private IPv6 address you ca
Great! (Score:1)
I used to use .local for testing, but that was up until I ran into odd multicast problems. You don't really notice it until you start to use linux machines. Ever since then I've just used my registered domain or abused .lan. Now with .internal, network guys can stop (rightfully) telling us to register a domain.
Re: (Score:2)
After all the crap with .local for a domain, especially in the Windows namespace, I use a secondary domain. For example, foo.com has foo.site, and foo.site is what I use internally. This way, it is a known domain, and I'm not taking the chance of any weirdness about anything else on the domain.
I hope .internal is something that can be used without the multicast issues that .local has. I also hope it can be used for AD and other internal stuff.
RFC822 (Score:2)
I started moving sites to .internal a while ago after seeing problems with relying on a registrar for internal systems, and it's great, however in 2024 people are *still* trying to roll their own RFC822 parsers and they choke.
e.g. camera-alerts@internal fails for Amcrest cameras. Even with internal. (dot).
Set up .internal.internal for now as a subdomain to handle the derpy cases. Head's up.
Re: (Score:2)
You generally want a hostname or domain to have a dot in it regardless. On many UNIX/Linux systems, /etc/resolv.conf is set up to add a domain to a dotless host if the dotless lookup fails. It's the search resolver configuration option.
Exact Opposite for Me (Score:3)
Doing so would mean the TLD could never be accessed on the open internet -- achieving the org's goal of delivering a domain that could be used for internal networks without fear of conflict or confusion. ICANN suggested such a domain could be useful, because some orgs had already started making up and using their own domain names for private internal use only.
Personally, I find that using different domain internally and externally is a pain. I much prefer using the same domain since it simplifies many configurations. For example, if I have an SMTP server named mail.my.domain on my local network, I can configure a mail client on my laptop so it works seamlessly onsite or offsite.
Also, good luck getting a signed SSL certificate for a server using .local or .internal.
.
Re: (Score:3)
This. Domain names are cheap. Get a friggin' real domain name and use it.
And the certificate comment is on point. I have a wildcard certificate for my personal domain via LetsEncrypt, and it makes deploying certificates to internal machines a breeze.
Re: (Score:3)
This. Domain names are cheap. Get a friggin' real domain name and use it.
And the certificate comment is on point. I have a wildcard certificate for my personal domain via LetsEncrypt, and it makes deploying certificates to internal machines a breeze.
For sure, but if you use the self-hosted validation method with Let's Encrypt, your domain name needs to be resolvable on the Internet. So unless you can use some other means of validating, internal-only TLDs will not work with Let's Encrypt.
Re: (Score:3)
Which is precisely why I use a real domain name. That was the entire point of my post (and the parent post.)
For a wildcard certificate, you have to use ACME-DNS to verify with LetsEncrypt, so you do need control over a publicly-accessible DNS server, which I do have. But once the certificate is in your hands, you can distribute it to internal machines, even ones not reachable from the outside world.
Re: (Score:2)
They said wildcard. Only one hostname has to be resolvable. The rest get a certificate without being externally accessible.
Re: (Score:2)
They said wildcard. Only one hostname has to be resolvable. The rest get a certificate without being externally accessible.
From their online documentation [letsencrypt.org], Let's Encrypt wildcard certificates are issued using the DNS-01 challenge [letsencrypt.org], which states:
"This challenge asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name. Let’s Encrypt will query the DNS system for that record".
This would not be possible with an internal-only domain.
Re: (Score:2)
Reading comprehension. NEARLY internal-only.
Only one hostname has to be resolvable.
Which means all your other internal hostnames can resolve to internal IPs and still be covered under the same certificate.
Re: (Score:2)
Reading comprehension. NEARLY internal-only.
Only one hostname has to be resolvable.
Which means all your other internal hostnames can resolve to internal IPs and still be covered under the same certificate.
If you have a domain like .internal which is reserved for internal use, then NOT EVEN ONE hostname will be resolvable by the Certificate Signing Authority. Therefore you cannot get a signed SSL certificate for a .internal domain, wildcard or not, because you can't validate that you own that domain.
Re: (Score:2)
Right. That's why this entire thread from the original reply to you is about getting a real domain for internal-only use. Did you forget what you were commenting on for a minute? Just because it's for internal-only use doesn't mean it's .internal - you're mixing the two.
If you're effectively rolling your own TLD, then you are also rolling your own CA.
Re: (Score:2)
Right. That's why this entire thread from the original reply to you is about getting a real domain for internal-only use. Did you forget what you were commenting on for a minute? Just because it's for internal-only use doesn't mean it's .internal - you're mixing the two.
I understand internal-only doesn't necessarily mean it's .internal. That was merely the example at hand.
If you're effectively rolling your own TLD, then you are also rolling your own CA.
I've been discussing signed SSL certificates. It has nothing to do with self-signed certificates. Obviously if you're going to act as your own Certificate Signing Authority, you can do whatever the hell you want.
Re: (Score:2)
This. Domain names are cheap. Get a friggin' real domain name and use it.
But why pay for something you don't want to use externally? If you have something reserved for internal use you may as well use it. You don't have every device on your home network with a publicly routable IP address either do you. No you use a subnet reserved for internal network use.
There's countless networks out there without any need for an external domain, without any need to be externally reachable, and above all, without any need for you to pay a yearly fee for the purposes of running your own privat
Re: (Score:2)
Personally, I'd love to see more built in support for having the OS bring up a configured VPN connection when it's resolver gets a request for a specific domain. That way the end users won't have to do anything before starting their web browser / email client / etc.
Re: (Score:2)
Personally, I'd love to see more built in support for having the OS bring up a configured VPN connection when it's resolver gets a request for a specific domain. That way the end users won't have to do anything before starting their web browser / email client / etc.
I'm pretty sure there are VPN clients that work that way, such as Sophos ZTNA.
Re: (Score:2)
Personally, I find that using different domain internally and externally is a pain.
Who said anything about externally. There's literally countless networks out there that aren't externally accessible or routed. .internal is now reserved for that use. What next, you're going to tell use to ditch the 192.168.x.y or 10.x.y.z IP addresses and get a public IP for every device on your internal network?
Different tools, different purposes.
Re: (Score:2)
Personally, I find that using different domain internally and externally is a pain.
Who said anything about externally. There's literally countless networks out there that aren't externally accessible or routed. .internal is now reserved for that use.
Well if your network is truly isolated from the outside world, then it doesn't matter what you name it. You don't need a special internal TLD.
What next, you're going to tell use to ditch the 192.168.x.y or 10.x.y.z IP addresses and get a public IP for every device on your internal network?
LOL. One of the first TCP/IP LANs I ever setup was in 1995, and I just used a Class C netblock that our ISP gave us. It worked just fine :)
Re: (Score:2)
What next, you're going to tell use to ditch the 192.168.x.y or 10.x.y.z IP addresses and get a public IP for every device on your internal network?
Eventually. The first World IPv6 Day was in 2011. Even now AT&T won't delegate a proper prefix for a router behind their provided equipment. I have fiber, and can't get a /48 from the modem/gateway - I have to request a /64 for each LAN (and the router host subnet).
How about .local (Score:2)
Re: (Score:2)
Since .local is reserved for multicast it can't traverse subnets. There's restrictions in the RFC6762 as to what you can do with local and software is configured to follow those restrictions.
Appendix G. Private DNS Namespaces
The special treatment of names ending in ".local." has been
implemented in Macintosh computers since the days of Mac OS 9, and
continues today in Mac OS X and iOS. There are also implementations
for M
Re: (Score:2)