Your network contains an Active Directory domain named contoso.com.

You plan to deploy a child domain named sales.contoso.com.
The domain controllers in sales.contoso.com will be DNS servers for sales.contoso.com.
You need to ensure that users in contoso.com can connect to servers in sales.contoso.com
by using fully qualified domain names (FQDNs).
What should you do?

A.
Create a DNS forwarder.

B.
Create a DNS delegation.

C.
Configure root hint servers.

D.
Configure an alternate DNS server on all client computers.

Explanation:
http://technet.microsoft.com/en-us/library/cc784494%28v=ws.10%29.aspx
Delegating zones
DNS provides the option of dividing up the namespace into one or more zones, which can
then be stored, distributed, and replicated to other DNS servers. When deciding whether to
divide your DNS namespace to make additional zones, consider the following reasons to use
additional zones:
A need to delegate management of part of your DNS namespace to another location or
department within your organization.
A need to divide one large zone into smaller zones for distributing traffic loads among
multiple servers, improve DNS name resolution performance, or create a more fault-tolerant
DNS environment.
A need to extend the namespace by adding numerous subdomains at once, such as to
accommodate the opening of a new branch or site.
If, for any of these reasons, you could benefit from delegating zones, it might make sense to
restructure your namespace by adding additional zones. When choosing how to structure
zones, you should use a plan that reflects the structure of your organization.
When delegating zones within your namespace, be aware that for each new zone you
create, you will need delegation records in other zones that point to the authoritative DNS
servers for the new zone. This is necessary both to transfer authority and to provide correct
referral to other DNS servers and clients of the new servers being made authoritative for the
new zone.
When a standard primary zone is first created, it is stored as a text file containing all
resource record information on a single DNS server. This server acts as the primary master
for the zone. Zone information can be replicated to other DNS servers to improve fault
tolerance and server performance.
When structuring your zones, there are several good reasons to use additional DNS servers
for zone replication:
1. Added DNS servers provide zone redundancy, enabling DNS names in the zone to be
resolved for clients
if a primary server for the zone stops responding.
2. Added DNS servers can be placed so as to reduce DNS network traffic. For example,
adding a DNS server to the opposing side of a low-speed WAN link can be useful in
managing and reducing network traffic.
3. Additional secondary servers can be used to reduce loads on a primary server for a zone.
Example: Delegating a subdomain to a new zone

As shown in the following figure, when a new zone for a subdomain (example.microsoft.com)
is created, delegation from the parent zone (microsoft.com) is needed.

In this example, an authoritative DNS server computer for the newly delegated
example.microsoft.com subdomain is named based on a derivative subdomain included in
the new zone
(ns1.us.example.microsoft.com). To make this server known to others outside of the new
delegated zone, two
RRs are needed in the microsoft.com zone to complete delegation to the new zone.
These RRs include:
An NS RR to effect the delegation. This RR is used to advertise that the server named
ns1.us.example.microsoft.com is an authoritative server for the delegated subdomain.
An A RR (also known as a glue record) is needed to resolve the name of the server specified
in the NS RR to its IP address. The process of resolving the host name in this RR to the
delegated DNS server in the NS RR is sometimes referred to as glue chasing.
Note When zone delegations are correctly configured, normal zone referral behavior can
sometimes be circumvented if you are using forwarders in your DNS server configuration.