Home > Articles > Operating Systems, Server > Microsoft Servers

Managing the Directory

  • Print
  • + Share This
Like this article? We recommend

Like this article? We recommend

4.2: DNS and Active Directory

The DNS Namespace

Previous versions of Windows NT were built on NetBIOS. To provide name resolution services for NetBIOS over the Transmission Control Prococol/Internet Protocol (TCP/IP), the Windows Internet Name Service (WINS) was created. This allows you to resolve 16-character NetBIOS names to Internet Protocol (IP) addresses.

For more information on the Windows Internet Name Service, see Chapter 8.4, "Windows Internet Name Service (WINS)."

One of the chief designs of Windows 2000 is the removal of the dependency on NetBIOS. The designers of Windows 2000 made the decision to move to a pure IP implementation. To provide name resolution services in Windows 2000, the Internet Engineering Task Force (IETF) standard Domain Name System (DNS) is used.

DNS is a hierarchical naming system. Names in DNS are composed of host names and Domain names. The Domain names consist of a series of names separated by periods (for example, na.mycompany.com). There are two fundamental principles to the DNS namespace. First, each child can have only one parent. Second, each parent can have only one child with any given name. This works the same way as the file system on your PC. Every file can exist only in one directory and the filename must be unique in that directory.

For more information on DNS and name resolution, see Chapter 8.3, "Domain Name System (DNS)."

In Windows 2000, all Domains and the computers in those Domains must have DNS names. Additionally, several key services register names. Chapter 1.2, "Introduction to Active Directory," provides an introduction to these concepts, including Domain Controllers and Global Catalog Servers. These service records are extremely important for the proper functioning of the Active Directory. In Windows 2000, these records are generally used for one of these three things:

  • Creating the replication topology for the Active Directory. The Knowledge Consistency Checker (KCC) uses specific DNS records to create the replication topology.

  • For more information on Active Directory Replication, see Chapter 4.3, "Configuring a Domain Controller."

  • Finding the location of Windows 2000 Domain Controllers and Global Catalog Servers. Windows 2000 clients use these records to find the appropriate Domain Controller or Global Catalog Server, based on that servers proximity to the client.

  • Finding the location of standard Kerberos services. Because Windows 2000 can provide standard Kerberos services to non-Windows 2000 clients, these records are important to ensure that those clients can find the correct servers. Examples of these records include the Kerberos Password Change servers and the Key Distribution Centers.

With two exceptions, Windows 2000 Domain names must follow all of the rules of DNS discussed previously. First, Microsoft's implementation of Windows 2000 DNS allows DNS names to contain UTF-8 characters. The UTF-8 character set is a superset of ASCII, as described in IETF RFC 2044. This was done to maintain compatibility with NetBIOS names used in Windows NT. Additionally, the UTF-8 character set includes support for most languages. Second, the DNS name of a Windows 2000 Domain cannot exceed 64 characters. This maximum was implemented due to a underlying limitation on DNS and UNC name lengths.

Beware of UTF-8 Names and Non-Windows 2000 DNS Server

If you are using the full UTF-8 character set and you are not using Windows 2000 DNS, you must ensure that your third-party DNS servers support these names. Otherwise, you will not be able to resolve these names, and these names could prevent your entire zone from loading.

In order to understand and design the DNS namespace to support your Active Directory implementation, you should follow these three steps:

  1. Understand your current DNS namespace.

  2. Plan your Active Directory based on your organizations needs.

  3. Create the additional DNS zones required to support the Active Directory.

Step 1: Understand Your Current DNS Namespace

Before designing your Active Directory implementation, you need to understand your existing DNS namespace. First, you need to know whether your organization even has an existing DNS namespace. Most companies will have some sort of DNS implementation in their current environment. Second, you need to know the names and hierarchy of the current environment. Finally, you need to know if this is a public (published on the Internet) or private namespace.

Figure 4.2.1 shows an example of a simple DNS namespace. Mycompany has an external namespace of mycompany.com with sub-domains of phx (Phoenix) and bos (Boston). Some of the machines in Phoenix and Boston need to be available on the Internet (public namespace).

Figure 4.2.1 Example of current DNS namespace.

Step 2: Plan your Active Directory Based On Your Organization's Needs

Now that you understand your organization's existing DNS namespace, it is important to begin planning for your Active Directory. Some of the most basic questions that you need to answer include "How many Domains will I need?" and "What will their names be?" It is recommended that you do not overlap with your existing DNS structure. Some of the most common implementations either create a completely separate namespace from your existing DNS implementation or simply delegate a sub-domain that will become the Active Directory's forest root.

Separate Your Internal and External DNS Namespaces

One practice that is common among large companies with public DNS namespaces is to create a DNS sub-domain named CORP under their public namespace. CORP then becomes the root of their Active Directory forest. This allows separation of public and private namespaces. Also, this allows implementation of the Active Directory without requiring any changes to the existing DNS namespace.

For more information on analyzing your current environment and planning your Active Directory, see the Deployment Planning Guide that comes with the Microsoft Windows 2000 Resource Kit.

Figure 4.2.2 shows an example of Mycompany's planned Active Directory. They will implement two Domains:

  • corp.mycompany.com: The root of the Windows 2000 forest.

  • na.corp.mycompany.com: A single Domain for all users and computers in North America.

Figure 4.2.2 Example of Active Directory implementation

Step 3: Create the Additional DNS Zones Required to Support the Active Directory

The final step is also the easiest. After you understand your current DNS namespace and have planned your Active Directory, you should simply create the appropriate DNS zones.

Figure 4.2.3 shows an example of the DNS zones required to support Mycompany's Active Directory shown in Figure 4.2.2. DNS zones need to be created for corp.mycompany.com and na.corp.mycompany.com. By creating these zones separate from the existing PHX and BOS zones, you are able to keep your existing machines in the public namespace without needing to publish your Active Directory zones on the Internet.

Figure 4.2.3 Example of DNS zones supporting the Active Directory.

The DNS Resource Records

A resource record is simply an entry in the DNS database. Resource records map the names of servers or services to their location, much the way that the Windows Internet Name Service (WINS) did in previous versions of Windows NT. This referenced location can be either the physical Internet Protocol (IP) address or the name of the server.

Table 4.2.1 lists some of the common resource record types that you will encounter in Windows 2000.

Table 4.2.1 Common DNS Resource Record Types


Abbreviation (DNS Type)


Start of Authority


Identifies the primary server that is responsible for the zone. In dynamic DNS, only the server pointed to by the SOA can accept updates.



Identifies the IP address of a server in the zone.

Name Server


Identifies a server that can respond to DNS queries for the zone (the DNS server that is authoritative for the zone).

Canonical Name(also known as an Alias Record)


Identifies another name as an alias for a server.

Service Locator*


Identifies the priority,weight, port, and server for a service.

Default Records Registered by a Windows 2000 Domain Controller

Because the Windows 2000 Active Directory is built on TCP/IP, Domain Controllers register several records in the DNS database. Mainly, these are Service Locator (SRV) records. These records allow clients to find the location of services, such as Domain Controllers, Global Catalog servers, Light-weight Directory Access Protocol (LDAP) Servers, and Kerberos Key Distribution Centers.

Table 4.2.2 lists the DNS records that are registered by the Netlogon service on Windows 2000 Domain Controllers.

Table 4.2.2 DNS Records Registered by Windows 2000 Domain Controllers




Identifies the Internet Protocol (IP) address of <ServerName>.


Identifies a LDAP server for the Domain. This record does not necessarily point to a DC.

_ldap._tcp.<SiteName>._sites. <DNSDomainName>

Identifies a LDAP server in the site and for the Domain. This record does not necessarily point to a DC.

_ldap._tcp.dc._msdcs. <DNSDomainName>

Identifies a LDAP server for the Domain. This record will always point to a DC.

_ldap._tcp.<SiteName>._sites. dc._msdcs.<DNSDomainName>

Identifies a LDAP server in the site and for the Domain. This record will always point to a DC.

_ldap._tcp.pdc._msdcs. <DNSDomainName>

Identifies the server that owns the PDC FSMO for the Domain.

_ldap._tcp.gc._msdcs. <DNSForestName>

Identifies a Global Catalog Only DCs that have the GC this record.

_ldap._tcp.<SiteName>._sites. .<DNSForestName>

Identifies a Global Catalog gc._msdcsserver in the site and for the forest. This record will always point to a DC.


Only DCs that have the GC installed will register this record.


Identifies a Global Catalog (GC) server for the Domain. This record does not necessarily point to a DC.


Only servers that have the GC installed will register this record.

_gc._tcp.<siteName>._sites. <DNSForestName>

Identifies a Global Catalog server in the site and for the Domain. This record does not necessarily point to a DC.


Only servers that have the GC installed will register this record.

_ldap._tcp.<DomainGUID>. Domains._msdcs.<DNSForestName>

Identifies a LDAP server for the Domain, as identified by its GUID. This record will always point to a DC.


Identifies a server acting as a Kerberos Key Distribution Center (KDC) for the Domain. This record does not necessarily point to a DC.


Same as previous, except specifies UDP.


Identifies a server acting as a Kerberos Key Distribution Center (KDC) in the site and for the Domain. This record does not necessarily point to a DC.

_kerberos._tcp.dc._msdcs. <DNSDomainName>

Identifies a DC acting as a Kerberos Key Distribution Center (KDC) for the Domain.


Identifies a DC acting as a Kerberos Key Distribution Center (KDC) in the site and for the Domain.


Identifies a Kerberos PasswordChange server for the Domain. This record does not necessarily point to a DC.


Same as above, except specifies UDP.


-Identifies a DC for the Domain through a standard host lookup on the Domain name.


Identifies a GC for the forest through a standard host lookup.


Identifies a DC in the forest through a standard host lookup on the DC's GUID.

The Netlogon service registers several records that may seem redundant. However, the Windows 2000 Active Directory was designed around industry standards (Kerberos, X.500, and so on). This allows the Active Directory to interoperate with many operating systems and applications. These records are required to maintain this level of interoperability.

Storing DNS Information in the Active Directory

One of the most powerful features of Windows 2000 DNS is the capability to store DNS information in the Active Directory. If a zone is stored in the Active Directory, it is said to be "Active Directory-integrated."

In order for a zone to be Active Directory-integrated, the DNS service must be installed on a Windows 2000 Domain Controller. You can set the zone type to be an Active Directory-integrated primary zone by right-clicking on the zone, selecting properties, and setting the appropriate value in the DNS MMC snap-in. Once done, this zone will be created as a container in the Active Directory. For example, location in the Active directory of the zone mycompany.com (to support the Domain mycompany.com) would be mycompany.com\system\MicrosoftDNS\mycompany.com.

All of the resource records for that zone would then be stored as objects in that container.

DNS Objects Cannot Be Updated via ADSI Scripts

Even though the DNS records are stored as objects in the Active Directory, those objects cannot be updated through ADSI scripts. The DNS objects can be updated only through standard DNS practices (client registrations, the DNS MMC snap-in, or DNSCMD.EXE).

After this data is stored in the Active Directory, there is no longer the need to set up zone transfers, as in standard DNS. These DNS objects are now replicated just like every other object in that Domain. Should you desire to replicate that zone to a member server or a server outside of the current zone, you can still set up a standard zone transfer. However, the server that the zone is being replicated to will treat that zone as a standard secondary zone. Clients cannot update records on a standard secondary zone. The clients need to send their update requests to the SOA for the zone. The SOA for that zone on the target server will point to the Domain Controller that the data was replicated from.

Why You Should Install DNS on All Your DCs

All DCs in the Domain will contain all zone containers and record objects, even if they do not have the DNS service installed. If you plan on using Active Directory-integrated DNS, it is a good idea to install DNS on all of your DCs. This will allow all your DCs to resolve DNS queries within the Domain without going to a remote system.

In addition to the simplification in replicating DNS data, there are other benefits of Active Directory-integrated DNS:

  • Multi-Master Updates

  • Secure Dynamic DNS

Multi-Master Updates

Standard Dynamic DNS allows only a single Start of Authority (SOA) record for each zone. All updates must occur on the SOA and are then replicated to the other DNS servers that house that zone.

This behavior, if not modified, would create a scalability issue for the Active Directory. As Domains get large in Windows 2000, it would not be optimal if all DCs, clients, servers, and services were required to update their DNS records through only one server. The DNS server that is the SOA would be a single point of failure for record updates.

However, if the DNS zone is stored in the Active Directory, this problem is solved. The Active Directory supports updates to objects on any DC. Because the DNS records are objects in the Active Directory, they support the multi-master behavior, as well. To allow this behavior within the confines of RFC 2136, which described Dynamic DNS, Windows 2000 allows each server to own the SOA for Active Directory-integrated zones that are installed on itself.

Secure Dynamic DNS

Another issue with standard dynamic DNS is that resource records are not protected. Only the last update to the resource record is reflected in the zone. This allows other servers or services to "steal" those records inadvertently, or, even worse, you could be susceptible to a denial-of-service attack.

To prevent these issues, an Active Directory-integrated zone can be configured to allow only secure updates. However, once enabled, only Windows 2000 systems can update that zone. Each record in the Active Directory is then ACLed with the SID of the system registering that record. Then, only that server, the system account, or an Administrator can modify that record.

Put DHCP and DNS On Separate Servers

DHCP can be configured to register the host records in DNS for clients that receive leases. If this option is turned on, you should not install DHCP and DNS on the same server. Because the DHCP service runs under the context of the System account, it has the authority to overwrite secure DNS records. This allows any DHCP client to "steal" a record from another system.

For more information on installing and configuring DHCP, see Chapter 8.2, "Dynamic Host Configuration Protocol (DHCP)."

Maintaining Zones in Windows 2000 DNS

With dynamic DNS, it is possible for records to be added to zones, but never deleted. Additionally, with the introduction of Secure Dynamic DNS, those records would be ACLed to the original owning server. If that server becomes unavailable, other servers are prevented from updating (or reusing) those records.

To solve these issues with dynamic DNS zones continuously expanding due to these stale records, Microsoft introduced the concept of aging and scavenging DNS records.

Aging and Scavenging is configured by setting parameters on both a per-zone and per-server basis. This allows you to specify which servers can scavenge which zones. Through careful planning, you can keep your zones clean and prevent having a server scavenge records that have been refreshed on, but not replicated from another server.

Table 4.2.3 Configurable Parameters for Aging and Scavenging DNS Records

Zone Parameters

Server Parameters

No Refresh interval.

Default No Refresh interval.

Specifies the time, starting at the last refresh timestamp, during which time the server will not allow the record to be refreshed.

Sets the No Refresh interval on new zones. The default value is 7 days.

Refresh interval.

Default Refresh interval.

Specifies the time, starting at the end of the No Refresh interval during which time the server will allow the record to be refreshed.

Sets the Refresh interval on new zones. The default value is 7 days.

Enable Scavenging.

Default Enable Scavenging.

Specifies whether the zone can be scavenged.

Sets the Enable Scavenging parameter on new zones. The default value is Disabled.


Enable Scavenging.


Specifies whether any zones on the server can be scavenged. The default value is Disabled.


Scavenging Period.


Specifies how often the server will perform scavenging. The default value is 7 days.

If Aging and Scavenging are enabled, a record in that zone has a period of time during which refreshes cannot occur. This is the No Refresh interval. This interval prevents excessive replication due to a short duration between refresh attempts on the client.

Updates (changing the data in the record) can occur at any time, including during the No Refresh interval.

After the No Refresh interval has expired, the record has a period of time during which it will allow refreshes. This is the Refresh interval. After the record is refreshed by the client, the No Refresh interval starts over again. If, for some reason, the Refresh interval expires, the record will be deleted at the next scavenging.

If both the server and the zone are set to allow scavenging, scavenging will occur as dictated by the scavenging period on the server.

Use Caution When Changing the No Refresh Interval

Setting the No Refresh Interval too low could cause a dramatic increase in replication traffic. As this value is lowered, the record will be refreshed more often and then replicated to the other DNS servers. However, if you increase the value too much, you could cause the size of your DNS zones to increase. Before changing these values, you should ensure that you completely understand the rate of change for your IP addresses, as well as the size of your DNS zones. This will allow you to find the proper balance for your organization.

Using Third-Party DNS Servers with the Active Directory

Although it is physically possible, choosing to use a third-party DNS server can be quite an undertaking. Microsoft has added some key features to its DNS service that makes it better prepared to support the Active Directory. For example, support for the UTF-8 character set ensures that Windows 2000 will fully interoperate with your down-level NetBIOS names. Also, the addition of Secure Dynamic DNS provides you with a level of security against denial-of-service attacks, with which a malicious user could attempt to "steal" critical service records from your Active Directory.

However, anticipating the need for some companies to run third-party DNS servers, Windows 2000 will run with non-Microsoft DNS servers as long as those servers support Service Locator (SRV) records. If your server does not support SRV records, you need to either upgrade that server or delegate the Active Directory zones to a server that does.

Assuming that your server supports SRV records, the type of DNS server that you have will determine the level of effort required to support the Active Directory. There are two general types of DNS servers:

  • Servers that support dynamic updates

  • Servers that do not support dynamic updates

Servers that Support Dynamic Updates.

Dynamic DNS is described in the Request For Comments (RFC) 2136, "Dynamic Updates in the Domain Name System." BIND 8.1.2 is an example of a DNS service that supports dynamic updates. As long as all of your servers that will support the Active Directory are RFC 2136-compliant, you do not need to do anything special for Windows 2000 to work. However, you do lose the benefits of Active Directory-integrated zones and Aging and Scavenging, discussed earlier in this chapter.

Servers that Do Not Support Dynamic Updates

If your server does not support dynamic updates, as described in RFC 2136, it is highly recommended that you upgrade your server to a version of DNS that does. BIND 4.9.x and earlier versions are examples of DNS services that do not support dynamic updates. Using a server that does not support dynamic updates is strongly discouraged. However, if the upgrade is not an option, you must manually update the correct DNS zones to ensure that the Active Directory will function correctly. You will need to do the following:

  • Implement a manual process for updating host records for all clients and servers.

  • Implement a manual process for registering Domain controller records.

Implement a Manual Process for Updating Host Records for All Clients and Servers

It should be safe to assume that if you are using non-dynamic DNS servers in your environment today, you have an adequate manual process for adding and removing host records. Having such a process in place is extremely important, especially for the host records for your Windows 2000 Domain Controllers. The Active Directory Service Locator (SRV) records will point to those host records.

Implement a Manual Process for Registering Domain Controller Records

For every Domain Controller in your forest, you will need to manually update all of the records listed in Table 4.2.2, earlier in this chapter. To assist you, the Netlogon service creates a file on each Domain Controller that contains these records. This file is %systemroot%\config\NETLOGON.DNS.

You must be very careful to enter each of the records in the correct zones. Some of the DNS records need to be in the zone for the local Domain, whereas some of the records need to be in the zone for the forest root. Maintaining the accuracy of these zones over time is also very important. If you delete and reinstall a Domain Controller, it will be necessary to update the DNS zones (because the DSAGuid will change). Also, if you remove a Domain Controller, you must remove the appropriate records from the DNS.

Due to the features that Microsoft's DNS provides, it is the ideal choice for supporting Windows 2000. As a general rule, it is not recommended that you run a third-party DNS server to support the needs of the Active Directory. However, with a solid plan and careful implementation, it is possible to set up a reliable infrastructure without using Microsoft's DNS service.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020