This is a guide on DNS with Active Directory.

This is a guide on DNS with Active Directory.
 

This is the Ankr Power Bank I have. It has been great and reliable when I go on trips or when I get on laptop to write somewhere away from home.

 
 
 
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
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 Administration
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.
 
Creating Zones
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.
 
Creating Forwarders
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 Records
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.
 
Viewing 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.
 
Adding Records
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 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.
 
Testing DNS Servers
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.
 
Testing Systems can find a DNS Server
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.
 
Testing SRV Records
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>