Problems with using a non-reserved top-level domain for local DNS resolution

Question

A network administrator at my organization (let's call him "Bill") wants to configure an internal DNS with the live top-level domain (TLD) .int for internal IP address resolution (for Active Directory, internal websites, etc.). For example, the domain exampleinternalsite.int would resolve to the some internal site that isn't visible to the public. Our organization has not registered these domain names with a registrar. Now I know that this is bad practice, but Bill remains unconvinced that this shouldn't be done.

What are the problems with using a live top-level domain for internal name resolution? Specifically, what are the security implications? In addition, does this somehow conflict with some fundamental way on how DNS and name resolution is supposed to work?

Note: I originally asked this question on Network Engineering SE and was kindly referred over to this site as a better place for this question.

Answer 1

Recommendations for Active Directory domain names

As this is about Active Directory, you really should follow the best practices from Microsoft:

• From Selecting the Forest Root Domain:

  We recommend that you use DNS names that are registered with an Internet authority in the Active Directory namespace. Only registered names are guaranteed to be globally unique. If another organization later registers the same DNS domain name (or if your organization merges with, acquires, or is acquired by another company that uses the same DNS name), the two infrastructures cannot interact with one another.

   Caution

  • Do not use single-label DNS names.
  • Also, we do not recommend using unregistered suffixes, such as .local.

• From Active Directory: Best Practices for Internal Domain and Network Names:

  The short answer, as best practice:

  • Microsoft strongly recommends that you register a public domain and use subdomains for the internal DNS.
  • So, register a public DNS name, so you own it. Then create subdomains for internal use (like corp.example.org, dmz.example.org, extranet.example.org) and make sure you've got your DNS configuration setup correctly.

  Recommendation 

  Microsoft strongly suggests to work with subdomains, within a publicly registered TLD domain.

The myth that using a non-registered domain on internal DNS would be a good idea is still strong, partly because Microsoft has also suggested it before (the history is explained in the Wikipedia article for .local). Myths related to this are probably best busted by MDMarra on Why you shouldn't use .local in your Active Directory domain name. Here, I'd like to cite a security related myth:

"Since .local isn't a valid TLD, it's more secure since my AD can't be attacked from the Internet."

I actually heard this on an Active Directory certification training video today and I was shocked. It's just plain silly. You shouldn't be exposing your Domain Controllers to the Internet, period. They should be behind a firewall on the trusted side of your LAN. If you do expose them to the Internet, having a made-up TLD isn't going to help you much. This is a false sense of security that has no root in reality.

Real problems from using non-registered domain names

• You can't get SSL certificates from a public CA for a fake domain! This is even worse with the Active Directory, as Windows servers will only create CSRs for their own FQDN, that is a subdomain of the Active Directory domain name. You can create your own internal CA, but that doesn't help if you e.g. provide services for others or allow BYOD devices.

• If someone else has used the same fake domain name, it's impossible to create a trust relationship between the AD domains. Or do anything else on a shared network.

• Using invalid TLDs or .local domains causes unnecessary traffic to root name servers. (Daniël Sánchez: “What is all that crap?”, Analysis of DNS root server bogus queries.)

• Some currently non-existing TLDs may be introduced in the future. Someone could buy your internal domain before you and start using it globally. It would even be possible to abuse your users, as now they can get valid certificates for the domain.

Answer 2

What are the problems with using a live top-level domain for internal name resolution?

You may find yourself unable to reach real hosts belonging to the real organization registering that domain in the future, because your DNS queries will be short circuiting that access. You may also leak queries reflecting internal organization (server names) in some circumstances (e.g., a laptop "off the network" querying public DNS instead of corporate DNS).

Specifically, what are the security implications?

If you have systems somehow querying "real" DNS, they'll either leak dns names and/or be potentially redirected to hosts they didn't intend to go to. That could lead to credential leakage as a worst-case scenario.

In addition, does this somehow conflict with some fundamental way on how DNS and name resolution is supposed to work?

Well, it's bad manners, and any breakage that resulted would be well-deserved.

See this answer for a list of TLDs that are safe for private use.