DNS

1.DNS Basic #

DNS

This article is a detailed overview of the Internet’s Domain Name System (DNS), covering the technical and theoretical aspects behind how domain names work.

DOMAIN NAME

A domain name usually consists of two or more parts (technically labels), separated by dots. For example: mediatemple.net.

  • The rightmost label conveys the top-level domain.
  • Each label to the left specifies a subdivision or subdomain of the domain above it. Note that “subdomain” expresses relative dependence, but not absolute dependence: for example, mediatemple.net comprises a subdomain of the net domain, and www.mediatemple.net comprises a subdomain of the domain mediatemple.net. In theory, this subdivision can go down to 127 Levels deep, and each label can contain up to 63 characters, as long as the whole domain name does not exceed a total length of 255 characters. But in practice some domain registries have shorter limits than that.
  • A hostname refers to a domain name that has one or more associated IP addresses. For example, the wiki.mediatemple.net and mediatemple.net domains are both hostnames.

DNS

The Domain Name System consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the nameservers of any domains “beneath” it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD). Iterative and recursive queries:

  • An iterative query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.
  • A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and both the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.

DNS PROPAGATION

DNS Propagation refers to the time for any DNS changes to transmit across the Internet. Please remember that DNS changes in general can take up to 24-48 hours to fully propagate.

DNS RECORDS

Root Domain

The root domain (also sometimes referred to as the “parent,” “naked,” or “apex” domain) is the primary entry for the domain without any subdomains. The NAME field typically remains blank as this would define a subdomain. This type of record should usually be an A record, with the value set to the destination IP address. Using a CNAME for the root domain can cause other DNS functions, such as MX records, to route incorrectly. It is standard practice to set the A record for the root domain to that of the “www.” subdomain.

CNAME or “Canonical Name”

CNAME Records are used to define an alias hostname. A CNAME record takes this format:

alias.domain.name      IN     CNAME   otherhost.domain.name.

This defines alias.domain.name as an alias for the host whose canonical (standard) name is otherhost.domain.name.

A Record

An A record gives you the IP address of a domain. That way, users that try to go to www.example.com will get to the right IP address. An A record or “Address Record” maps a hostname to a 32-bit IPv4 address. An “A” Record takes this format (example):

Name             TTL     TYPE    DATA
ftp.domain.com   43200   A       IP Address

Media Temple DNS Zone files are written with a “wildcard” entry, that looks like this:

*.domain.com   IN   A   xxx.xxx.xxx.xxx

The x’s represnt your particular IP address. The star takes “anything” .domain.com and points it to your server’s IP address. This way, if someone mistakenly types too many or too few w’s, they’ll still see your website. This is also useful for setting up subdomains on your server, relieving you of the duty of adding an additional “A” record for the subdomain.

MX Record

Mail Exchange Record: Maps a domain name to a list of mail exchange servers for that domain. A zone can have one or more Mail Exchange (MX) records. These records point to hosts that accept mail messages on behalf of the host. A host can be an ‘MX’ for itself. MX records need not point to a host in the same zone. An ‘MX’ record takes this format:

host.domain.name       IN     MX      10 otherhost.domain.name.
IN     MX      20 otherhost2.domain.name.

The ‘MX’ preference numbers nn (value 0 to 65535) signify the order in which mailers select ‘MX’ records when they attempt mail delivery to the host. The lower the ‘MX’ number, the higher the host is in priority.

PTR Record / Pointer Record

Maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr.arpa. domain that corresponds to an IP address implements reverse DNS lookup for that address. For example, at the time of writing, www.icann.net has the IP address 192.0.34.164, but a PTR record maps 164.34.0.192.in-addr.arpa to its canonical name.

NS Record or “Name Server Record”

Maps a domain name to a list of DNS servers authoritative for that domain. In this case, for (mt) Media Temple purposes would be:

ns1.mediatemple.net
ns2.mediatemple.net

SOA Record or “Start of Authority Record”

Specifies the DNS server providing authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

TXT Record

The TXT Record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework and DomainKeys specifications.

2.Installing DNS 2012R2 #

Installing Windows 2012R2 DNS Server.

Microsoft Windows Server 2012R2 is a powerful server operating system capable of many different roles and functions. However, to prevent overloading production servers with features and options that are never used, Windows Server provides a modular approach in which the administrator manually installs the services needed. To setup and configure DNS, one must install the DNS Server Role on Windows Server 2012.

https://img.purch.com/windows-server-2012/w/600/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS8zL1EvNDQ4NTUwL29yaWdpbmFsLzFfV2luU2VydmVyMjAxMl9BZGRSb2xlcy5qcGc=

To add a new role to Windows Server 2012, you use Server Manager. Start Server Manager, click the Manage menu, and then select Add Roles and Features.

Click Next on the Add Roles and Features Wizard Before you begin window that pops up. (If you checked Skip this page by default sometime in the past, that page will, of course, not appear.)

Now, it’s time to select the installation type. For DNS servers, you will be selecting the Role-based or feature-based installation.

https://img.purch.com/windows-server-2012/w/450/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS8zL1UvNDQ4NTU0L29yaWdpbmFsLzJfV2luU2VydmVyMjAxMl9JbnN0YWxsVHlwZS5qcGc=

Next, you will choose which server you want to install the DNS server role on from the server pool. Select the server you want, and click next.

At this point, you will see a pop-up window informing you that some additional tools are required to manage the DNS Server. These tools do not necessarily have to be installed on the same server you are installing the DNS role on. If your organization only does remote administration, you do not have to install the DNS Server Tools.

However, in a crunch you may find yourself sitting at the server console or remotely using the console and needing to manage the DNS Server directly. In this case, you will wish you had the tools installed locally.

Unless your company policy forbids it, it is typically prudent to install the management tools on the server where the DNS will be housed.  Now you should see the Features window. No need to make any changes here; just click Next.

Next is an informational window about DNS Server and what it does, although one would assume that if you’ve gotten this far, you are already aware of what it is. Click Next to move on.

https://img.purch.com/windows-server-2012/w/450/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS8zL1cvNDQ4NTU2L29yaWdpbmFsLzRfV2luU2VydmVyMjAxMl9BZGRGZWF0dXJlcy5qcGc=

This is the final confirmation screen before installation completes.

You can check the box to Restart the destination server automatically, if you like. Installing the DNS Server does not require a restart, but unless you’ve planned for the downtime, keep that box unchecked, just in case.

https://img.purch.com/windows-server-2012/w/450/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS8zL1MvNDQ4NTUyL29yaWdpbmFsLzNfV2luU2VydmVyMjAxMl9JbnN0YWxsQ29uZi5qcGc=

 

 

 

 

 

 

 

The DNS Server role should now be installed on your server. There should be a new DNS Role tile in your Server Manager.

Powershell installation:

Import-Module ServerManager

Example : Install-WindowsFeature -Name <feature_name> -computerName <computer_name> -Restart

To install the dns server role only: Install-WindowsFeature -Name DNS -computerName myowncomputername -Restart

To install the DNS remote managment tools on the dns server : Install-WindowsFeature RSAT-DNS-Server

3.DNS zones and records #

Create and configure DNS zones and records

Although DNS is based on the concept of domains and subdomains, you store information about these domains and subdomains and the relationship between them in DNS zones. You can consider a DNS zone to be one or more domains and subdomains from your DNS infrastructure.

For example, the domains hottfixes.com and sales.hottfixes.com might both be stored in a DNS zone called Adatum.com, or sales.hottfixes.com might be stored in a delegated zone called sales.hottfixes.com, while the parent domain, Adatum.com, is stored in its own zone.

You can store the zone in files on the DNS server or in the Active Directory Domain Services (AD DS) database. It is important that you know how and when to create primary and secondary zones, delegated zones, AD DS–integrated zones, and stub zones.

Overview of DNS zones

Zones are used by DNS servers to resolve client DNS queries. Usually, clients perform forward lookup queries in which a hostname must be resolved into the corresponding Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) address. Forward lookup queries are resolved by reference to forward lookup zones.

Forward lookup zones contain a variety of DNS record type (discussed in the next section) include:

  • Host (A) records
  • Alias (CNAME) records
  • Records that identify which server is hosting a service, such as service (SRV) records and Mail exchanger (MX) records.

Less often, a DNS client queries a DNS server for the name of a host when it has the IPv4 or IPv6 address of the host. This is called a reverse lookup, and is satisfied by reference to a reverse lookup zone. Reverse lookup zones contain pointer (PTR) records.

Before you create your zone, you must first determine whether the zone is a forward or reverse lookup zone. Then you must determine whether the zone is primary, secondary, or AD DS–integrated. Strictly speaking, it is not the zone that is primary or secondary. Instead, it is the local copy of the zone that is primary or secondary. In other words, for there to be a secondary zone for Adatum.com, there must already exist a primary zone for Adatum.com on another DNS server from which the secondary can obtain the zone data.

When you first deploy the DNS server role in Windows Server 2016, the DNS Manager console navigation pane contains the server node, and beneath this, nodes for Forward Lookup Zones, Reverse Lookup Zones, Trust Points, and Conditional Forwarders. These nodes are all empty until you start to create zones on the DNS server.

Configure DNS zones

Windows Server 2016 supports a number of different zone types. These include primary zones, secondary zones, and Active Directory integrated zones. It’s important that you know how to create and configure these different types of zone..

Create primary zones

A primary zone is a writable copy of a DNS zone that exists on a DNS server. To create a primary zone, in the DNS Manager console, use the following procedure:

  1. Right-click the Forward Lookup Zones node, and then click New Zone.
  2. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.
  3. On the Zone Type page, select Primary Zone, as shown in Figure 1-17, and then click Next.

FIGURE 1-17

Creating a primary zone

  1. On the Zone Name page, in the Zone name box, type the zone name. For example, type Contoso.com. Click Next.
  2. On the Zone File page:
    • If you have a DNS zone file with which to populate your zone (for example, from another DNS server), click Use This Existing File, specify the path to the file, and then click Next.
    • If you do not have an existing zone file, click Create A New File With This File Name and click Next. Figure below shows the filename that is created automatically when you choose this option.

FIGURE 1-18

Defining the zone file

  1. On the Dynamic Update page, shown , choose one of the following, and then click Next:

FIGURE 1-19

Choosing dynamic updates

    • Allow Only Secure Dynamic Updates (Recommended For Active Directory) This option enables clients that support dynamic DNS to update their records in the DNS zone, such as when a client computer obtains a different IPv4 address from a Dynamic Host Configuration Protocol (DHCP) server. This option requires that each DNS record has an owner—the entity that registered the original record. Only the owner can update the record, which helps you secure your DNS records. This option is only available if you are creating an AD DS–integrated zone.
    • Allow Both Nonsecure And Secure Dynamic Updates This option also enables clients that support dynamic DNS to update their records in the DNS zone. It also supports nonsecure dynamic updates.
    • Do Not Allow Dynamic Updates Choose this option if you want to manually maintain all DNS records.
  1. On the Completing The New Zone Wizard page, click Finish.

After you have created your primary zone, you can view the initial contents of the zone by using the DNS Manager console, as shown in Figure 1-20. It contains the Start of Authority (SOA) record and a Name Server (NS) record. These two records define which computer(s) are responsible, or authoritative, for the zone.

FIGURE 1-20

Viewing the completed Contoso.com zone

You can also add a primary zone by using the Add-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to complete the same process as in the preceding example by using Windows PowerShell, run the following command:

Add-DnsServerPrimaryZone -Name “Contoso.com” -ZoneFile “Contoso.com.dns”

-DynamicUpdate None

After you have created the primary zone, you can reconfigure it from the DNS Manager console by right-clicking the zone in the navigation pane and clicking Properties. You can then configure the following properties on each of the following tabs:

  • General You can change the zone type, zone file name, the dynamic updates setting, and configure aging and scavenging.
  • Start of Authority (SOA) Shown in Figure 1-21, you can reconfigure the SOA record. This includes the Primary server’s Fully Qualified Domain Name (FQDN), the responsible person’s contact details, and the Refresh, Retry, and Expire intervals. These intervals determine:

FIGURE 1-21

Editing the Contoso.com DNS zone properties

    • Refresh interval The frequency with which other DNS servers that host the zone must refresh the zone data.
    • Retry interval The interval at which other DNS servers retry a refresh operation.
    • Expires after The length of time after failure to refresh zone data other DNS servers assume that the zone data has expired.

The Start of Authority (SOA) tab also contains the Minimum (Default) TTL value. This is the value that determines how long records in this zone can be cached by other recursive DNS servers.

  • Name Servers Use this tab to add, remove, or edit the name and IP addresses of other DNS servers that host this zone.
  • Zone Transfers Use this tab to configure how the zone data is transferred to other name servers hosting copies of the zone.
  • WINS Use this tab to configure Windows Internet Name Service (WINS) and DNS integration. WINS supports the resolution of NetBIOS names. Less relevant today, NetBIOS names use a nonhierarchical structure based on a 16-character name. Enabling the Use WINS Forward Lookup option enables the DNS server to respond to requests for NetBIOS names without the client computer having to petition a WINS server directly.

You can configure the zone properties by using the Set-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to change the Contoso.com Primary Zone Dynamic Update settings with Windows PowerShell, run the following command:

Set-DnsServerPrimaryZone -Name “hottfixes.com” -DynamicUpdate “NonsecureAndSecure”

4.Configure AD DNS Primary zone #

Configure Active Directory integration of primary zones

Traditional DNS zones are file-based and are stored in the local file system of the DNS server. DNS servers that host the primary copy of a zone have a writable version of the DNS zone file. Secondary servers have read-only copies of the zone file; they periodically obtain updates by using a zone transfer from their configured master, as you saw in Create and configure secondary zones.

In an AD DS environment, you have the option to create AD DS-integrated zones. In this situation, all copies of the zone data are writable. In addition, the zone data is stored securely in Active Directory and is replicated securely as part of the AD DS database.

The benefits of using AD DS-integrated zones are:

  • Multimaster updates AD DS-integrated DNS zones are multimaster, and updates can be made to any copy of the zone data. This provides for redundancy in your DNS infrastructure. If your organization implements dynamic updates to the DNS zone, then geographically remote DNS clients can update their records by connecting to the nearest DNS server.
  • Replicated using AD DS replication AD DS replication is based at the attribute-level. This means that only changed attributes, rather than entire records, are replicated. This means that the volume of zone transfer traffic can be reduced.
  • Secure dynamic updates You can implement secure dynamic updates in an AD DS–integrated zone. This is discussed in the next section.
  • Improved security You can delegate administration of AD DS-integrated zone, domains, and resource records with the AD DS object-level Access Control List (ACL) for the zone.

When you promote a new domain controller in your AD DS forest, the DNS server role deploys automatically. This is configurable on the Domain Controller Options page of the Active Directory Domain Services Configuration Wizard.

When you create zones on a DNS server that is also a domain controller, you have the option to install an AD DS-integrated zone. To create an AD DS-integrated DNS zone, use the following procedure:

  1. On your domain controller, open DNS Manager.
  2. Right-click the Forward Lookup Zones node, and then click New Zone.
  3. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.
  4. On the Zone Type page, select Primary Zone, as shown , select the Store The Zone In Active Directory (Available Only If The DNS Server Is A Writable Domain Controller) check box, and then click Next.

FIGURE 1-27

Selecting the zone type

On the Active Directory Zone Replication Scope page, as shown, select the appropriate zone replication option from the following:

FIGURE 1-28

Specifying the preferred zone replication scope

    • To All DNS Servers Running On Domain Controllers In This Forest This option causes the zone data to replicate to all domain controllers running the DNS server role in the forest.
    • To All DNS Servers Running On Domain Controllers In This Domain This option (the default) causes the zone data to replicate to all domain controllers running the DNS server role in the current AD DS domain.
    • To All Domain Controllers In This Domain (For Windows 2000 Compatibility) This option provides backward compatibility with earlier versions of Windows Server. You would not normally select this option.
    • To All Domain Controllers Specified In The Scope Of This Directory Partition Directory partitions enable you to create an AD DS replication boundary that is not restricted to all domain controllers in the forest or local domain. The option is only available if you have created a directory partition before you configure the DNS zone.
  1. Click Next.
  2. On the Zone Name page, in the Zone name box, type the zone name, for example, type Hottfixes.com. Click Next.
  3. On the Dynamic Update page, choose one of the following, and then click Next.
    • Allow Only Secure Dynamic Updates (Recommended For Active Directory)
    • Allow Both Non-Secure And Secure Dynamic Updates
    • Do Not Allow Dynamic Updates
  4. On the Completing The New Zone Wizard page, click Finish.

You can also create an AD DS-integrated primary zone by using the Add-DnsServerPrimaryZone Windows PowerShell cmdlet. For example, to complete the same process as in the preceding example by using Windows PowerShell, run the following command:

Add-DnsServerPrimaryZone -Name “hottfixes.com” -ReplicationScope “Domain”

On domain controllers, existing standard primary zones can be converted to AD DS–integrated zones. In DNS Manager, right-click the zone, and then click Properties. On the General page, click Change, and then select the Store The Zone In Active Directory (Available Only If The DNS Server Is A Writable Domain Controller) check box. Click OK twice.

Configure secure dynamic updates

If you have implemented an AD DS-integrated primary zone, you have the option of enabling secure dynamic updates. Dynamic updates is a feature in which DNS clients can update their own DNS records on their configured DNS server. This is particularly convenient when an organization assigns IP configuration to networked clients by using DHCP. If a client obtains a different IP address from a DHCP scope, they can register this change automatically on DNS.

With secure dynamic updates, the DNS server assigns ownership to the registered DNS records, and only the owner—the original DNS client—can update the records. To enable secure dynamic updates, you can choose one of the following options:

  • Select the Allow Only Secure Dynamic Updates (Recommended For Active Directory) option on the Dynamic Updates page of the New Zone Wizard when you create an AD DS-integrated primary zone.
  • After creating the AD DS-integrated primary zone, in DNS Manager, right-click the DNS zone, and then click Properties. On the General page, in the Dynamic Updates list, click Secure Only.
  • After creating the AD DS-integrated primary zone in Windows PowerShell, use the Set-DnsServerPrimaryZone command. For example:

Set-DnsServerPrimaryZone -Name “Contoso.com” -DynamicUpdate “Secure”

5.Configure secondary zones #

Create and configure secondary dns zones

Creating a secondary zone is a different process from a primary zone. This is because a secondary zone hosts a read-only copy of a zone, which it obtains from another DNS server.

To create a secondary zone, you must know the name of the zone, and have the name and IP address of a DNS server that hosts a copy of the zone.

The name server you specify as a source for a secondary zone does not have to be hosting a primary copy of the zone. You can point one secondary zone server to another secondary zone server. However, somewhere a primary copy of the zone must exist.

You can use the DNS Manager console to create a secondary zone. To do this, use the following procedure:

  1. Right-click the Forward Lookup Zones node, and then click New Zone.
  2. In the New Zone Wizard, on the Welcome To The New Zone Wizard page, click Next.
  3. On the Zone Type page, select Secondary Zone, and then click Next.
  4. On the Zone Name page, in the Zone Name box, type the zone name, and click Next.
  5. On the Master DNS Servers page, in the Master Servers list, type the FQDN or IP address of the server that hosts a copy of the zone, press Enter, and then click Next, as shown below.

FIGURE 1-22

Defining the master server for a secondary zone

  1. On the Completing The New Zone Wizard page, click Finish.

After you have added the secondary zone, it is necessary to configure the master DNS server that you specified. This is to enable zone transfers to your secondary server. To perform this step, switch to the DNS Manager console on the master server and perform the following procedure:

  1. Right-click the appropriate zone, and then click Properties.
  2. On the Name Servers tab, in the Name servers list, click Add to specify the FQDN and IP address of the DNS server hosting the secondary copy of the zone, as shown in . Click OK.

FIGURE 1-23

Configuring the Name Servers list

  1. Click the Zone Transfers tab.
  2. Select the Allow Zone Transfers check box. Then, as shown below, choose one of the following:

FIGURE 1-24

Configuring zone transfers

    • To Any Server.
    • Only To Servers Listed On The Name Servers Tab.
    • Only To the Following Servers (If you choose this option, you must click Edit to specify the list of name servers that you want to allow).
  1. Click Notify.
  2. In the Notify dialog box, either select Servers Listed on the Name Servers Tab, or else click The Following Servers, and then type the IP addresses of the secondary name servers you want to notify.
  3. Click OK twice to complete configuration. Next, switch back to the DNS Manager console on the server hosting the secondary zone. You should see the DNS records populate into the secondary zone. If this does not happen immediately, right-click the secondary zone, and then click Transfer From Master.

You can use the Add-DnsServerSecondaryZone Windows PowerShell cmdlet to create a secondary zone. For example, the following command creates a secondary zone for the Adatum.com zone:

Add-DnsServerSecondaryZone -Name “hottfixes.com” -ZoneFile “hottfixes.com.dns”

-MasterServers 172.16.0.10

6.Configure DNS Delegation #

Configure delegation

DNS delegation is when a DNS server delegates authority over a part of its namespace to one or more other DNS servers. For example, hottfixes.com and sales.hottfixes.com could be hosted in the same zone, hottfixes.com, with the sales.hottfixxes.com merely being a subdomain record. In this case, the authoritative DNS servers for hottfixes.com and sales.hottfixes.com are the same. There is no need for the DNS servers in hottfixes.com to refer recursive DNS servers to another domain.

Alternatively, you could create a separate zone for both hottfixes.com and sales.hottfixes.com, each with their own DNS servers. Because one domain, sales.hottfixes.com, is a child domain of another domain, hottfixes.com, there must exist a method to enable the authoritative name servers for the subdomain to be located. This method is called delegation, and is essentially a pointer to the authoritative name servers for a subdomain.

You can see two DNS zones: hottfixes.com, which contains a subdomain, marketing.hottfixes.com, and a second zone, sales.hottfixes.com, which contains a single domain, sales.hottfixes.com.

FIGURE 1-25

The hottfixes.com DNS namespace separated into two zones

When determining whether to delegate a subdomain, consider the following:

  • Your DNS zones are large, and delegation enables you to distribute the zone into smaller pieces across your organization.
  • Organizational changes, such as mergers and acquisitions, mean that you have additional subdomains to manage.
  • You have a distributed management structure, and want different departments or locations to be responsible for managing their own DNS namespaces.

To create a DNS delegation, in the DNS Manager console, perform the following procedure:

  1. Right-click the parent zone. For example, right-click hottfixes.com, and then click New Delegation. The New Delegation Wizard launches.
  2. In the New Delegation Wizard, on the Welcome page, click Next.
  3. On the Delegated Domain Name page, as shown in Figure 1-26, in the Delegated domain box, type the subdomain name. For example, type Sales. The suffix is added automatically. Click Next.

FIGURE 1-26

Delegating the sales.hottfixes.com zone

  1. On the Name Servers page, click Add.
  2. In the New Name Server Record dialog box, on the Server Fully Qualified Domain name (FQDN) box, type the name of the DNS server that hosts the new delegated zone, click Resolve, and then click OK.
  3. On the Name Servers page, click Next, and then click Finish.

You can use the Add-DnsServerZoneDelegation Windows PowerShell cmdlet to create a delegated zone in an existing zone. For example, the following command creates the sales.hottfixes.com delegated zone in the existing hottfixes.com zone:

Add-DnsServerZoneDelegation -Name “hottfixes.com” -ChildZoneName “Sales” -NameServer

“ns1.Sales.hottfixes.com” -IPAddress 172.16.0.136

After you have completed the delegation, if necessary, you should install DNS on the name server that you specified in the wizard, and create the delegated zone, in this case sales.hottfixes.com.

7.Configure DNS trust #

Before you can create a cross-forest trust in Active Directory, DNS name resolution needs to be working between the two forests. I’ll show you how to set up DNS in Windows Server so that you can establish a cross-forest trust.

A robust DNS infrastructure is critical for a healthy Active Directory. DNS can be automatically set up and configured when you install a domain controller. But when you need to create a trust between two AD forests, you will have to perform some manual configuration in DNS to ensure that name resolution works between the two forests.

Secondary Zones and Delegation

There are different ways to set up name resolution between two DNS domains. One is creating a secondary zone on your DNS server. A secondary zone contains a complete copy of a DNS zone from another DNS server. For example, I could create a secondary zone for kofschip.hottfixes.com on a DNS server running in the ad.hottfixes.com domain.

Delegation allows a domain’s root DNS server to resolve queries for subdomains. When creating a delegation, you specify the subdomain to delegate and the IP address or fully-qualified domain name (FQDN) of the DNS server that will host the delegated zone. For instance, a root DNS server hosting hottfixes.com could delegate DNS for ad.hottfixes.com to another DNS server.

Stub Zones and Forwarding

Stub zones are copies like secondary zones but contain just Name Server (NS), Start of Authority (SOA), and sometimes glue Host (A) records because stub zones are not authoritative for the domain. Unlike delegation, stub zones can be copies of zones from any domain. For instance, you could create a stub zone for kofschip.hottfixes.com on a server in the ad.hottfixes.comdomain. The authoritative DNS server for kofschip.hottfixes.com must give permission for the partial zone transfer to thead.hottfixes.com DNS server.

DNS forwarders can be used to redirect lookup queries to another DNS server. In Windows Server DNS, you can configure a forwarder to send all queries that cannot be resolved by the local DNS server to another server. In addition to that, Windows Server DNS supports conditional forwarding, which sends lookup queries for a domain to another server without attempting to resolve the query locally.

Root Hints

Root hints are similar to forwarders but use iterative queries instead of recursive queries. Recursive queries are passed to a name server listed in the forwarder configuration and the client waits for an answer. Recursive queries can supply the client with a referral that requires it to query another name server. This process continues until an answer is provided. Recursive queries are more resource intensive for the client.

Set Up Conditional Forwarding

So which method should you use when configuring DNS name resolution for establishing a trust between two Active Directory forests? The most efficient way to resolve names in kofschip.hottfixes.com from ad.hottfixes.com, and vice versa, is to set up a conditional forwarder in both forests. There is no DNS root server that can be the server for both DNS domains, so delegation cannot be used.

Conditional forwarders are best suited in situations where we know that the IP addresses of authoritative DNS servers are not going to change often. Stub zones are better when authoritative DNS servers frequently change because stub zones do not usually require manual reconfiguration. Conditional forwarders provide non-authoritative responses because the zones are not hosted on the DNS server against which the queries are made. But in a secured AD environment that is OK.

It is worth noting that if you had Preferred DNS server and Alternate DNS server IP addresses set in the client list of IP addresses for the server before it was promoted to a domain controller and they were something other than the server’s own IP address those addresses are automatically added to the DNS server’s Forwarders list when DNS is installed. This configuration is not automated on servers that are multihomed. I.e. servers that are connected to more than one network.

The quickest way to create a conditional forwarder on your DNS server is using PowerShell. Log into the DNS server, open a PowerShell window, and run the command below. In this example, I am logging into ad.hottfixes.com and want to set up a conditional forwarder for the kofschip.hottfixes.com domain. I know the DNS server IP address in the kofschip.hottfixes.com domain is 192.168.1.2.

PowerShell

1 Add-DnsServerConditionalForwarderZone -Name kofschip.hottfixes.com -MasterServers 192.168.1.2

I can then repeat this action in the kofschip.hottfixes.com forest and set up a conditional forwarder for the ad.hottfixes.com domain:

PowerShell

1 Add-DnsServerConditionalForwarderZone -Name ad.hottfixes.com -MasterServers 192.168.1.1

My AD forests each have one domain controller and one DNS server. If you have more than one DNS server in a domain or forest, you can configure forwarders to be replicated in AD by adding the -ReplicationScope parameter and setting the value to Forest or Domain.

If you want to configure a DNS conditional forwarder using the GUI, here is how to do it in Windows Server 2016:

  • Log into the DNS server.
  • Open Server Manager from the Start menu.
  • In Server Manager, select DNS from the Tools menu.
  • Expand the DNS server tree in the left pane, right-click Conditional Forwarders and select New Conditional Forwarderfrom the menu.
  • In the New Conditional Forwarder window, type the name of the DNS domain for which you want to resolve queries.
  • In the list of IP addresses, click <Click here to add an IP Address or DNS Name>.

Configure a DNS conditional forwarder in Windows Server 2016 (Image Credit: Russell Smith)

Configure a DNS Conditional Forwarder in Windows Server DNS.

  • Type the IP address of the DNS server that will resolve queries from the domain you entered in the previous step and press ENTER.
  • If the DNS server can be reached, after a few seconds the Server FQDN name field will display the name of the DNS server.
  • If you want to replicate the conditional forwarder in AD, click Store this conditional forwarder in Active Directory, and replicate it as follows:
  • Select All DNS servers in this forest or All DNS servers in this domain from the drop-down menu.
  • Click OK.

Do not worry if the DNS server you enter for the conditional forwarder is not validated at first. Wait a few minutes and check the properties of the conditional forwarder again. You should see that the server has been validated.

 

8.Configure Stub zones #

Create and configure stub zones

You can use conditional forwarding as a means to redirect query traffic to a designated DNS server. With conditional forwarding, if a DNS query contains a specific domain name, for example hottfixes.com, it is forwarded to a specific DNS server. To learn more about Conditional Forwarding, see “Configure forwarders, root hints, recursion, and delegation.”

Alternatively, you can also use a stub zones to achieve a similar result. A stub zone is used by a DNS server to help resolve names between two separate DNS namespaces, such as following a merger or acquisition. A stub zone differs from conditional forwarding in that the stub zone contains the complete list of DNS servers for the other domain.

Comparing Conditional Forwarding with stub Zones

Imagine that two DNS namespaces, Adatum.com and hottfixes.com, are now owned by the A. Datum Corporation following an acquisition. For DNS clients in the Adatum.com domain to locate resources in the hottfixes.com domain it requires the use of root hints by Adatum.com DNS servers.

To avoid this, in the Adatum.com domain, you could configure DNS conditional forwarding for the hottfixes.com domain. With conditional forwarding, you configure to which DNS server(s) in the hottfixes.com domain to forward DNS queries.

You can also use a stub zone for hottfixes.com in the Adatum.com domain. This stub zone contains the complete list of DNS server that are authoritative for the foreign domain. This list of servers is updated automatically.

When considering whether to use conditional forwarding or stub zones, remember:

  • You must manually maintain conditional forwarding records, while stub zones are maintained automatically.
  • With conditional forwarding, you can designate the specific foreign DNS server to forward queries to, but with a stub zone, you cannot.

Creating a stub Zone

You can use the following procedure to create a stub zone. Open DNS Manager, and then:

  1. Right-click the Forward Lookup Zones node, and then click New Zone.
  2. On the New Zone Wizard, on the Welcome to the New Zone Wizard page, click Next.
  3. On the Zone Type page, select Stub Zone, and then click Next.
  4. On the Zone Name page, in the Zone name box, type the DNS domain name for the foreign domain, and then click Next.
  5. On the Zone File page, if you have a DNS zone file that you use to populate your zone (for example, from another DNS server), click Use This Existing File, specify the path to the file on the Zone File page, and then click Next.
  6. On the Master DNS Servers page, in the Master Servers list, type the IP address or FQDN of the DNS server in the foreign domain from which the DNS server obtains zone updates, and then click Next.
  7. Click Finish to create the stub zone.

You must now populate the stub zone with the required records that includes the Start of Authority (SOA) record, and the Host (A) and NS records that pertain to the foreign DNS servers, and are retrieved from the specific master server(s). To manually perform this task, in the DNS Manager, right-click the stub zone and then click Transfer from Master.

You can use the Windows PowerShell Add-DnsServerStubZone cmdlet to create a stub zone. For example, to create a stub zone for hottfixes.com, use the following command:

Add-DnsServerStubZone -Name “hottfixes.com” -MasterServers “192.168.0.66” -ZoneFile

“hottfixes.dns”

9.DNS Globalname zone #

Configure a GlobalNames zone

Some older networked apps rely on a non-hierarchical naming standard known as NetBIOS. In the past, network clients that accessed these apps needed to be able to resolve these single-label NetBIOS names. You can use the WINS server feature to provide for NetBIOS name registration, resolution, and release.

The dis-advantages of using WINS are:

  • Organizations must maintain two name services, with the resultant administrative overhead.
  • Network clients potentially use both DNS and WINS to resolve names, resulting in possible name resolution delay.

As an alternative to WINS, you can use the DNS GlobalNames zone in Windows Server (2016). When clients resolve single-label names, such as Hott-SVR2, these names are resolved by reference to the GlobalNames zone. An organization has only a single GlobalNames zone, which you must create manually. Also, you must populate the zone with the required CNAME resource records that point to your organization’s server and app resources.

To create the GlobalNames zone, use the following procedure:

  1. Open Windows PowerShell.
  2. Run the Set-DnsServerGlobalNameZone –AlwaysQueryServer $true command to enable GlobalNames zone support.
  3. Run the Add-DnsServerPrimaryZone –Name GlobalNames –ReplicationScope Forest command to create the GlobalNames zone.
  4. Open DNS Manager and locate the GlobalNames zone node.
  5. Create the required CNAME records for server resources that still use single-label names.

10.Setup DNS Records #

Configure DNS records

Zones contain DNS records that point either to name servers, hosts, services, or to other zones. After you have created your zones, you must populate them with records appropriate to your organization’s network. You must also be prepared to maintain these records to ensure the accuracy of zone data.

Create and configure DNS resource records

A DNS server exists to provide name resolution for DNS clients. In order for this to be possible, you must populate the DNZ zones that you create with appropriate DNS resource records. These resource records include:

  • Host A host record—commonly given the abbreviation A—holds the IPv4 address for the specified hostname. AAAA records hold the IPv6 address for the specified hostname. These are probably the most common resource records and are found in forward lookup zones.
  • Pointer Also known as PTR records, these enable a DNS client to resolve an IPv4 or IPv6 address into a hostname. These records exist in reverse lookup zones.
  • Start of Authority Created when you create a primary zone, the SOA record contains information about the authoritative server for the zone, contact information for the zone, and other information, including TTL values for resource records in the zone.
  • Name Server Name server (NS) records identify the authoritative name servers in the zone, including both primary and secondary servers. They also identify name servers for any delegated zones.
  • Service Location Known as SRV records, these enable you to specify by service, protocol, and DNS domain name, which servers are hosting particular apps or services. If a DNS client is looking for a web server, for example, you can configure SRV records for the http service enabling clients to find all servers providing that service. Clients then use corresponding A or AAAA records to resolve the server names into IP addresses. An SRV record is more complex than many others, and contains the following fields: _Service.Proto.Name TTL Class SRV Priority Weight Port Target. For example: http._tcp.Contoso.com. IN SRV 0 0 80 www.Contoso.com. AD DS services, such as the Kerberos authentication service, use SRV records to advertise themselves to clients in an AD DS network.
  • Alias CNAME records enable you to create an alias for a host. For example, the server lon-svr2.adatum.com might host a website. You can create an alias for this host with the name www by adding a CNAME record that points to the FQDN of the lon-svr2 server.
  • Mail Exchanger MX records are used by Simple Mail Transfer Protocol (SMTP) hosts for transferring email around the Internet. In order for an originating SMTP host to route mail to a recipient with the email address Dave@Contoso.com, it is necessary for the originating host to know which hosts can receive the email at Contoso.com. You create MX records in the Contoso.com namespace to advertise which hosts provide this service. To help to ensure a reliable inbound email flow, you can advertise several hosts by using multiple MX records. Each can be assigned the same or different mail server priorities, or preference values. If you implement MX records with the same priority, email is routed to them randomly, distributing the load. If you use different values, the lower value is used first by the originating server, thereby enabling you to specify a preferred inbound server.

Note Enabling Dynamic Updates

Remember that you can enable dynamic updates for your DNS zone in Microsoft DNS. This enables hosts to register and update their own resource records. This is particularly relevant for A, AAAA, PTR, and SRV records that might commonly be expected to change.

To find out more about common DNS resource record types, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/cc958958.aspx.

You can create these records manually from the DNS Manager console. Right-click the appropriate forward lookup zone (reverse lookup zone for PTR records), and then click the appropriate option for the record type you want to create, as shown in Figure 1-29.

FIGURE 1-29

Creating resource records

Creating the resource records are straightforward, but vary slightly for each record type because you must specify different information for each separately. However, this is a very intuitive process. For example, for a new host record, you must specify the host’s name and its IP address. You can also select the option to create a PTR record for the host automatically. For an MX record, you must specify the FQDN of the host that provides SMTP email support, and a Mail server priority value.

If the record type you want is not listed on the context menu, (for example, SRV), select Other New Record from the context menu. Then select the record type you want in the Resource Record Type dialog box, and then click Create Record. This list contains all record types, including those used less frequently.

FIGURE 1-30

Selecting resource record types

You can use the Add-DnsServerResourceRecord Windows PowerShell cmdlet to create resource records. For example, the following command creates a host called hott-svr2 in the Contoso.com domain:

Add-DnsServerResourceRecord -ZoneName “hottfixes.com” -A -Name “hott-svr2”

-AllowUpdateAny -IPv4Address “172.16.0.27” -TimeToLive 01:00:00 -AgeRecord

11.DNS Zone Scopes #

Configuring zone scopes

In Windows Server 2016, you can configure your DNS zones to have multiple zone scopes. Each zone scope contains its own set of DNS resource records. A resource record can exist in multiple zone scopes, each with different IP addresses depending on the scope. You can also use the zone scope to control zone transfers, enabling resource records from a zone scope in a primary zone to be transferred to the same zone scope in a secondary zone.

Typically, the first step in creating a zone scope is to create and configure client subnets. You do this in reference to your physical network topology. For example, to create subnet for DNS clients in New York and another for clients in London, use the following Windows PowerShell commands:

Add-DnsServerClientSubnet -Name “NYCSubnet” -IPv4Subnet “172.16.0.0/24”

Add-DnsServerClientSubnet -Name “LONSubnet” -IPv4Subnet “172.16.1.0/24”

Next, you create the DNS zone scopes for New York and London DNS clients by using the following commands:

Add-DnsServerZoneScope -ZoneName “hottfixes.com” -Name “NYCZoneScope”

Add-DnsServerZoneScope -ZoneName “hottfixes.com” -Name “LONZoneScope”

Configuring records in zone scopes

After you create the zone scopes, you must populate them with resource records. Again, you must do this with Windows PowerShell. To create a specific IP address record for clients in the New York City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName “hottfixes.com” -A -Name “www” -IPv4Address

“172.16.0.41” -ZoneScope “NYCZoneScope”

For clients in the London City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName “hottfixes.com” -A -Name “www” -IPv4Address

“172.16.1.22” -ZoneScope “LONZoneScope”

Configuring policies for zones

Finally, you must create the policies that instruct the DNS servers to respond to client queries based upon the previously defined factors. To configure the DNS servers to respond with resource records from the New York zone scope, create a DNS policy:

Add-DnsServerQueryResolutionPolicy -Name “NYCPolicy” -Action ALLOW -ClientSubnet

“eq,NYCSubnet” -ZoneScope “NYCZoneScope,1” -ZoneName “hottfixes.com”

Similarly, for clients based in the London zone scope, you must add another policy:

Add-DnsServerQueryResolutionPolicy -Name “LONPolicy” -Action ALLOW -ClientSubnet

“eq,LONSubnet” -ZoneScope “LONZoneScope,1” -ZoneName “hottfixes.com”

Now, if a client in the New York subnet petitions a DNS server for the IPv4 address of the www.hottfixes.comhost, the DNS server responds with the IP address 172.16.0.41. If a client in London requests the same record, the client receives the IPv4 address 172.

Configuring records in zone scopes

After you create the zone scopes, you must populate them with resource records. Again, you must do this with Windows PowerShell. To create a specific IP address record for clients in the New York City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName “hottfixes.com” -A -Name “www” -IPv4Address

“172.16.0.41” -ZoneScope “NYCZoneScope”

For clients in the London City zone scope, run the following command:

Add-DnsServerResourceRecord -ZoneName “hottfixes.com” -A -Name “www” -IPv4Address

“172.16.1.22” -ZoneScope “LONZoneScope”

Configuring policies for zones

Finally, you must create the policies that instruct the DNS servers to respond to client queries based upon the previously defined factors. To configure the DNS servers to respond with resource records from the New York zone scope, create a DNS policy:

Add-DnsServerQueryResolutionPolicy -Name “NYCPolicy” -Action ALLOW -ClientSubnet

“eq,NYCSubnet” -ZoneScope “NYCZoneScope,1” -ZoneName “hottfixes.com”

Similarly, for clients based in the London zone scope, you must add another policy:

Add-DnsServerQueryResolutionPolicy -Name “LONPolicy” -Action ALLOW -ClientSubnet

“eq,LONSubnet” -ZoneScope “LONZoneScope,1” -ZoneName “hottfixes.com”

Now, if a client in the New York subnet petitions a DNS server for the IPv4 address of the www.hottfixes.comhost, the DNS server responds with the IP address 172.16.0.41. If a client in London requests the same record, the client receives the IPv4 address 172.16.1.22.

12.Configure dns Subnet Policy #

Configure policy for DNS subnet.

Network Traffic Management Using DNS Policies in Windows Server 2016

New in Windows Server 2016 Technical Preview 2, DNS Policies allow system administrators to create rules that determine how DNS servers respond to client queries based on several different factors, including the client’s location, time of day, and transport protocol. This enables new traffic management scenarios, such as redirecting users to specific servers based on location, a new way to implement split-brain DNS, and blocking malicious domains or ensuring clients can only resolve specific names.

DNS Client Subnets and Zone Scopes

Before DNS Policies can be applied, it’s necessary to define DNS client subnets and zone scopesDNS client subnets define IPv4 or IPv6 address ranges from which DNS server queries might be received. Bear in mind that authoritative DNS servers usually receive queries not directly from clients, but from a DNS server hosted by the client’s Internet service provider (ISP). Nevertheless, ISP DNS servers are usually located geographically close to the clients they serve, so it’s reasonable to expect that the IP address of the ISP’s DNS server gives a fair approximation of the location of the client that originated the query.

Zone scopes divide DNS zones so that tailored responses can be returned depending on criteria set in DNS policy. Each zone contains a different set of records so that depending on the DNS policy applied to the query, a different IP address can be returned for a given domain name.

Configuring Client Subnets and Zone Scopes

To use DNS Policies, you’ll need to be running Windows Server 2016 Technical Preview 2 and have the DNS server role installed. For more information on installing Windows Server 2016 TP 2.

In the example that follows, we’ll redirect users to specific servers based on location, but I’ll also give examples of how to create other kinds of policies. You should also note that at the time of writing, DNS client subnets and zone scopes are not displayed in the DNS management console and can only be created and viewed using PowerShell.

Install the DNS Server Role and Create a Primary DNS Zone

If you don’t have the DNS server role installed with a DNS zone already configured, you’ll need to do some basic preparation. Log in to Windows Server 2016 with a local administrator account. Open a PowerShell prompt by clicking the PowerShell icon on the desktop taskbar and run the command below to install the DNS Server server role:

PowerShell

1 Install-WindowsFeature DNS –IncludeManagementTools

Once DNS has been installed, you’ll need to add at least one DNS zone. The command below adds a standalone DNS zone for contoso.com. A zone file is specified because the zone isn’t integrated with Active Directory.

PowerShell

1 Add-DnsServerPrimaryZone -Name contoso.com -ZoneFile contoso.com.dns

Client Subnets

In this example, I’m going to configure two DNS client subnets using the Add-DnsServerClientSubnet cmdlet, one for the London Office (192.168.1.0) and a second for Paris (192.168.2.0), both with a 24-bit subnet mask.

PowerShell

1

2

3

Add-DnsServerClientSubnet -Name LondonSubnet -IPv4Subnet 192.168.1.0/24

 

Add-DnsServerClientSubnet -Name ParisSubnet -IPv4Subnet 192.168.2.0/24

Adding DNS client subnets in Windows Server 2016 (Image Credit: Russell Smith)

Adding DNS client subnets in Windows Server 2016 (Image Credit: Russell Smith)

To list the configured DNS client subnets on the server, type Get-DnsServerClientSubnet into the PowerShell prompt and press ENTER.

Zone Scopes

Now we’ll divide the contoso.com DNS zone into zone scopes, so that queries received from different client subnets can be answered using different DNS resource records. Here two zone scopes are created, one for London, and a second for Paris.

PowerShell

1

2

3

Add-DnsServerZoneScope -ZoneName contoso.com -Name LondonZoneScope

 

Add-DnsServerZoneScope -ZoneName contoso.com -Name ParisZoneScope

To list the zone scopes created in the contoso.com DNS zone, type the command below:

PowerShell

1 Get-DnsServerZoneScope -ZoneName contoso.com

Adding DNS zone scopes in Windows Server 2016 (Image Credit: Russell Smith)

Adding DNS zone scopes in Windows Server 2016 (Image Credit: Russell Smith)

Add Resource Records to Zone Scopes

Now that the contoso.com DNS zone has been divided into zone scopes, we can add resource records to each zone scope. The commands below add an address (A) record – www – with a different IP address for the London and Paris zone scopes:

PowerShell

1

2

3

Add-DnsServerResourceRecord -ZoneName contoso.com -A -Name www -IPv4Address 192.168.1.10 -ZoneScope LondonZoneScope

 

Add-DnsServerResourceRecord -ZoneName contoso.com -A -Name www -IPv4Address 192.168.2.10 -ZoneScope ParisZoneScope

You might also want to add the records to the default zone scope, so that everyone is able to access the servers:

PowerShell

1

2

3

Add-DnsServerResourceRecord -ZoneName contoso.com -A -Name www -IPv4Address 192.168.1.10

 

Add-DnsServerResourceRecord -ZoneName contoso.com -A -Name www -IPv4Address 192.168.2.10

To list the records in each zone scope in the contoso.com DNS zone, run the three commands below:

PowerShell

1 Get-DnsServerResourceRecord -ZoneName contoso.com Get-DnsServerResourceRecord -ZoneName contoso.com -ZoneScope ParisZoneScope Get-DnsServerResourceRecord -ZoneName contoso.com -ZoneScope LondonZoneScope

Adding DNS resource records to zone scopes in Windows Server 2016 (Image Credit: Russell Smith)

Adding DNS resource records to zone scopes in Windows Server 2016 (Image Credit: Russell Smith)

Sponsored

Create DNS Policies

Once the zone scopes and DNS client subnets have been created, all we need to do is add some policies. The PowerShell commands that follow create policies to redirect queries from the London and Paris subnets to the corresponding zone scopes in the contoso.com DNS zone.

PowerShell

1

2

3

Add-DnsServerQueryResolutionPolicy -Name LondonPolicy -Action ALLOW -ClientSubnet ‘eq,LondonSubnet’ -ZoneScope ‘LondonZoneScope,1’ -ZoneName contoso.com

 

Add-DnsServerQueryResolutionPolicy -Name ParisPolicy -Action ALLOW -ClientSubnet ‘eq,ParisSubnet’ -ZoneScope ‘ParisZoneScope,1’ -ZoneName contoso.com

The –ClientSubnet parameter starts with an operator, EQ for equals or NE for not equals, followed by a list of client subnets. Operators can be combined in a string, such as ‘eq,LondonSubnet,ne,ParisSubnet,BerlinSubnet.’ The –ZoneScope parameter is a string of zone scopes, each followed by a weighting.

Creating DNS Policies in Windows Server 2016 (Image Credit: Russell Smith)

Creating DNS Policies in Windows Server 2016 (Image Credit: Russell Smith)

There’s no need to reboot the server. Once a policy has been added, it becomes effective immediately; and in the example above, queries for www.contoso.com received from Paris should resolve 192.168.2.10, and from London 192.168.1.10. To see the policies configured for the contoso.com zone, type:

PowerShell

1 Get-DnsServerQueryResolutionPolicy -ZoneName contoso.com

Policies can be removed using the Remove-DnsServerQueryResolutionPolicy cmdlet:

PowerShell

1 Remove-DnsServerQueryResolutionPolicy –Name LondonPolicy -ZoneName contoso.com

Sink Hole and Time-Based Policies

Here are some other examples of how you can use policies to manage network traffic. The policy below ensures that queries for baddomain.com are not resolved by the DNS server:

PowerShell

1 Add-DnsServerQueryResolutionPolicy -Name BlackholePolicy -Action IGNORE -FQDN ‘EQ,*.baddomain.com’

Creating DNS Policies in Windows Server 2016 (Image Credit: Russell Smith)

Creating DNS Policies in Windows Server 2016 (Image Credit: Russell Smith)

On the flip side, the policy below blocks a subnet, preventing it from using the server for DNS resolution, which might be useful in cases where a subnet is identified as being infected with malware:

PowerShell

1 Add-DnsServerQueryResolutionPolicy -Name BlackholePolicyLondon -Action IGNORE -ClientSubnet ‘EQ,LondonSubnet’

Time-based policies allow servers to respond differently at times where specific load conditions need to be addressed. The policy below is effective between 18:00 and 21:00, according to the local time of the server, and directs 80 percent of requests to London, and 20 percent to Paris.

PowerShell

1 Add-DnsServerQueryResolutionPolicy -Name ContosoPeakPolicy -Action ALLOW -ZoneScope ‘LondonZoneScope,8;ParisZoneScope,2’ –TimeOfDay ‘EQ,18:00-21:00’ -ZoneName contoso.com

To see all available parameters of the Add-DnsServerQueryResolutionPolicy cmdlet, type:

PowerShell

1 Get-Help Add-DnsServerQueryResolutionPolicy -Parameter *

13.Configure DNS Round Robin #

Configure DNS round robin

You can use DNS round robin to help to distribute load across servers providing the same service. For example, if you had three web servers in your network and you wanted to distribute the client load across all three equally, one solution is to configure the same host resource record (www.hottfixes.com) and point it to three different IP addresses. For example:

Round robin works by responding to each client request for the resolution of www.hottfixes.com with a differently ordered list of IP addresses. On the first request, the server with the IPv4 address of 172.16.0.10 is returned at the top of the list. Next, 172.16.0.12 is returned first on the list, and so on.

You configure round robin on DNS server on the Advanced server settings dialog box. It is enabled by default. You can also use the Set-DnsServer Windows PowerShell cmdlet.

You can also use netmask ordering to achieve a similar result, but in this case, a client receives the result that is most relevant to their location, based on their subnet.

14.Setup DNS zone scavenging #

Configure zone scavenging

Resource records often remain in a DNS zone even though the host that registered the record is no longer active. This is known as a stale record. You can use aging settings to determine when the DNS role can remove a stale record. This removal is known as scavenging.

Two parameters determine scavenging behavior:

  • No-refresh Interval The no-refresh interval is the period of time that the record is not eligible to be refreshed. By default, this is also seven days.
  • Refresh Interval The refresh interval is the time that the record is eligible to be refreshed by the client. The default is seven days.

Usually, a client host record cannot be refreshed for seven days after it is first registered (or refreshed). But then it must be refreshed within the following seven days. If it is not, the record becomes eligible to be scavenged.

By default, aging and scavenging of resource records is disabled.

To enable scavenging, you must enable it on both the DNS zone(s) and on the server(s) that host those zones.

To configure aging and scavenging on a DNS zone:

  1. In DNS Manager, right-click the appropriate zone, and then click Properties.
  2. On the General tab, click Aging.
  3. In the Zone Aging/Scavenging Properties dialog box, select the Scavenge Stale Resource Records check box, and then configure your preferred No-Refresh Interval and Refresh Interval values.

FIGURE 1-31

Enabling and configuring zone aging and scavenging

  1. Click OK twice.

You can also enable zone aging/scavenging with the Set-DnsServerZoneAging Windows PowerShell cmdlet. For example:

Set-DnsServerZoneAging hottfixes.com -Aging $True -ScavengeServers 172.16.0.10

You can configure aging/scavenging for all zones by right-clicking a server in the DNS Manager console and then clicking Set Aging/Scavenging for All Zones.

To configure scavenging on a DNS server, in the DNS Manager console:

  1. Right-click the appropriate DNS server and then click Properties.
  2. In the Server Properties dialog box, click the Advanced tab.
  3. Select the Enable Automatic Scavenging Of Stale Records check box, and then in the Scavenging period box, specify the number of days, and then click OK.

You can enable DNS server aging/scavenging with the Set-DnsServerScavenging Windows PowerShell cmdlet. For example:

Set-DnsServerScavenging -RefreshInterval 7.00:00:00

15.Analyze zone level statistics #

Analyze zone level statistics

Introduced in Windows Server 2012 R2, and improved in Windows Server 2016, DNS zone level statistics enable you to understand how a DNS server is being used for each authoritative zone on that server.

You can gather and view the following zone level statistics:

  • Zone queries Provides the number of:
    • Queries received
    • Successful responses
    • Failed query responses
    • Name error responses
  • Zone transfers Provides the number of zone transfer:
    • Requests received when operating as a primary server for a specific zone
    • Requests sent when operating as a secondary server for a specific zone
    • Requests received when operating as a secondary server for a specific zone
  • Zone transfers statistics also provide the number of zone transfers
    • Received by the DNS Server service when operating as a secondary server for a specific zone
    • Sent by the DNS Server service when operating as a master server for a specific zone
  • Zone updates Provides the total number of
    • Dynamic update requests received
    • Dynamic updates rejected

To access these statistics, use the Windows PowerShell Get-DnsServerStatistics cmdlet. For example:

Get-DnsServerStatistics -ZoneName “hottfixes.com”

16.DNS 127.0.0.1 BPA #

DNS local loopback 127.0.0.1 Active Directory servers Setup.

Best practice.

Using the loopback address on domain controllers running Windows Server 2012 and Windows Server 2012 R2

The answer for this can basically be inferred from two TechNet articles describing the Best Practices Analyzer for Domain Name System. The first article is called DNS: DNS servers on <adapter name> should include their own IP addresses on their interface lists of DNS servers, and the relevant statements on this page are these:

“The inclusion of its own IP address in the list of DNS servers improves performance and increases availability of DNS servers.”

The second article is called DNS servers on <adapter name> should include the loopback address, but not as the first entry, and the relevant information here is:

“The loopback address should be configured only as a secondary or tertiary DNS server on a domain controller. If the loopback IP address is the first entry in the list of DNS servers, Active Directory might be unable to find its replication partners.”

Error when running the dcdiag /test:dns command

From the above TechNet articles, it sounds as if it’s quite OK to use the loopback address instead of the domain controller’s actual IP address in the DNS Client configuration of the domain controller–as long as you don’t use the loopback address (or the actual IP address!) as the preferred (primary) DNS Server for the domain controller. Unless of course you only have one domain controller in your environment, which is not a good idea of course because it leaves you with a single point of failure for identity and access to your network.

However, I have heard a few reports from the IT community that have left me feeling a bit concerned about using the loopback address in the DNS Client configuration of a domain controller. For example, I’ve heard a few reports that use of the loopback address as a secondary or tertiary DNS Server address has sometimes resulted in failures when running the dcdiag /test:dns command (see “DNS Test Syntax” on for details of this command). Specifically, one colleague reported the following error in this scenario:

Error details: 10054 (Type: Win32 – Description: An existing connection was forcibly closed by the remote host.)

The colleague reported that when the loopback address was replaced with the actual IP address for the domain controller, the dcdiag /test:dns command completed successfully without errors. However, when I asked some experts at Microsoft concerning this, one of them said that the problem was actually with the dcdiag command and not with the DNS configuration on the domain controller. Specifically, this error may happen when you run dcdiag remotely but it doesn’t occur when you run the command locally on the domain controller that hosts the DNS zone. So the error seems to be with the troubleshooting tool (dcdiag) and not with the DNS configuration of the domain controller that you’re trying to troubleshoot.

DNS configuration for domain controllers in central site vs branch sites

An interesting question arises however with configuring the DNS settings on domain controllers in large “hub and spoke” Active Directory environments where you have a large central site and a number of smaller branch office sites. I’ve been advised by one colleague who is very experienced with large AD environments that the proper way of doing this is as follows:

Central (hub) site:

  • Primary DNS – another DNS server in the central (hub) site
  • Secondary DNS – another DNS server (a different one than above) in the central (hub) site
  • Tertiary DNS – the local server (using either loopback or actual address)

Branch sites:

  • Primary DNS – a DNS server in the central (hub) site
  • Secondary DNS – another DNS server in the same branch site (or a DNS server in a different branch site)
  • Tertiary DNS – the local server (using either loopback or actual address)

On the other hand, another colleague who also has similar long-time experience with large AD deployments tells me that the correct way of doing it is to configure the DNS on ALL of the domain controllers (i.e. in both the central site and the branch offices) like this:

  • Primary DNS – a DNS server in the central (hub) site (but not the local DNS server)
  • Secondary DNS – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Tertiary DNS – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Quaternary DNS for local server in central (hub) site – a different DNS server in the central (hub) site (but again not the local DNS server)
  • Quaternary DNS for local server in branch site – a different DNS server in the same branch site
  • Quinary DNS – the local server (using either loopback or actual address)

Regardless of which of these schemes you decide to follow, you might have to vary them depending upon the connectivity, bandwidth and latency between the different sites involved. Remember also that you may be able to mitigate latency issues that can affect DNS resolution by deploying caching-only name servers and utilizing conditional forwarding.

Testing possible failure scenarios

Finally, whichever scheme you use for configuring DNS Server settings on domain controllers in your Active Directory environment, you may want to also conduct a test to see what happens if all of the domain controllers in a site are suddenly shut down, either gracefully or by an abrupt power failure. I’ve actually heard a report of an organization that had two domain controllers in their central site where each domain controller pointed to the other as its preferred DNS server and to itself as its alternate DNS server, and when both domain controllers were restarted at the same time after having patches applied, the Active Directory services of neither of them were able to restart afterwards. I’m not sure why this would happen, but I’m told it did. So the moral of the story is, however you configure the DNS Client on your domain controllers, be sure to test your setup thoroughly!

17.Monitor DNS #

Monitor DNS

Since DNS is such a critical service, providing name resolution and service location for configured clients, it is important that you ensure that DNS is running reliably and is optimized. To help you achieve this, you can use a number of monitoring and auditing tools in Windows Server.

Use DNS audit events and analytical events

Windows Server 2016 can collect a vast amount of logging data. Much of this logging is enabled by default, but features such as Debug logging  must first be enabled before you can use them.

You can also use DNS Audit events and DNS Analytic events.

  • DNS Audit Events These are enabled by default. Use to enable change tracking on your DNS servers. Every time a server, zone, or resource record is edited, an audit event is logged. Event IDs numbered 513 through 582 are logged in this regard, and are explained on the following website.

Need More Review? Audit Events

For more information about audit events in Microsoft DNS, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/dn800669(v=ws.11).aspx#audit.

  • DNS Analytic Events These are disabled by default. Windows logs an analytic event every time the DNS server sends or receives DNS information. Event IDs numbered 257 through 280 are logged in this regard, and are explained on the website listed below.

Need More Review? Analytic Events

For more information about analytic events in Microsoft DNS, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/dn800669(v=ws.11).aspx#analytic.

Viewing Audit and Analytical Events

To view audit events, use the following procedure:

  1. Open Event Viewer.
  2. Expand Application And Services Logs, expand Microsoft, expand Windows, and then click DNS-Server.
  3. Click the Audit folder, as shown in Figure 1-33. You can review events from here.

FIGURE 1-33

Viewing Audit events for a DNS server

To view analytic events, use the following procedure:

  1. Open Event Viewer.
  2. Expand Application And Services Logs, expand Microsoft, expand Windows, and then click DNS-Server.
  3. Right-click DNS-Server, click View, and then click Show Analytic And Debug Logs. The Analytical and Audit log folders display, as shown in Figure 1-33.
  4. Right-click Analytical and then click Enable Log.
  5. In the Event Viewer pop-up dialog box, click OK.

Need More Review? DNS Logging and Diagnostics

For more information about logging and diagnostics in Microsoft DNS, refer to the Microsoft TechNet website at https://technet.microsoft.com/library/dn800669(v=ws.11).aspx.

18.DNS Summary #

DNS summary

  • You can install the DNS server role on Windows Server 2016 and Nano Server.
  • DNS forwarders, recursion, and root hints enable you to control the flow of DNS query traffic throughout your organization’s network.
  • You can implement DNSSEC, DNS socket pool, cache locking, DANE, and response rate limiting to help to secure your DNS infrastructure from malicious attacks.
  • DNS policies in Windows Server 2016 help you configure DNS behavior throughout your organization without needing to manually configure each DNS server.
  • DNS logging can help you to pinpoint problems with the DNS servers in your organization before they can affect your users.
  • The DNS server role is affected by CPU and memory resources, and proactive monitoring of these resources can be beneficial.
  • Although the DNS namespace is based on domains and subdomains, the data that maintains this namespace is stored in DNS zones.
  • Secondary zones receive updates via their configured master server.
  • DNS delegation enables a part of your DNS namespace, such as a child domain, to be authoritatively maintained in a separate zone.
  • AD DS-integrated zones provide for multimaster updates, secure replication, and secure dynamic updates.
  • Conditional forwarding provides similar function to stub zones.
  • DNS scopes are based on DNS policies.
Help Guide Powered by Documentor
Suggest Edit