A new company registers the domain name of contoso.com. The company has a web
presence on the Internet. All Internet resources have names that use a DNS suffix of
contoso.com.
A third-party hosts the Internet resources and is responsible for managing the contoso.com
DNS zone on the Internet. The zone contains several hundred records.
The company plans to deploy an Active Directory forest.
You need to recommend an Active Directory forest infrastructure to meet the following
requirements:
Ensure that users on the internal network can resolve the names of the company’s Internet
resources.
Minimize the amount of administrative effort associated with the addition of new Internet
servers.
What should you recommend?
A.
A forest that contains a single domain named contoso.local
B.
A forest that contains a root domain named contoso.com and another domain named
contoso.local
C.
A forest that contains a root domain named contoso.com and another domain named
ad.contoso.com
D.
A forest that contains a single domain named contoso.com
It’s going to be C.
.local and the type are considered poor practice.
naming the forest ad.contoso.com is going to mitigate having to setup split brain DNS (which is a viable solution but more work).
Sorry. It’s D. Just setup split brain DNS.
None of these are good answers, but C is the closest.
You don’t use a non-routable TLD anymore- period. You can’t get SSL certs which will make hosting anything a pain.
Creating a splitbrain DNS is also terrible because I’ve encountered various configurations where no amount of aliases or A records will fix it. If http://www.domain.com is hosted externally on a load balancer, you can’t just put in the IP and make it work.
Making the forest root ad.domain.com is the best solution.
https://support.microsoft.com/en-us/kb/909264
If the organization has an Internet presence, use names that are relative to the registered Internet DNS domain name. For example, if you have registered the Internet DNS domain name contoso.com, use a DNS domain name such as corp.contoso.com for the intranet domain name.
https://technet.microsoft.com/en-us/library/cc738121%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
If you chose a registered suffix that is already in use on the network, select a prefix for the forest root domain name by using the prefix rules in Table 2.8. Add a prefix that is not currently in use to create a new subordinate name. For example, if your DNS root name is contoso.com, then you can create the Active Directory forest root domain name concorp.contoso.com, if the namespace concorp.contoso.com is not already in use on the network. This new branch of the namespace will be dedicated to Active Directory and can be integrated easily with the existing DNS implementation. When selecting a prefix, consider the following:
http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in-your.html
Update: Since this post was written, there has been a major new development with fabricated TLDs. The CA/Browser forum, which is a consortium of web browser vendors and public CAs has released a document titled: Internal Server Names and IP Address Requirements for SSL: Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses provided by the CA/Browser Forum. It can be found here (warning: direct link to PDF).
This document states that no major certificate vendor will issue an SSL certificate for an address with a made up TLD in it, such as .local, .lan, .corp, etc. This echos the best practices that have been published for years, but now has real tangible consequences attached to it.
What’s wrong with A ? Use the internal DNS of contoso.local for local name resolving and resolve external names by forwarding to the external DNS of your provider. No split brain DNS needed. Can it be simpler ?
Given the answer choices, A is correct. The ideal configuration would be a forest root named ad.contoso.com, but that’s not one of the options. The requirements say nothing about SSL certs for anything internal, only that internal users must be able to resolve the public servers’ names and that adding more public servers should require a minimum of administrative effort. Using a .local name satisfies both of those requirements.
In this configuration, if you do need an SSL cert for an internal server, you’ll configure a pinpoint DNS zone for it with whatever public FQDN is on the cert. This is MUCH easier than trying to deal with internal and external domains with the same DNS name when the external servers are controlled by someone else.