This is a guide on DNS with Active Directory.

This is a guide on DNS with Active Directory.

 

 

 

 

DNS and active directory work together. Active Directory uses DNS for a number

of services. When a machine starts on the network, it queries DNS to discover

the nearest domain controller. Without this information, your machine will not

be able to connect to the domain and will not be able to log on. 

 

Most organizations use Microsoft DNS because it integrates with Active

Directory. The benefits are:

 

1. single replication topology - AD replication controls DNS replication,

instead of requiring the configuration of a separate topology.

2. Multimaster DNS Servers - Records can be written to any DNS server, instead

of just the primary DNS server.

3. Dynamic updates - The client machines can update their own records.

4. Secure updates - Enables controlling which users and computers can update DNS

records.

 

It is possible to use a non-Microsoft DNS, but this requires more work on your

part.

 

Microsoft DNS has the advantage that it is designed to integrate with Active

Directory and it comes in the box. It also uses GUI tools that follow the

pattern you are used to and can be administered using PowerShell. 

 

When installing Active Directory, one of the options is to install DNS at the

same time. If you are using Microsoft DNS, this is the recommended approach.

Once DNS is installed on your domain controller, the standard AD replication

process will copy the data onto the new DNS server. 

 

You have a number of options for managing DNS. You can manage Windows DNS using

the DNS GUI console or you can use PowerShell. The DNS GUI is relatively

unchanged across the current version of Windows server. 

 

You do not have to use Microsoft DNS with your Active Directory. You can use

something like BIND or Cisco Registrar. A non-Microsoft implementation of DNS

has to meet the following requirements:

 

1. Must support SRV records.

2. Should support dynamic updates.

3. Should ideally support incremental zone transfers.

 

The latest versions of BIND support all of these. You must check compliance  on

any other DNS server in use in your organization.

 

If you use a non-Microsoft DNS, you will need to utilize the management tools

that are applicable to your DNS implementation.

 

DNS is a system that tends to look after itself. If you have implemented dynamic

DNS, your systems will register themselves in DNS when they start. This saves

you a lot of work. There are still a number of tasks you need to perform,

including viewing and changing the server level settings, managing DNS zones,

and managing forwarders.

 

Once the DNS server is installed, you probably will not need to do much to it in

the way of administration. Your time will be spent working with the zones and

records. You may need to check DNS server settings. You can view the settings as

follows:

 

1. Open the DNS Manager console

2. Right click the DNS server

3. Choose Properties

 

You can control:

 

1. The IP address on which DNS listens for requests.

2. Servers to which your DNS server will forward requests if they cannot

resolve.

3. Root hints - the top-level DNS servers on the internet

4. Logging and monitoring

5. Security

6. Record scavenging

 

A full listing of the DNS server settings, including the zones on the server,

can be obtained using the Windows Server 2012 PowerShell cmdlet.

 

A DNS zone is a partition in the DNS namespace. One DNNS zone will match the

name of your AD domain. This is the forward lookup zone used to discover IP

addresses from machine names. A reverse lookup zone is used to supply a machine

name when an IP address is given. You can think of DNS zones as analogous to

OU's in AD, they are containers for DNS records.

 

If you install DNS as part of your initial AD installation, you will find two

zones are created:

1. A forward lookup zone that matches the AD domain

2. A forward lookup zone whose name starts with _msdcs. This is used by AD

to store the SRV DNS records that are used to advertise AD services through

DNS.

 

You may need to create additional zones because:

1. You introduce additional domains into your environment.

2. You need to create a reverse lookup zone

3. You segregate part of your environment.

 

You can create a zone using the DNS GUI tool or PowerShell.

 

Creating a Reverse Lookup Zone with the GUI

Creating a reverse lookup zone is very similar. Supply a network and the reverse

lookup zone name will be populated for you. Complete the wizard. You can also

create these with PowerShell.

 

Conditional forwarders are created to enable your DNS servers to forward

requests to a specific domain. A normal forwarder will forward requests to one

or more DNS servers. A conditional forwarder will only forward requests  for the

one domain.

 

Imagine that you have created a conditional forwarder to a certain website. If a

request to resolve it is received by your internal DNS server, it will forward

it to the DNS server indicated by the conditional forwarder. Any other request

will be forwarder through your general forwarder for resolution by the internet

DNS servers.

 

General forwarders are normally created in your perimeter network, also known as

a DMZ, and usually remain unchanging. You can also create forwarders on your

internal DNS server. 

 

DNS zones contains records for individual machines in your environment. The

minimum is a record in the forward lookup zone known as an 'A record'. These are

for IPv4 addresses. If you are actively using IPv6 addresses, you will need to

create 'AAAA records'. Both types of records are used to supply an IP

address when you submit the machine name to the DNS.

 

There are occasions when you know the IP address but need the machine name. This

involves using using a pointer record in a reverse lookup zone. The abbreviation

PTR is always used when discussing reverse lookup records. The lifecycle of a

DNS record is very simple, because it is created and eventually destroyed when

the machine to which it refers is no longer required. The other important action

you need to perform is viewing the DNS records.

 

A useful troubleshooting technique, in the case of machine connectivity

problems, is to check if a system is correctly registered with DNS. You can use

the DNS console or checking using PowerShell. You will learn how to test if a

system can find the DNS server and resolve a machine name.

 

If you are using an AD-integrated DNS, the records in your forward lookup zones

will be maintained automatically. Servers will refresh their records when they

restart and workstations will have their records refreshed by DHCP.

 

Occasionally you may need to create records if you have assigned another IP

address to a machine or you need to create an entry for a website. The DNS GUI

tool is one way to create records.

 

Deleting DNS records is a relatively infrequent operation, usually only

performed when a resource such as a server or web site is decommissioned. In the

GUI tool, navigate to the record you wish to delete, right click it, and choose

delete.

 

You know that computers in a Windows environment use DNS to discover IP address

information when they need to communicate with other systems. Usually everything

works, but sometimes problems arise and you are in the hot seat trying to

discover why something is not working. Testing a DNS is a common troubleshooting

step in these cases. You need to test that your system can find a DNS server and

that the DNS server is responding to your system. In the case of AD-related

problems, you also need to test that the SRV records can be found.

 

If your machines cannot find a DNS server, they will not be able to communicate

with AD and your users will not be able to logon and work. The first step is to

ensure that the machine is configured with the address of one or more DNS

servers:

 

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPenabled=$True"

| select DNSDomain, DNSHostname, DNSServerSearchOrder

 

The next step is to determine if your system can contact the DNS server:

 

Test-Connection -ComputerName 10.10.10.10 -Quiet

 

If a connection is made, you will see a reply of True. A reply of False

indicates that the test failed and the machine could not be contacted.

 

The last test is to ensure that the machine you are contacting really is a DNS

server:

 

Resolve-DNSName -Name $env:Computername -Server 10.10.10.10

 

The -Name is the name of the local machine and the -Server is the DNS server.

$enc:ComputerName is the environmental variable holding the computer name. 

 

You can also test the DNS server itself:

 

Resolve-DNSName -Name 10.10.20.20 -Server 10.10.10.10

 

This uses the reverse lookup zone to resolve the name of the DNS server. Now

that you know the DNS server, you need tot est whether it has the records for

DNS to function correctly with your Active Directory.

 

The SRV records stored in a DNS are used to advertise specific services used in

Active Directory. The SRV records are stored in the _msdcs forward lookup zone. 

 

The _msdcs zone contains the following subzones:

1. dc provides SRV records for the domain controllers in the domain. There

is a folder called Sites that has the subfolder per site in your AD.

2. domains shows the different domains in your forest, in this case there is

only one.

gc has records for the global catalog

pdc stores the records for the global catalogs in your forest

 

The OwnerName property indicates where the record sits in the _msdcs zone and

the RecordData indicates the domain controller that offers those services. The

numbers under the RecordData property indicate priority, weight, and port.

 

If you know the AD site your machine sits in, you can discover whether AD

services are available to it through the SRV records.<F8><F9>