INFORMATION SHEET 3.2.

Respond to unplanned events or conditions

LEARNING OBJECTIVE/S:

After reading this information sheet, you must be able to:

1. Identify what are unplanned events or conditions.

2. Identify how to respond to unplanned events or conditions.
3. Identify what are Active Directory Domain Controller, Dynamic Host
Configuration Protocol and Domain Name Servers.

WHAT IS A DOMAIN NAME SERVER (DNS) AND HOW DOES IT WORK

 Domain Name Servers (DNS) are the Internet's equivalent of a phone book.
They maintain a directory of domain names and translate them to Internet
Protocol (IP) addresses. This is necessary because, although domain names
are easy for people to remember, computers or machines, access websites
based on IP addresses.

 Information from all the domain name servers across the Internet are
gathered together and housed at the Central Registry. Host companies and
Internet Service Providers interact with the Central Registry on a regular
schedule to get updated DNS information.

 When you type in a web address, e.g., www.jimsbikes.com, your Internet

Service Provider views the DNS associated with the domain name,
translates it into a machine friendly IP address (for example
216.168.224.70 is the IP for jimsbikes.com) and directs your Internet
connection to the correct website.
  After you register a new domain name or when you update the DNS servers
on your domain name, it usually takes about 12-36 hours for the domain
name servers world-wide to be updated and able to access the information.
This 36-hour period is referred to as propagation.

Understanding the DNS Process

Do you ask yourself, “What is DNS?” “Do I need to use DNS?”  Do you feel
confused? In some cases, DNS can be convoluted and complicated.  Let’s talk
about Domain Name System (DNS) services.

When you need to access a website, you type the domain name, such as
www.google.com, into the web browser instead of typing an IP address. A
conversion happens between www.google.com to 172.217.12.46, an IP, which
designated to a device on the Internet.

This conversion is a DNS query, an integral part of devices connecting with

each other to communicate over the internet. To understand the DNS query
process, let’s talk about how a DNS query routes through different components.

DNS Lookup Process

Step 1: Requesting Website Information

First, you visit a website by typing a domain name into a web browser.
Your computer will start resolving the hostname, such as www.liquidweb.com.
Your computer will look for the IP address associated with the domain name in its
local DNS cache, which stores DNS information that your computer has recently
saved.  If it is present locally, then the website will be displayed. If your computer
does not have the data stored, then it will perform a DNS query to retrieve the
correct information.
Step 2: Contact the Recursive DNS Servers

If the information is not in your computer’s local DNS cache, then it will
query the recursive DNS servers from your (ISP) Internet service provider.
Recursive DNS servers have their local DNS cache, much like your computer.

Given that many of the ISP’s customers are using the same recursive DNS
servers, there is a chance that common domain names already in its cache. If the
domain is cached, the DNS query will end here and the website displayed to the
user.

Step 3: Query the Authoritative DNS Servers

If a recursive DNS server or servers do not have the information stored in

its cache memory, the DNS query continues to the authoritative DNS server that
has the data for a specific domain. These authoritative name servers are
responsible for storing DNS records for their respective domain names.

Step 4: Access the DNS Record

For our example, to find out the IP address for www.liquidweb.com, we will
query the authoritative name server for the address record (A record). The
Recursive DNS server accesses the A record for www.liquidweb.com from the
authoritative name servers and stores the record in its local DNS cache.

If other DNS queries request the A record for www.liquidweb.com, the

recursive server will have the answer and will not have to repeat the DNS lookup
process. All DNS records have a time-to-live value, which shows when a DNS
record will expire. After some time has passed, the recursive DNS server will ask
for an updated copy of the DNS record.

Step 5: Final DNS Step

The Recursive DNS server has the information and returns the A record to
your computer. Your computer will store the DNS record in its local DNS cache,
will read the IP address from the DNS record, and pass this information to your
browser. The web browser will connect to the web server associated with the A
records IP and display the website.

The entire DNS lookup process, from start to finish, takes only milliseconds
to complete. For a more profound understanding let’s break down the previously
mentioned DNS components that are relevant to the DNS lookup process.

Identify and Troubleshoot DNS Problems

When DNS name resolution stops working, your Microsoft Active Directory
(AD) environment has problems. DNS is the bedrock of your environment, and
without name resolution, operations may be interrupted or grind to a halt.
Possibly a name resolution issue has built up over time due to a slow migration
away from a sound DNS tree hierarchy design.

This could have happened as a result of decisions made by segmented

groups where an immediate functional need was required but enterprise DNS
design consideration fell to the wayside. Here are some key tips and
troubleshooting tools to help you avoid or resolve DNS problems.

Tip 1: The DNS namespace should reflect a contiguous tree hierarchy

The Internet DNS namespace has a tree hierarchy (by design), and
administration of this is delegated to DNS administrators responsible for various
branches of the DNS namespace (IETF RFC 1034, RFC 1032). Like their Internet
counterparts, intranet DNS admins should follow hierarchical tree design.
Whenever a non-contiguous or disjoint namespace is encountered in an intranet
environment, complexity will ensue in the form of the addition of conditional
forwarders, stub zones, and/or secondary zones.
 Take the scenario of a company acquisition, where each company has two
separate, independent namespaces that must be consolidated in functionality
using Windows Server trusts. A suggested approach is to create a secure VPN
between both company environments at the root of each separate, continuous
namespace. Use conditional forwarders to direct name queries across the VPN to
the namespace on the opposite side of the VPN tunnel, as Figure 1 shows.

Tip 2: Understand where DNS information is stored

DNS zone data can be stored in the AD information tree or in the file
system in c:\%systemroot%\system32\dns. I strongly recommend that you store
zone information in AD, then replicate this zone information either to every DNS
server in the domain (DomainDNSZones) or possibly in the forest
(ForestDNSZones). Storing DNS information on every DNS server in the domain,
then forwarding upstream to the parent zone is an optimal choice. DNS
forwarding would be set up so that DNS servers in child1.domain1.local and
child2.domain1.local forward to DNS servers in parent domain1.local. In the
parent domain, there would be delegation to each child domain. (For additional
information about DNS zone location, see my article "Chasing the DNS Zone
Location Problem".)

Tip 3: Identify whether the DNS problem is a name-registration or name-

resolution problem

To resolve a name, the name must be registered in a zone on a DNS server.

In a Windows environment, different services register different records. In
Windows 7, Windows Vista, Windows Server 2008 R2, and Server 2008, the DNS
client service registers A and PTR records. In Windows XP and Windows Server
2003, the DHCP client service registers A and PTR records. The registration
interval is 24 hours, except for when the DHCP server is doing the registering; in
this case, the registration should take place when the DHCP client's lease is
renewed.

In Server 2008 R2, Server 2008, and Windows 2003, the Netlogon service is
responsible for the registration of some additional records. A log of the records
registered by the Netlogon service is located at %SystemRoot%\System32\
Config\Netlogon.dns. Domain controllers (DCs) dynamically register 15 to 30 SRV
records every hour in Server 2008, whereas in Windows 2003 the registration by
Netlogon is every 24 hours.

In Server 2008, the Cluster service registers the cluster network name
resource when the resource comes online. The record is updated at least once
every 24 hours. The setting RegisterAllProvidersIP can be used to determine
whether all IP addresses for the network name resource are registered in DNS.
(For more information, see the Microsoft article "Description of what to consider
when you deploy Windows Server 2008 failover cluster nodes on different, routed
subnets".)

The problem is a DNS registration issue. If DNS records are not present in the
DNS console, use ADSI Edit to verify that the records are not simply being
displayed in the DNS console GUI or in AD. Verify record existence in AD by
following the steps in the article "Event ID 4515 is logged in the DNS Server log in
Windows Server 2003". If the records are not present, install Microsoft's Network
Monitor on the machine performing the DNS registration and take a network
trace while attempting to register the A, PTR, or SRV records. To initiate A and
PTR record registration, issue this command:

ipconfig /registerdns

For SRV record registration, issue this command:

c:\net stop netlogon && net start netlogon
 Stop the network trace and filter on DNS traffic. If no registration traffic is
present in the network trace, focus on whether the service responsible for the
registration (DHCP client, DNS client, Netlogon, Cluster) is running, and check
the event logs. (If you're still stuck at this point, it may be time to call Microsoft
Support.)

The problem is a DNS resolution issue. If the technical issue is not related to
DNS record registration, change the troubleshooting approach and investigate
DNS name resolution. First, ping the Fully Qualified Domain Name (FQDN) of the
target and determine success or failure. If the failure is by name and not by IP
address, verify that the DNS server settings are properly configured in the TCP/IP
properties of the machine initiating the query. Next, start a network trace and
clear the resolver cache by issuing this command:

c:\ipconfig /flushdns

Now ping the target by FQDN (e.g., ping server.domain1.local). Stop the
network trace and determine whether there is an outbound DNS query and/or an
inbound DNS response. The goal here is to determine whether the issue is with
getting a query to the DNS server or if the DNS server gets the query and either
doesn't respond or the response fails to reach the DNS query initiator.

Tip 4: Use DNS diagnostic tools

To assist you in troubleshooting DNS issues, make sure you have these tools in
your DNS toolkit: DNSLint, DCDiag, and NSlookup.

DNSLint. The DNSLint utility has three functional tests, all of which output
results to an HTML report. The test are for "lame delegation", the DNS records
required for AD replication to succeed, and verifying a user-defined set of DNS
records on multiple DNS servers. Specify /d on the dnslint command to perform
the domain name test and provide results that can help in diagnosing lame
delegation. Specify /s to indicate the IP address of the DNS server for the DNS
server authoritative for the domain. Specify /ad to determine whether the DNS
record needing AD forest replication is resolvable. (For more information,
see "Description of the DNSLint utility".)

DCDiag. You can run the dcdiag command using the option /test:DNS. Test
options include a DNS basic test and tests for forwarders and root hints,
delegation, DNS dynamic updates, DNS record registration, and Internet name
testing.

Test the health of a DC:

DCDIAG /TEST:DNS /v /s: /f:

Test the health of all forest DCs:

DCDIAG /TEST:DNS /f /e /f:

Test the DC's ability to register the DC Locator DNS records:

DCDIAG /TEST:RegisterInDNS /DnsDomain: /v /f:

(In the previous commands, /v specifies verbose output, /s means run

local, /f means direct output to file, and /e means test all servers.)

In Windows 2003 SP2, use the DCDiag utility included with SP2, as
described in support.microsoft.com/kb/926027. In Server 2008 and Server 2008
R2, install DCDiag by navigating to Server Manager, Features, Add Features,
Remote Server Administration Tools, Role Administration Tools, Select DNS
Server Tools, Next, Install.

NSlookup. This is a well-known command for DNS troubleshooting. View

NSlookup syntax variations by running NSlookup from a command prompt, then
issuing the command help. Keep in mind that NSlookup has its own built-in stub
resolver in the executable and does not use the OS's resolver.

Tip 5: Microsoft DNS best practices

Check your Server 2008 R2 DNS environment's heath by using the Microsoft Best
Practices Analyzer (BPA) included in Server 2008 R2. Two variations of the tool
exist: one for best practices for DNS configuration, and the second for best
practices for DNS operation. BPA is helpful tool for scanning your Server 2008 R2
DNS environment and investigating potential DNS configuration issues.

To open BPA, follow these steps:

1. Go to Start, Administrative Tools, and click Server Manager.

2. In the tree pane, open Roles, then select the role for which you want to open
BPA.
3. In the details pane, open the Summary section, then open the Best Practices
Analyzer area.

REFERENCES

 https://www.networksolutions.com/support/what-is-a-domain-name-
server-dns-and-how-does-it-work/
 https://www.liquidweb.com/kb/understanding-the-dns-process/
 https://www.itprotoday.com/compute-engines/identify-and-troubleshoot-
dns-problems