Now that the ICANN is allowing custom Top Level Domain names and often corporate IT workers like to use .local as the TLD for internal networks, if someone does buy the .local TLD what are some possible dangers a user could encounter?

The main example I can think of is spear-phishing attacks. If a company has computers like SuperSecureServer.local on their LAN and a malicious attacker makes TotallyARealCorporateServer.local would TotallyARealCorporateServer.local resolve to the attackers IP? If it did, the attacker could send a bad link then could impersonate a real server and get domain login credentials.

up vote 25 down vote accepted

To answer your specific question, .local has already been reserved by ICANN as an internal gTLD. Please see section "Reserved Names" in the ICANN Applicant Guidebook.

The full list of reserved gTLDs are:


*Note that in addition to the above strings, ICANN will reserve translations of the terms 
"test" and "example" in multiple languages. The remainder of the strings are reserved 
only in the form included above

(There is an addendum to the above to state that "similarity" metrics are applied to make sure that gTLDs like .1ocal are not abused, either.)

  • 1
    Maybe this question is not so much about .local, but an attacker knowing about an internally used fantasy-named TLD. I know various companies that use different TLD's than .local, eg. .intra or .network ... – jippie May 9 '12 at 17:40
  • 1
    Understood, which is why I stressed that the answer was to this specific question. – logicalscope May 9 '12 at 17:49
  • 3
    @jippie, Using a name you don't own or control is asking for trouble at some point, and should be avoided or repaired. The reserved list from ICANN exists so that can be avoided for some common cases, such as internal names, testing, and examples in documentation. – RBerteig May 9 '12 at 18:51
  • RFC 2606 defines only four reserved top level domain names (.test, .example, .invalid, .localhost). Is it only a subset of the reserved names list provided in the ICANN Applicant Guidebook? Which one is the official one? – Niavlys Jan 11 at 10:17

That depends on the DNS configuration for the local networks. I would assume most companies have their own DNS servers which, aside from knowing where to ask for DNS records for other domains, also declare themselves as authorative for the .local TLD. Assuming all clients are pointing at these DNS servers, owning the .local TLD wouldn't help an attacker one bit.

DNS is a distributed system of naming; some servers give authorative answers for domain names and others simply cache the responses; the responses are valid for a given window of time. This leads rise to cache poisoning, since it is possible for a rogue server to alter the authoritative response before caching, hence the suggestions for implementation of DNSSEC. However, for this problem the authoritative server is also the first one that receives our request, so .local DNS queries would be answered from the zone records the DNS server has.

Yes, this does also mean that your network administrators could set their DNS server up as authoritative for .com.

I've been wondering about this as well. As Ninefingers says, if you have your own DNS servers, it won't help attackers one bit.

But what happens when the company employees bring home their laptop and connects to the internet from home? As long as they don't establish a VPN connection they will hit public DNS servers which will point them to the public authority for the mentioned domain. Am I right?

So to speculate: If company XYZ has an internal windows domain called xyz.internal and a DC called, and someone buys .internal then he will be able to establish a subdomain called xyz.internal and an A record called dc1. When employees bring home their laptops, then they will try to authenticate against the public and if he is sniffing the traffic, then there you have the problem.

Now, the real question: Is this a legimate threat? Is it a realistic scenario? Is it worth starting a complete domain migration over?

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.