System Administration

and Maintenance
 Module 7
Domain Name System
• To understand the DNS server role in Windows Server
• To know the new DNS features and functionality in Windows Server
• To know more about DNS Security Extensions support in Windows
Server 2012 and Windows Server 2012 R2, including concepts and
detailed deployment procedures
 DNS Part 1

7.1

System Administration and Maintenance

• DNS is a system that is used in TCP/IP networks for
naming computers and services through user-friendly
names.
• DNS in Windows Server 2012 R2 and Windows Server
2012 provides the following:

• DNS Security Extensions (DNSSEC)

• a suite of extensions that adds security to the DNS protocol
• DNS integration with Active Directory is the same in Windows
Server 2012 R2 and Windows Server 2012 as in previous operating
systems
• DNS and DHCP integration is the same in Windows Server 2012 R2
and Windows Server 2012 as in previous operating systems
• Installation of the DNS Server role can be performed using
Server Manager. The following features and tools are
installed automatically when you install DNS Server:
Feature or Tool Description
Remote Server DNS Server Tools are required to manage the DNS Server role, but do not have to be
Administration Tools installed on the same server. The DNS Manager console is installed automatically when
you install DNS Server unless you choose to cancel installation of Remote Server
Administration Tools.
Functionality New or Description
improved
DNS query adaptive New This feature enables the timeout for DNS queries to adapt
timeout based on the time required for previous queries, reducing the
timeout for most queries. Timeouts can also be increased for
high-latency links, such as satellite links. Configuration of DNS
timeouts is enabled on a per network interface basis, and can
be optimized by Windows Store apps.
Instead of waiting for 1000ms before timing out a DNS query,
the first timeout is adjusted to be between 25ms and 1000ms,
based on past performance of the network.
Functionality New or Description
improved
DNS server non-responsive New Nonresponsive DNS servers are cached and periodically
cache retried. This enables the DNS client to use the best available
server consistently, and to spend less time waiting for
unresponsive DNS servers.
DNS cache improvements New The DNS cache is improved to consolidate cache entries,
enable more cache entries, and to permit caching of additional
records.

DNS query coalescing New Multiple DNS queries for the same name are combined,
resulting in only one DNS query. This optimizes client,
network, and server resources.

DNS SQM New Improvements are made to Software Quality Metrics (SQM)
reporting for the DNS client. This information can be used to
improve performance and reliability.

Events for name resolution New Event tracing for Windows (ETW) events are added to DNS
logging. This feature will assist with troubleshooting DNS
issues.
Functionality New or Description
improved
Parallelize A and AAAA New A and AAAA DNS queries are issued in parallel, saving time for
queries interfaces that have both IPv6 and IPv4 addresses.

Per interface Winsock New This feature enables the GetAddrInfoEx() application
name resolution programming interface (API) to issue a name query on a
specific network interface.

Asynchronous Winsock New This feature enables the GetAddrInfoEx() API to issue
name resolution asynchronous name resolution queries.

Persistent cache New The DNS cache is now persistent across changes that occur on
the same network, including address change notifications and
sleep-resume-standby state transitions.
Functionality New or Description
improved
Link-local multicast name Improved Outbound LLMNR queries are not sent to mobile broadband
resolution (LLMNR) and VPN interfaces.

Network basic Improved Outbound NETBIOS queries are not sent to mobile broadband
input/output system interfaces.
(NETBIOS)
LLMNR timeout Improved The LLMNR query timeout has been increased to 410 msec for
the 1st retry and 410 msec for the 2nd retry. The total timeout
value is now 820 msec instead of 300 msec. This change is to
solve a problem with computers in power saving mode.
LLMNR and NETBIOS queries are also issued in parallel,
improving response times for all queries.
Functionality New or Description
improved
Parallel queries Improved LLMNR and NETBIOS are issued in parallel and optimized for
IPv4 and IPv6 queries.

Binding order optimization Improved Interfaces are divided into networks to send parallel DNS
queries and prefer binding order responses.

Protocol reordering Improved If a specific interface is hijacking DNS names, then for flat
names on those networks LLMNR and NETBIOS queries are
sent in parallel with DNS queries and the LLMNR or NETBIOS
response is preferred.
Asynchronous DNS cache Improved All the queries in DNS cache service are asynchronous and
response timing is optimized.
Functionality New or Description
improved
DNS Logging and New Enhanced DNS logging and diagnostics in Windows Server
Diagnostics 2012 R2 and later includes DNS Audit events and DNS Analytic
events. Enhanced logging enables monitoring of all DNS query,
response, and operational transactions.
Zone-level statistics Improved Zone level statistics are available for different resource record
types, zone transfers, and dynamic updates.

DNSSEC support Improved DNSSSEC key management and support for signed file-backed
zones is improved.

Windows PowerShell Improved New Windows PowerShell parameters are available for DNS
support Server.

Dynamic DNS Forwarders New DNS now maintains a list of DNS Forwarders ordered by
response time, to ensure queries are sent to forwarders with
quicker response time.
• DNS server statistics available in Windows Server® 2012 using the Get-
DnsServerStatistics Windows PowerShell
• In Windows Server 2012 R2, the following additional statistics are
available:

ZoneQueryStatistics: Zone query statistics provide the information about:

• QueriesFailure: The number of queries that did not result in a successful response, for example
when the response is DNS SERVER FAILURE.
• QueriesNameError: The number of queries that resulted in an NXDOMAIN or EMPTY AUTH
response.
• QueriesReceived: The total number of queries received for the specified record type.
• QueriesResponded: The total number of queries that resulted in a valid DNS response.
•ZoneTransferStatistics: Zone transfer statistics provide the
information about AXFR and IXFR transations, including:
• RequestReceived: The total number of zone transfer requests received by the DNS
Serverservice when operating as a primary server for a specific zone.
• RequestSent: The total number of zone transfer requests sent by the DNS
Serverservice when operating as a secondary server for a specific zone.
• ResponseReceived: The total number of zone transfer requests received by the DNS
Serverservice when operating as a secondary server for a specific zone.
• SuccessReceived: The total number of zone transfers received by the DNS Server
servicewhen operating as a secondary server for a specific zone.
• SuccessSent: The total number of zone transfers successfully sent by the DNS
Serverservice when operating as a primary server for a specific zone.
•ZoneUpdateStatistics: Zone update statistics provide the
information about:
• DynamicUpdateReceived: The total number of dynamic update
requests received by theDNS server.
• DynamicUpdateRejected: The total number of dynamic updates
rejected by the DNSserver.
Enhanced support for DNSSEC includes changes to online
signing for file-backed zones, and enhanced signing key
management support:
• In Windows Server 2012 R2, the Key Master role is
introduced for file-backed multi-master zones.
• DNSSEC key separation is accomplished by enabling
generation and storage of keys on a cryptographic next-
generation (CNG) compliant offline storage module.
The following new Windows PowerShell cmdlets and
parameters are introduced in Windows Server 2012 R2:
• Step-DnsServerSigningKeyRollover: This cmdlet forces a
KSK rollover when waiting for a parent delegation signer
(DS) update
• Add-DnsServerTrustAnchor -Root: The Root parameter
set enables you to retrieve trust anchors from the URL
specified in RootTrustAnchorsURL property of the DNS
server. Alias: Retrieve-DnsServerRootTrustAnchor
• RootTrustAnchorsURL: The Get-DnsServerSetting and
Set-DnsServerSetting cmdlets are extended to add a new
output string of RootTrustAnchorURL
• When you add more than one forwarder in the settings for
a DNS Server in Windows Server 2012 R2, the DNS service
reorders the list of servers in the list of forwarders based
on response time of each server in the list.
• The reordering and response checking operations are
enabled by default in Windows Server 2012 R2. If you wish
to disable this feature, you need to change the following
registry DWORD value to 0:
HKLM\System\CurrentControlSet\Services\DNS\Parameters\En
ableForwarderReordering
In Windows Server 2012, DNS Server offers enhanced
support in the following areas:
•DNSSEC support
•Windows PowerShell support
In Windows Server 2012, DNS Security Extensions (DNSSEC) support is
extended to include online signing and automated key management. Other
enhancements to DNSSEC include:
•Support for Active Directory-integrated DNS scenarios including DNS
dynamic updates in DNSSEC signed zones.
•Support for updated DNSSEC standards, including NSEC3 and RSA/SHA-2.
•Automated trust anchor distribution through Active Directory.
•Automated trust anchor rollover support per RFC 5011.
•Updated user interface with deployment and management wizards.
•Validation of records signed with updated DNSSEC standards (NSEC3,
RSA/SHA-2).
•Easy extraction of the root trust anchor.
DNS configuration and management is greatly enhanced with Windows
PowerShell, including:
•Parity with the user interface and dnscmd.exe.
•DNS Server role installation/removal using Windows PowerShell.
•Windows PowerShell client query with DNSSEC validation results.
•Server configuration is enabled for computers running older operating
systems.
 DNS Part 2: DNS Logging and
Diagnostics

7.2

System Administration and Maintenance

Debug logging
• Prior to the introduction of DNS analytic logs, DNS debug logging was an available method to monitor DNS
transactions.
• The DNS debug log provides extremely detailed data about all DNS information that is sent and received by the
DNS server, similar to the data that can be gathered using packet capture tools such as network monitor.
• Debug logging can affect overall server performance and also consumes disk space, therefore it is recommended
to enable debug logging only temporarily when detailed DNS transaction information is needed.

Audit and analytic event logging

• Enhanced DNS logging and diagnostics in Windows Server 2012 R2 and later includes DNS Audit events and
DNS Analytic events.
• DNS audit logs are enabled by default, and do not significantly affect DNS server performance.
• DNS analytical logs are not enabled by default, and typically will only affect DNS server performance at very high
DNS query rates.
To install DNS diagnostic logging
1.If the DNS server is running Windows Server 2012 R2, download the hotfix
from https://support.microsoft.com/kb/2956577.

2.Double-click the self-extracting file, for example 475151_intl_x64_zip.exe.

3.In the Microsoft Self-Extractor dialog box, click Continue.

4.Type a location where you want to save the extracted files, for example C:\hotfix. If the directory does not yet exist,
you will be asked if you wish to create it. Click Yes and confirm that All files were successfully unzipped is
displayed, then click Ok.

5.In the location where files were unzipped, double-click the Windows Update file, for example Windows8.1-
KB2956577-v2-x64.msu.

6.The Windows Update Standalone Installer will verify that the computer meets requirements to install the update.
These requirements include some prerequisite updates. When verification is complete, click Yes when asked if you
wish to install the Hotfix for Windows (KB2956577).
7. If recently downloaded updates have not yet been installed, you might need to restart the computer before the
current hotfix can be installed. If this is required, you must restart the computer first and then run the Windows8.1-
KB2956577-v2-x64.msu a second time after the computer has completed installing necessary updates. The
Windows Update Standalone Installer will notify you that installation of the hotfix is not yet complete. If this
happens, and you are prompted to restart the computer, click Restart Now.

8. If the computer is ready to install the update when you run the hotfix, installation will complete and you must
restart the computer for the update to take effect. If Installation complete is displayed, click Restart Now for the
update to take effect.

You can confirm that the hotfix was successfully installed by viewing installed updates in the Programs and
Features control panel. If the update is successfully installed, Hotfix for Microsoft Windows (KB2956577) will be
displayed. You can also verify installation of the hotfix by typing wmic qfe | find "KB2956577" at an elevated
command prompt. The URL and date of installation for the hotfix will be displayed if it was successfully installed.
1.Type eventvwr.msc at an elevated command prompt and press ENTER to open Event Viewer.
2.In Event Viewer, navigate to Applications and Services Logs\Microsoft\Windows\DNS-Server.
3.Right-click DNS-Server, point to View, and then click Show Analytic and Debug Logs.
The Analytical log will be displayed.
4.Right-click Analytical and then click Properties.
5.Under When maximum event log size is reached, choose Do not overwrite events (Clear logs
manually), select the Enable logging checkbox, and click OK when you are asked if you want to
enable this log
6.Click OK again to enable the DNS Server Analytic event log.

By default, analytic logs are written to the file: %SystemRoot%\System32\Winevt\Logs\Microsoft-

Windows-DNSServer%4Analytical.etl.
See the following sections for details about events that are displayed in the DNS server audit and
analytic event logs.
DNS logs are compatible with Event Tracing for Windows (ETW) consumer applications such
as logman, tracelog, and message analyzer.

•Using ETW consumers

•Audit events
•Analytic events
You can use ETW (Event Tracing for Windows) consumers such as tracelog.exe with DNS server audit and analytic events by
specifying a GUID of {EB79061A-A566-4698-9119-3ED2807060E7}.

You can get tracelog.exe by downloading and installing the Windows Driver Kit (WDK). Tracelog.exe is included when you install the
WDK, Visual Studio, and the Windows SDK for desktop apps.

example, when you download and install Windows Driver Kit (WDK) 8 and accept the default installation path, tracelog.exe is
available at C:\Program Files (x86)\Windows Kits\8.0\Tools\x64\tracelog.exe.

The following examples demonstrate how to use tracelog.exe with DNS audit and analytic event logs:

The following command will enable both analytical and audit logging:
tracelog.exe -start Dns -guid #{EB79061A-A566-4698-9119-3ED2807060E7} -level 5 -matchanykw 0xFFFFFFFF -f C:\analytic_audit.etl

While the trace is active, all analytical and audit events will be recorded in the C:\analytic_audit.etl file that was specified on the
command line. You can stop tracing by issuing a stop command:

tracelog –stop Dns

After stopping the trace, you can view the .etl file in Event Viewer by clicking Action and then clicking Open Saved Log. See the
following example.
The following example enables just the analytical channel and matches only the keywords to
0x7FFFF:

tracelog.exe -start Dns -guid #{EB79061A-A566-4698-9119-3ED2807060E7} -level 5 -

matchanykw 0x7FFFF -f C:\analytic.etl
A logging level of 5 is used in the previous examples. The following logging levels are available:

Logging level Description

0 (None) Logging OFF
1 (Critical) Only critical events are logged, for example process exit or termination. If no logging
level is given by the user this level is used by default.
2 (Error) Only severe error events are logged, for example failures to complete a required task.
3 (Warning) Errors that can cause a service issue, but are acceptable or recoverable, for example the
first attempt to contact a forwarder has failed.
4 Very high-level events are recorded in the event log. These might include one message
(Informational) for each major task performed by the service. Use this setting to begin an investigation
when the location of the problem is in doubt, for example a scavenger thread was
started.
5 (Verbose) All events are logged. This provides a complete log of the operation of the service. Use
this level when the problem is traced to a particular category or a small set of
categories.
DNS server audit events enable change tracking on the DNS server. An audit event is logged
each time server, zone, or resource record settings are changed. This includes operational
events such as dynamic updates, zone transfers, and DNSSEC zone signing and unsigning.
The following table summarizes DNS server audit events.

Examples:
Event ID Type Category Level Event text
513 Zone delete Zone operations Informational The zone %1 was deleted.
514 Zone updated Zone operations Informational The zone %1 was updated. The %2 setting has been set to %3.

515 Record create Zone operations Informational A resource record of type %1, name %2, TTL %3 and RDATA %5 was created in
scope %7 of zone %6.

516 Record delete Zone operations Informational A resource record of type %1, name %2 and RDATA %5 was deleted from scope
%7 of zone %6.
 DNS server analytic events enable activity tracking on the DNS server. An analytic event is
logged each time the server sends or receives DNS information. The following table
summarizes DNS server analytic events.

Examples:
Event ID
257
Type
Response success
Category
Lookup
Level
Informational
Event text
RESPONSE_SUCCESS: TCP=%1; InterfaceIP=%2; Destination=%3; AA=%4; AD=%5; QNAME=%6; QTYPE=%7; XID=%8;
DNSSEC=%9; RCODE=%10; Port=%11; Flags=%12; Scope=%13; Zone=%14; PolicyName=%15; PacketData=%17

258 Response failure Lookup Error RESPONSE_FAILURE: TCP=%1; InterfaceIP=%2; Reason=%3; Destination=%4; QNAME=%5; QTYPE=%6; XID=%7;
RCODE=%8; Port=%9; Flags=%10; Zone=%11; PolicyName=%12; PacketData=%14

259 Ignored query Lookup Error IGNORED_QUERY: TCP=%1; InterfaceIP=%2; Reason=%3; QNAME=%4; QTYPE=%5; XID=%6; Zone=%7; PolicyName=%8

260 Query out Recursive query Informational RECURSE_QUERY_OUT: TCP=%1; Destination=%2; InterfaceIP=%3; RD=%4; QNAME=%5; QTYPE=%6; XID=%7;
Port=%8; Flags=%9; ServerScope=%10; CacheScope=%11; PolicyName=%12; PacketData=%14

261 Response in Recursive query Informational RECURSE_RESPONSE_IN: TCP=%1; Source=%2; InterfaceIP=%3; AA=%4; AD=%5; QNAME=%6; QTYPE=%7; XID=%8;
Port=%9; Flags=%10; ServerScope=%11; CacheScope=%12; PacketData=%14
• Domain Name System Security Extensions (DNSSEC) is a suite of extensions that add
security to the DNS protocol
• With DNSSEC, non-authoritative DNS servers are able to validate the responses they
receive when they query other DNS servers.
• In addition, DNS client computers running Windows® 7 or later can be configured to
require this validation be performed.
• The DNS protocol is vulnerable to attack due to an inherent lack of authentication and
integrity checking of data that is exchanged between DNS servers or provided to DNS
clients.
• DNSSEC adds security to DNS responses by providing the ability for DNS servers to
validate DNS responses.
• With DNSSEC, resource records are accompanied by digital signatures. These digital
signatures are generated when DNSSEC is applied to a DNS zone using a process called
zone signing.
• When a resolver issues a DNS query for resource record in a signed zone, a digital
signature is returned with the response so that validation can be performed.
• If validation is successful, this proves that the data has not been modified or tampered
with in any way.
• DNS spoofing is a type of attack that involves impersonation of DNS server responses in
order to introduce false information.
• In a spoofing attack, a malicious user attempts to guess that a DNS client or server has
sent a DNS query and is waiting for a DNS response.
• successful spoofing attack will insert a fake DNS response into the DNS server’s cache, a
process known as cache poisoning.
• A spoofed DNS server has no way of verifying that DNS data is authentic, and will reply
from its cache using the fake information.
DNSSEC uses digital signatures and cryptographic keys to validate that DNS responses are
authentic. The following topics briefly discuss how these signatures are managed and
validation is performed.

Digital signatures
Signatures generated with DNSSEC are contained within the DNS zone itself in the new
resource records. These new resource records are called RRSIG (resource record signature)
records. When a resolver issues a query for a name, the RRSIG record is returned in the
response. A public cryptographic key called a DNSKEY is needed to verify the signature. The
DNSKEY is retrieved by a DNS server during the validation process.
Zone signing
When you sign a zone with DNSSEC, you are individually signing all the records contained in
the zone. This makes it possible to add, modify, or delete records in the zone without re-
signing the entire zone. It is only necessary to re-sign the updated records.
• What if a DNS query is for a record that does not exist? If the DNS server responds that no record
was found, this response also needs to be validated as authentic.
• However, since there is no resource record, then there is no RRSIG record.
• The answer to this problem is the Next Secure (NSEC) record.
• NSEC records create a chain of links between signed resource records.
• To create NSEC records, the zone is sorted and NSEC records are created such that each NSEC
record has a pointer to the next NSEC record.
• The last NSEC record points back to the first record.
• When a query is submitted for a nonexistent record, the DNS server returns the NSEC record prior
to where the nonexistent record would have been in the order.
• This allows for something called authenticated denial of existence.

NSEC3 is a replacement or alternative to NSEC that has the additional benefit of preventing “zone
walking” which is the process of repeating NSEC queries in order to retrieve all the names in a zone. A
DNS server running Windows Server® 2012 supports both NSEC and NSEC3. A zone can be signed
with either NSEC or NSEC3, but not both.
• A trust anchor is a preconfigured public key associated with a specific zone.
• A validating DNS server must be configured with one or more trust anchors in order to perform
validation.
• If the DNS server is running on a domain controller, trust anchors are stored in the forest directory
partition in Active Directory Domain Services (AD DS) and can be replicated to all domain
controllers in the forest.
• On standalone DNS servers, trust anchors are stored in a file named TrustAnchors.dns. A DNS
server running Windows Server 2012 or Windows Server 2012 R2 also displays configured trust
anchors in the DNS Manager console tree in the Trust Points container. You can also use Windows
PowerShell or Dnscmd.exe to view trust anchors.
• DNSSEC key management strategy includes planning for key generation, key storage, key
expiration, and key replacement.
• Together, key expiration and replacement in DNSSEC is called key rollover.
• In Windows Server 2012 and Windows Server 2012 R2, key management is made easier
with simple and flexible key generation, Active Directory storage and replication, an
automated key rollover.
• In Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, the
DNS Client service continues to be non-validating and security-aware, the same as
computers running Windows 7 and Windows Server® 2008 R2.
• When the DNS client issues a query, it can indicate to the DNS server that it understands
DNSSEC. However, the client is non-validating.
• When issuing queries, the DNS client relies on the local DNS server to indicate that
validation was successful. If the server fails to perform validation, or reports that
validation was unsuccessful, the DNS Client service can be configured to return no
results.
• The Name Resolution Policy Table (NRPT) is a table that contains rules you can
configure to specify DNS settings or special behavior for names or namespaces.
• The NRPT can be configured using Group Policy or by using the Windows Registry.
• When performing DNS name resolution, the DNS Client service checks the NRPT before
sending a DNS query.
• If a DNS query or response matches an entry in the NRPT, it is handled according to
settings in the policy.
• Queries and responses that do not match an NRPT entry are processed normally.
• You can use the NRPT to require that the DNS Client service perform DNSSEC validation
of DNS responses for the namespaces that you specify.
Blokdyk, Gerardus (2018). Information security management system A Clear and Concise Reference. 5STARCooks.
Blokdyk, Gerardus (2018). Security Management Information System A Complete Guide. 5STARCooks.
Francis, Dishan (2017). Mastering Active Directory: Understand the Core Functionalities of Active Directory Services Using
Microsoft Server 2016 and PowerShell. Packt
Kim, David, Solomon, Michael (2016). Fundamentals of Information Systems Security 3rd Edition. Jones and Barnet
Learning.
Limoncelli, Thomas;Hogan, Christina; Chalup, Srata (2016). The Practice of System and Network Administration: Volume 1:
DevOps and other Best Practices for Enterprise IT (3rd Edition) 3rd Edition. Addison-Wesley