3

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.

3
  • There are a lot of horror stories like that, first leakages like in gowenfawr's answer and then just complete misunderstanding when trying to access real names. This setup is basically an alternate root and nothing good comes out of this (as long as it is not a completely off the Internet experiment). People did the same thing with IP addresses and then merges and NAT were nightmares. There are even more horror stories when people used .dev as Google added it to the HSTS preloading list... The good solution is to register a domain name and use it as suffix for all internal needs. – Patrick Mevzek Jul 10 '20 at 23:01
  • And this also hinders DNSSEC. – Patrick Mevzek Jul 10 '20 at 23:03
  • "this somehow conflict with some fundamental way on how DNS and name resolution is supposed to work?" to the spirit at least, because the DNS is a tree, each node is delegated from the parent. Is exampleinternalsite.int really delegated (that is registered) from int? No, so in a sense you are not doing proper DNS setup with a tree and delegations. – Patrick Mevzek Jul 10 '20 at 23:04
2

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.

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.

2
  • (I disagreed with the referenced answer about using things like .CORP, etc. see comments there). But there is ongoing discussion to have a RFC telling people they are able to use any ccTLD reserved at ISO level for private DNS needs as it is "guaranteed" they will never get allocated. See tools.ietf.org/html/draft-arends-private-use-tld-01 "In addition, exactly 42 alpha-2 code elements are not used in the ISO 3166, AA, QM to QZ, XA to XZ, ZZ." – Patrick Mevzek Jul 10 '20 at 23:05
  • 1
    "Well, it's bad manners, and any breakage that resulted would be well-deserved." The problem is not just for the perpetrator of this misbehaving, as it has consequences for everyone. Because everyone abused .mail or .corp using them in configuration and real deployment, these TLDs will never exist for real, ICANN saying basically "we see far too much traffic for them (leakage), so if we create them, it will break a lot of networks, hence they are permanently reserved and not registered". – Patrick Mevzek Jul 10 '20 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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