Home > Articles > Operating Systems, Server > Microsoft Servers

Like this article? We recommend

Heterogeneous Environments

In the real world, DNS has been managed effectively on UNIX servers for years. Many UNIX administrators see no added value to implementing Microsoft DNS. This section addresses some of the issues from both perspectives.

This section discusses the issues that may arise when Microsoft DNS servers are used in a mixed environment with non-Microsoft DNS servers. Because the Microsoft DNS server is RFC-compliant, it is fully interoperable with all other RFC-compliant DNS servers. However, because the Microsoft DNS server provides a wider spectrum of features than specified in the RFC, you are advised to exercise caution when using these features. These features are limited to the use of Windows Internet Name Services (WINS), WINSR resource records, and UTF-8 character encoding.

Using WINS and WINSR Records

Because currently only Microsoft DNS servers support the WINS and WINSR resource records, I recommend disabling replication of these records if all the following conditions are satisfied:

  • The primary copy of the zone contains one of these records.

  • At least one of the secondaries resides on a non-Microsoft DNS server.

At the same time, if the secondaries reside partially on Microsoft and non-Microsoft DNS servers, disabling WINS and WINSR resource records replication may require manual input of these records to the secondary zones residing on the Microsoft DNS servers.

Using UTF-8 Characters Format

The Windows 2000 DNS server can be configured to allow or disallow the use of UTF-8 characters on a per-server or per-zone basis. A non-UTF-8–aware DNS server may accept a zone transfer of a zone containing UTF-8 names, but it might not be able to write back those names to a zone file or reload those names from a zone file. Administrators should exercise caution when transferring a zone containing UTF-8 names to a non-UTF-8–aware DNS server.

Receiving Non-RFC–Compliant Data

If an Active Directory domain controller supports a secondary zone and receives unknown resource records, it drops such records and continues zone replication. The secondary server also drops circular CNAME resource records if it receives them.

UNIX/BIND

Storing your Microsoft DNS information in Active Directory offers a significant advantage. In standard DNS, replication is single master, pushing updates to secondary servers. This leaves a single point of failure, so many companies implement primary and backup DNS servers. However, if you implement ADS storage of DNS, replication is multi-master because ADS replicates between the domain controllers running DNS on your network. With ADS storage of Microsoft DNS, you don't need to manage a separate replication structure, transfers are secure (managed by trusts in AD), and there is no single point of failure. You can also send standard zone transfers to other servers as necessary. With ADS storage, DNS data is converted to an object model in which a DNS name becomes the object and the resource record set is the attribute.

Performance and manageability advantages promote the integration of AD with DNS. There are a few caveats. For one, only primary zones can be AD-integrated, so the DNS zone must be running Windows 2000, not a third-party DNS such as BIND or NetWareDNS. Only domain controllers can host AD-integrated zones, although you can have read/write access from any client loaded with the DNS snap-in. Another is the manual process of importing current zone files into Windows 2000 DNS. The only current method for doing so is to move the pre-created zone file in the systemroot\system32\dns folder and then indicate to use that zone file when you set up the zone as primary. Then you can convert this zone to an AD-integrated zone.

However, despite all these new features and caveats, the challenge remains for corporations whether they will implement Microsoft DNS into their environments and how they will perform this integration.

The primary benefits for interoperability in these environments include

  • Full interoperability with other DNS server implementations that implement RFC- compliant behavior for DNS name service

  • Use of Windows DNS servers to provide DNS service on the Internet

For interoperability testing, the Windows 2000 development team has tested the Windows 2000 DNS Server service with the following versions of the Berkeley Internet Name Domain (BIND) DNS server implementation:

  • BIND 4.9.7

  • BIND 8.1.2

  • BIND 8.2

Active Directory is completely dependent on DNS. However, great challenges and significant planning go into designing an effective directory service. Perhaps the greatest of these challenges in the enterprise for Microsoft AD implementation is interoperability. Because most enterprises currently host their DNS on UNIX servers running BIND, exactly how to integrate Active Directory into this environment will prove challenging. Because clients in a Windows 2000 environment look up SRV resource records in the DNS server to locate their network's AD and services, it is important that UNIX servers have recent BIND versions installed to perform these functions.

Some of the new DNS requirements of Active Directory are as follows:

  • Support of SRV records (RFC 2782)

  • Recommended support of dynamic updates (RFC 2136)

  • Recommended support of incremental zone transfer (IXFR) (RFC 1995)


Note - BIND 8.2.2 or higher supports DNS extensions used by Active Directory.


Windows 2000 clients use DNS for name resolution and for locating domain controllers for logon. Down-level clients (Windows NT 4.0 and earlier, Windows 9x) rely on NetBIOS, which uses WINS, broadcast, or LMHOSTS files. WINS is used for domain controller location. Because Windows 2000 DNS is WINS-aware, a combination of DNS and WINS can be implemented in a mixed environment. Windows NT 4.0 clients can register in Windows 2000 WINS, and Windows 2000 clients can register in Windows NT 4.0 WINS.

The minimum DNS requirement for Active Directory integration is support of SRV resource records. BIND 4.9.6 and higher versions meet this requirement. However, upgrading to at least 8.x is strongly recommended to support dynamic updates. Note that BIND 8.2.2 supports integration with Active Directory, including dynamic updates, incremental zone transfers, and SRV record updates.

The Dynamic Update Protocol (RFC 2136) allows hosts to register domain names and IP addresses with the name service, which in turn allows for automatic namespace updates and alleviates manual administrative updates—which is important if you're using DHCP to assign IP addresses dynamically.

The Incremental Zone Transfer Protocol (RFC 1995) allows for incremental updates in the zone transfer process as opposed to transferring the entire zone file. This protocol alleviates bandwidth demands during zone transfers.

The Service Location Resource Record (RFC 2782) allows services to be published in DNS by specifying the location of the server(s) for a specific protocol and domain. The SRV record is used to locate AD services such as LDAP at port 389. It does not use round robin as an A record query would.

To determine whether your version of BIND supports dynamic record updates, use the nsupdate tool that ships with BIND. You can create a test domain and its zone file in your DNS server. Then you can turn on dynamic updating by using the nsupdate tool to perform manual dynamic updates.


Note - It is imperative that you coordinate and plan your Active Directory and UNIX DNS integration with your current DNS team.


Although implementing AD and Microsoft DNS may sound quite enticing to the Windows support team of a larger company, if you are operating in a heterogeneous environment, the debate over directory services may fall nothing short of a technological holy war.

Many large enterprises have been hosting their DNS domains on UNIX servers for a long time. From their perspective, why change something that isn't broken, especially to an unproven and proprietary Microsoft product? Windows DNS has raised the stakes by complying with Internet standards and providing a wider spectrum of features than specified in the current RFC documents. Because of its advanced features, you need to be cautious when planning integration, particularly AD-integrated zones.

Microsoft believes strongly the following features of Windows 2000 DNS make it a good choice for corporations looking to implement a reliable hierarchical distributed network environment:

  • AD integration

  • Incremental zone transfer

  • Dynamic update and secure dynamic update

  • Unicode character support

  • Enhanced domain locator

  • Enhanced caching resolver service

  • Enhanced DNS Manager

  • Record scavenging

Remember that some of the UNIX Internet DNS servers in your environment are currently stable and secure. Add to this the fact that many UNIX administrators feel that Microsoft tends to "alter" existing technologies and preface them with its name (that is, Microsoft TCP/IP, Microsoft DNS), and you understand their concern.

DNS Integration Options

When you're integrating AD into an existing DNS infrastructure, your discussions should focus on whether the AD namespace will join, overlap, or trump your existing DNS namespace. If you are in a larger corporation, chances are the AD service you are designing will need to be integrated into the existing DNS infrastructure. Let's take a closer look at the three options for integrating Windows 2000 DNS into your current DNS.

If you are seriously considering installing Microsoft DNS as part of your Active Directory implementation, your three options are as follows:

  • Implement Microsoft DNS in AD and replace current DNS services.

  • Integrate your UNIX DNS structure into the DNS required for Windows 2000.

  • Maintain your UNIX DNS structure with Windows 2000.

Your choice depends on a variety of variables, including your current DNS infrastructure and specifications, as well as the many pending political issues.

Windows 2000 DNS as Primary DNS

Option 1, implementing proprietary Microsoft DNS with Active Directory, is Microsoft's choice for obvious reasons. And if your company is committed to redesigning your DNS infrastructure around Windows 2000 Active Directory, this is your choice. If you have older UNIX machines running older versions of BIND (such as 4.x) and feel the upgrade process is not worthwhile based on the enterprise shift to Active Directory, consider this option. Migration from Windows NT 4.0 DNS is relatively easy.

Migrating to Windows 2000 DNS

When migrating UNIX DNS servers to the Windows 2000 DNS, you should first introduce Windows 2000 DNS servers as secondary servers. Configure a zone transfer from a master to a secondary Windows 2000 DNS server, and make sure no errors occur in the zone transfer process. You may receive errors if the Windows 2000 DNS server cannot recognize records sent by the UNIX DNS server during the zone transfer. You should either repair or remove the records from the zone in order for the zone transfer to complete successfully. You can also FTP the forward and reverse zone files from your UNIX DNS server (db.xxx files located in etc/named.boot or etc/named.conf, depending on the BIND version) to the C:\winnt\ system32\dns directory on your Windows 2000 DNS server.

When moving from a BIND DNS server to DNS service, however, you need to copy and rename any BIND-created zone or boot files that you intend to use with the DNS service. Also, if you continue to use a BIND boot file to provide the initial configuration settings used by the DNS service when it is started, you need to change the boot method used by the DNS service.

To migrate from BIND-based server zones to Windows 2000 DNS servers, perform the following steps:

  1. At your Windows 2000 server computer, install a DNS server.

  2. Using the DNS console, at the new server add secondary zones for all your existing zones hosted at the BIND-based DNS servers.

    Configure the BIND servers as the master servers for each of the secondary zones you need to create.

  3. Initiate zone transfer at your Windows 2000 DNS servers to transfer the zones from the BIND servers.

  4. After completing the zone transfers, convert any of the secondary zones to primary zones that were obtained from primary zones at the BIND servers.

  5. For the other secondary zones that remain, update the master servers for those zones to use the new primary servers running Windows 2000 server.

If you continue to use your BIND DNS servers as secondary servers for zones for which your DNS server running Windows 2000 server is the primary server, you should review interoperability issues related to zone transfer for this configuration.

Keep in mind that any zone files created and stored on UNIX DNS servers that use BIND need to be manually copied from those servers to the systemroot\system32\dns folder on the computer running Windows 2000 server and appropriately renamed. BIND zone files have a different naming convention from that used by DNS servers running under the DNS service provided in Windows operating systems.

After you transfer the files, you can upgrade your secondary zones to AD-integrated zones. You should change the SOA resource record to one of the AD-integrated DNS servers. Then you can terminate your UNIX DNS servers (to avoid duplicate SOA records for the same zone) and remove them from the network.

One disadvantage comes in the form of integration. AD-integrated zones must be stored on DCs in the same domain. If you need it to cross domains, you must create secondary zones at other DNS servers outside the domain.

BIND as Primary DNS

You can integrate your current DNS structure into the DNS required for Windows 2000. If your current DNS meets the recommended requirements for Windows 2000 and you have tested dynamic updates, you can integrate it with Active Directory. This includes BIND 8.2.2 and higher, as well as Novell's NetWare 5.0. Remember that BIND 4.9.6 and 4.9.7 meet the minimum requirements. However, BIND 8.x supports dynamic updates and incremental zone transfers, and is strongly recommended for integrating with Active Directory.

The advantage to integrating your current DNS structure into Windows 2000 DNS is that less administrative effort is required to implement. Your company can maintain its current equipment and infrastructure. UNIX and NT administrators can cohabitate, and you can focus on your Windows 2000 implementation as opposed to fighting the DNS war.

Some disadvantages are that many UNIX DNS servers are running BIND 4.x, which may create a crossroads situation: upgrade or convert. The possible increase in future administrative overhead and manual data entry may be an issue. There will also be a single point of failure for dynamic registrations.

A final option is to supplement your current DNS structure with Windows 2000. If your company hasn't installed and maintained recent BIND versions on your root DNS servers, and issues have been minimal, you may decide that there's no reason to "fix something that's not broken." UNIX administrators may approach Microsoft's entry into the directory services arena very cautiously. With this option, you avoid the replacement of your current DNS, as well as additional effort.

You can delegate a new Windows 2000 DNS namespace from the existing DNS structure. When a DNS namespace is delegated off an existing DNS tree, the DNS server that owns the zone file for the newly delegated namespace becomes the primary master for that namespace. The DNS zone name should correspond to the ADS root domain. This is recommended if you want the benefits of the Windows 2000 DNS server. You can continue using the existing DNS server without delegating the Active Directory namespace as long as current DNS servers support the SRV records and dynamic updates.

One advantage of this option is that your initial integration efforts are minimized. You don't have to revamp your entire DNS infrastructure. Because your current DNS root is UNIX-based (north-rim.com), you can configure a subdomain (w2k.north-rim.com) and create a new zone strictly for your Windows 2000 clients. Another advantage is that you reduce Active Directory's dependence on your current DNS and avoid any potential incompatibility problems.

A disadvantage to this option is that it requires a separate namespace for Windows 2000 logons. This may increase administrative overhead in the long run, including managing dual DNS services. However, companies running DNS on BIND are familiar with distributed or "localized" DNS support, so hierarchical support of DNS as mentioned in this option is quite common already. As a result, many companies will likely opt for this integration solution.

If you are using the BIND boot file with the DNS service after migration, other limitations apply to the use of this file by the DNS service. For example, some BIND boot directives are not supported—in particular, xfrnets and other directives provided with versions of BIND, such as version 8.1.1 or higher.

If you are accustomed to manually editing DNS zone files, be aware that the DNS service uses RFC-compliant notation for its supported resource records (RRs). In most cases, the DNS service interprets and loads RRs from zone files originally created for BIND DNS servers without any need for file changes. If, however, you have used nonstandard record formatting, the DNS service will detect these edits and interpret them as bad or errored zone data.

DNS Considerations for Active Directory

When you select the option to install and configure a DNS server using the Active Directory Installation Wizard, zones are created based on the DNS name you specified during the process of promoting the server to a domain controller. Other tasks might also be useful when the first server in the domain is promoted to a domain controller, such as changing the zone type from standard primary to Active Directory–integrated and changing the update policy for the zone to Allow Only Secure Updates.

If you are deploying DNS to support Active Directory, a simple method for redundancy and fault tolerance planning is to have a DNS server running on each domain controller. For each subnet, a good rule to follow is to have two Windows 2000 server computers configured as domain controllers so that they are also running as DNS servers that load and store only Active Directory–integrated zones.

By observing these guidelines for simplified DNS and Active Directory configuration, you can enable your DNS servers to fully leverage the enhanced benefits of using Active Directory and Windows 2000 DNS servers, such as integrated storage, merged replication of Active Directory and DNS data, and secure authentication when allowing dynamic updates.

Zone Transfers Between AD and BIND

When transferring a zone between two Windows 2000 DNS servers, the DNS Server service always uses a fast transfer method that uses compression. This method includes multiple resource records in each message sent to complete the transfer of the zone between servers. For Windows 2000 DNS servers, this is the default method used when initiating transfer with other DNS server implementations.

If necessary, the servers can be configured to transfer a zone using the slower uncompressed transfer format. This way, you can make successful zone transfers with DNS servers that do not support the faster transfer method, such as BIND servers prior to version 4.9.4.

When the BIND Secondaries option is checked on the Advanced tab of the server properties, no fast transfers are made (see Figure 3.8). By default, the check box is cleared to enable fast transfers.

Figure 3.8
Enabling slow transfers to BIND servers.

Supporting Active Directory with Other DNS Server Implementations

In many large organizations, DNS is already implemented using other solutions, such as UNIX DNS servers that run legacy versions of BIND software. In some cases, these DNS servers are not equipped to support the DNS requirements for deploying Active Directory. This issue can be addressed in one of two ways:

  • Upgrade any BIND DNS servers to version 8.1.2 or higher to meet the DNS requirements for Active Directory support.

  • Use the DNS service provided with Windows 2000 server to migrate, if possible, any of your current DNS zones to Windows 2000 DNS servers.

Although the DNS service is recommended to support Active Directory, you can use other DNS server implementations for this purpose. These other implementations should support the (SRV) resource records (RFC 2782) and dynamic updates in DNS (RFC 2136).

Support for dynamic updates is recommended but not essential. Support for the SRV resource record is mandatory because it is required to provide basic DNS support to Active Directory. Windows NT Server 4.0 (updated to Service Pack 4 or higher) supports the DNS requirements of Active Directory including SRV RRs. It does not support IXFRs or dynamic updates.

Additional manual administration of SRV resource records is needed for DNS configuration support of Active Directory to function properly on a DNS server that does not support dynamic updates. For more information, see the "SRV Records" section earlier in this chapter.

If you decide to use Windows DNS service and manage it with a split DNS configuration in which one of the following is true:

  • Existing DNS servers for root zones are not to be upgraded or migrated to other DNS solutions

  • The DNS service and Windows 2000 server are to be deployed and provide management of any DNS domain names required to register, update, and support for use with Active Directory

Then you can modify your DNS namespace design plans in either of the following ways:

  • Create a single new subdomain in your current DNS domain namespace to root your first Active Directory domain.

    For example, if your organization has registered and is using a second-level domain name, such as north-rim.com, you can create a single subdomain such as ad.north-rim.com and use this domain to root the DNS domain namespace used by Active Directory. The DNS service is automatically configured to support Active Directory when you install the first domain controller.

    Before you create a zone for the new subdomain at a computer running the DNS Server service, you can delegate these subdomains away at the primary zone for your second-level domain, such as north-rim.com. In some cases, you might only need to notify another DNS or UNIX system administrator in your organization to make the delegation for you.

  • Create multiple subdomains based on your DNS second-level domain to support registration of Active Directory in DNS.

For example, if your organization has a registered second-level DNS domain name already in use (such as north-rim.com), you can create additional subdomains that are delegated to Windows DNS servers and used only for registering DNS names related to Active Directory.

This method is more complex to implement but causes less change to your currently deployed DNS infrastructure that is not Windows-based. With this namespace design, you create only those additional subdomains and appropriate zones needed to support your Active Directory deployment. For example, in this configuration, the domain name north-rim.com is both the root DNS and the root Active Directory domain name for your organization.

For this configuration, you first need to create zones for the following subdomains using the DNS snap-in tool at a computer running DNS service and Windows 2000 server:

    _msdcs.north-rim.com

    _ldap._tcp.north-rim.com

Before these zones are created, you can delegate these subdomains away at the primary zone for your parent or second-level domain name or notify another DNS administrator who manages these zones for your organization to do so.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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