DNS

DNS?
Domain Name System is a service to resolve the Name to IP Address and IP Address to
Name, DNS also used to locate servers, computers and services on your network and DNS is
backbone of Active Directory that can be installed on windows server as a standalone or
Domain Controller.
DNS Console:
Open command prompt and type dnsmgmt.msc or go to server manager or administrative
management  DNS management
What is Static and Dynamic DNS Record?
Manually created DNS entry called static record and the record created automatically by the
system/DHCP itself called Dynamic DNS Record, static records are not easy to manage as
the IP address changes will not update automatically, we have to update manually.
Name Server:
Name Server is used for storing the information for the domain name to IP and IP to domain
name. In other words, the name server is used for storing records of the domain names. Name
servers help for convert domain name to IP address.
Name server is a server on the Internet specialized in handling queries regarding the location
of the domain name's various services. In easy words, name servers define your domain's
current DNS provider. All domains usually have at least two DNS servers which can be
checked via nslookup tool.

What is primary and secondary name server?

Primary name server reads the data from the domain zone, it has DNS records of domain
names and it replicates the data with the secondary name server.
A secondary name server is the backup of primary name server is having an issue or not
reachable.

What is DNS resolver?

DNS resolvers being used by ISP (Internet Service Provider) for the user request to resolve
the domain name. If a user request google.com, DNS resolver need to contact TLD(Top
Level Domain) i.e. .com, for translation of domain name to IP address and it caches the data
if the user again queries for the same domain, this reducing the loads on the server and
response time.
What is Dynamic DNS (DDNS)?
Dynamic DNS or DDNS is a method of updating a DNS record, DDNS is preferred most of
the organization since it’s easy to maintain and you always get the latest updated IP address
of the servers and computers

Dynamic DNS (DDNS or DynDNS) is a method of automatically updating a name server in

the Domain Name Server (DNS), often in real time, with the active DDNS configuration of
its configured hostnames, addresses or other information.
Simply Dynamic DNS helps for automatically updating the name servers whenever there is
change in IP address in the DNS.

How DDNS Service works?

To use DDNS, just sign up with a dynamic DNS provider and install their software on the
host computer. The host computer is whichever computer is used as the server, be it a file
server, web server, etc.
For example, if you have FTP software on your computer to turn that device into an FTP
server, you'd install the DDNS application on that computer. That computer is the one that
users will reach when they request your server, so it's the one that needs to always be
updating the DDNS provider with its current IP address.
What the software does is monitors the dynamic IP address for changes. When the address
changes (which it eventually will, by definition), the software contacts the DDNS service to
update your account with the new IP address.
This means that so long as the DDNS software is always running and can detect a change in
the IP address, the DDNS name you have associated with your account will continue to direct
visitors to the host server no matter how many times the IP address changes.
The reason a DDNS service is unnecessary for networks that have static IP addresses is
because the domain name doesn't need to know what the IP address is after it's initially told
of it the first time. This is because static addresses don't change.

What are the different types of DNS server?

All DNS servers fall into one of four categories: Recursive resolvers, root name servers, TLD
name servers, and authoritative name servers.

DNS Zone?
Zone is a sub tree of DNS database. A DNS zone file contains the mapping between a domain
name, IP address, resource records etc. in text representative format. Also, DNS zone refers
to the administrative responsibility in the DNS.

A DNS zone is the contiguous portion of the DNS domain name space over which a DNS
server has authority or is authoritative. DNS zones contain either domains or subdomains.

What is primary, Secondary, stub & AD Integrated Zone?

Primary Zone: - zone which is saved as normal text file with filename (.dns) in DBS folder.
Maintains a read, write copy of zone database.
Secondary Zone: - maintains a read only copy of zone database on another DNS server.
Provides fault tolerance and load balancing by acting as backup server to primary server.
Stub Zone: - contains a copy of name server and SOA records used for reducing the DNS
search orders. Provides fault tolerance and load balancing.
Note: Each zone can only have one primary DNS server, but it can have any number of
secondary DNS servers.

How do I configure Active Directory integrated DNS?

It is possible to configure DNS servers that are also domain controllers to store the contents
of the DNS database in the Active Directory which will then be replicated to all domain
controllers in the domain. The option to store the DNS database in the Active Directory is not
available on DNS servers that are not domain controllers.

 Start the "DNS Management" MMC snap-in (Start - Programs - Administrative Tools
- DNS Management)
 Expand the DNS server, expand the "Forward Lookup Zones", select the domain, e.g.
savilltech.com
 Right click on the domain and select Properties from the context menu
 Under Type click Change
 Select "Active Directory-integrated" and click OK
 Click OK to "Are you sure you want this zone to become an Active Directory-
integrated"
 Click Apply then OK.

Benefits of AD-integrated zones?

Active Directory integrated DNS enables Active Directory storage and replication of DNS
zone databases. Windows 2000 DNS server, the DNS server that is included with Windows
2000 Server, accommodates storing zone data in Active Directory.
When you configure a computer as a DNS server, zones are usually stored as text files on
name servers that is, all the zones required by DNS are stored in a text file on the server
computer.
These text files must be synchronized among DNS name servers by using a system that
requires a separate replication topology and schedule called a zone transfer. However, if you
use Active Directory integrated DNS when you configure a domain controller as a DNS name
server, zone data is stored as an Active Directory object and is replicated as part of domain
replication.

What is ZONE transfer in DNS?

Zone transfer is the process of replicating a zone file to another name server and is
accomplished by copying the zone file information from the master server to the secondary
server. Zone transfers take place when names and IP address mappings change in a domain.

Where AD is integrated DNS stored?

DNS zone data stored in Forest DNS Zone is replicated to every DNS server in the
contiguous AD forest. If the zones weren't stored in AD, they would be stored in flat files
(i.e., non–AD integrated).

Benefit of configuring multiple DNS server in Active Directory?

To make the deployment of multiple DNS servers easier you should use Active Directory
integrated zones. You can only use AD integrated zones if you have DNS configured on your
domain controllers. If one DNS server fails, the other server has a full copy of the DNS
information and can resolve names for clients.

What are the requirements from DNS to support AD?

When you install Active Directory on a member server, the member server is promoted to a
domain controller. Active Directory uses DNS as the location mechanism for domain
controllers, enabling computers on the network to obtain IP addresses of domain controllers.
During the installation of Active Directory, the service (SRV) and address (A) resource
records are dynamically registered in DNS, which are necessary for the successful
functionality of the domain controller locator (Locator) mechanism.
To find domain controllers in a domain or forest, a client queries DNS for the SRV and A
DNS resource records of the domain controller, which provide the client with the names and
IP addresses of the domain controllers. In this context, the SRV and A resource records are
referred to as Locator DNS resource records.
When adding a domain controller to a forest, you are updating a DNS zone hosted on a DNS
server with the Locator DNS resource records and identifying the domain controller. For this
reason, the DNS zone must allow dynamic updates (RFC 2136) and the DNS server hosting
that zone must support the SRV resource records (RFC 2782) to advertise the Active
Directory service. For more information about RFCs, see DNS RFCs.
If the DNS server hosting the authoritative DNS zone is not a server running Windows 2000
or Windows Server 2003, contact your DNS administrator to determine if the DNS server
supports the required standards. If the server does not support the required standards, or the
authoritative DNS zone cannot be configured to allow dynamic updates, then modification is
required to your existing DNS infrastructure.
For more information, see Checklist: Verifying DNS before installing Active Directory and
Using the Active Directory Installation Wizard.

Important:
The DNS server used to support Active Directory must support SRV resource records for the
Locator mechanism to function. For more information, see managing resource records. It is
recommended that the DNS infrastructure allows dynamic updates of Locator DNS resource
records (SRV and A) before installing Active Directory, but your DNS administrator may add
these resource records manually after installation. After installing Active Directory, these
records can be found on the domain controller in the following location: systemroot\
System32\Config\Netlogon.dns.

What is Resource Record?

Resource Record (RR) defines the elements or attributes of a domain name in DNS zone file
like Address (A) record, Mail Exchange (MX) record, CNAME, PTR, SOA, NS etc.
Simply it is a record which provides the information about the resources available in the N/W
infrastructure.
MX Record?
Mail Exchange record is a type of resource record which is used for email sending and
delivery.
It must be specified in the DNS zone files mails for the domain.
PTR Record?
PTR (Pointer) records are used for mapping IP addresses which are associated with hostname
name. It also called reverse DNS lookup at it resolves IP address to domain or hostname.
There must be "A" record for every PTR record. PTR mainly used for the mail server.
CNAME Record?
CNAME record stands for Canonical Name record. It used as the alias for domain or the
Canonical name (alias name) for a domain.
E.g. By mistake we have typed freshersworld.com as fresherworld.com, then by CNAME
record we can redirect to
freshersworld.com.
This is a type of resource record in DNS which is specified in the zone file.
CNAME records should always point to another domain and never directly point to IP
address.

How do you manually create SRV records in DNS?

This is on windows server go to run  dnsmgmt.msc right click on the zone you want to
add srv record to and choose "other new record" and choose service location (srv).

What is the main purpose of SRV records?

SRV records are used in locating hosts that provide certain network services

SOA Records must have to be included in every zone, what are they used for?
SOA records contain a TTL value, used by default in all resource records in the zone. SOA
records contain the email address of the person who is responsible for the zone.
Also it contain the serial number of the zone, which is use for zone transfer.

Generally, SOA record stores essential information like refresh rate, expiry, TTL in Domain
Name System in a zone file.
Serial Number  It has the serial number, which gets increments whenever there is a
change in DNS records.
Refresh Interval  It gets refresh at the specific interval and if there any changes in the
records, data is replicated.
Retry  If the propagation failed, it will retry after specific time which is defined in the zone
file.
Expire  It is set to have an expiry day, as specified in the zone file. Also used for
secondary server how long it should be active in case the primary DNS server is down.
TTL  It has the default time to live (TTL).
A zone file should have only one SOA record and it must be at the top of it.

TTL values in DNS records?

In an ideal world, the DNS would be like one of those As-Seen-On-TV rotisserie ovens - set
it and forget it. However, the Internet is a dynamically changing place and what may be
relevant in one moment may not be the next.
To cope with this, the DNS was designed with a mechanism to refresh records and ensure
that users were always given the most pertinent answer when they requested it.

The Basics
Time To Live or TTL is the sort of expiration date that is put on a DNS record. The TTL
serves to tell the recursive server or local resolver how long it should keep said record in its
cache. The longer the TTL, the longer the resolver holds that information in its cache. The
shorter the TTL, the shorter amount of time the resolver holds that information in its cache.
For example, we’ve got example.com. Example.com has an A-Record at the apex of the zone
to point us to a server. With a TTL of 3600 seconds or 1 hour, that means that as a recursive
server learns about example.com, it will store that information about the A-record at
example.com for one hour. Anyone else who uses that same resolver will get the same
answer and on the authoritative side, there will be no query to the server unless the TTL runs
out.
Best Practices:
TTLs are nothing to take lightly - they can directly affect the amount of query volume that is
attributable to your authoritative service, and in the event of needing to quickly change the
record, can result in longer than expected change propagation to all users.
For records that leverage a sort of advanced traffic management scenario, such as NS1’s
Filter Chain, it’s best to keep the TTL as short as possible. This way, when a change is
enacted by the system, users on the other end requesting the name are given the most recent
information. It’s worth noting that most recursive servers do not actually understand a TTL
shorter than 30 seconds - while we won’t stop you from going lower than that, the results
may not be favourable in the long run.
For records that rarely change, such as TXT or MX records, it’s best to keep those
somewhere between an hour (3600s) and a day (86400s). When it does come time to enact
changes with regard to these types of records, it may behove you to change the TTL down to
a shorter interval before enacting any changes to ensure that the changes are propagated
quickly.

The SOA TTLs:

At the top of every DNS zone, in the Start of Authority (SOA), there are five TTL values that
serve a higher purpose in the DNS.
SOA TTL - The interval at which the SOA record itself is refreshed.
Refresh TTL - The interval at which slave servers (secondary DNS) are set to refresh the
master zone file from the master server.
Retry TTL - The rate at which a slave server will retry to refresh the master zone file if the
initial refresh failed.
Expiry TTL - If Refresh and Retry fail repeatedly, this is the time period after which the
master should be considered gone and no longer authoritative for the given zone.
NX TTL - In the event that requesting the domain results in a non-existent query
(NXDOMAIN), this is the amount of time that is respected by the recursor to return the
NXDOMAIN response.
It is recommended to not modify these TTLs unless you have a very specific need to do so,
which is often a very rare case.

DNS – TCP vs UDP?

DNS and some other services work on both the protocols. We will take an example of DNS
Service. Two protocols are somewhat different from each other. TCP is a connection-oriented
protocol and it requires data to be consistent at the destination and UDP is connection-less
protocol and doesn't require data to be consistent or don't need a connection to be established
with host for consistency of data.

UDP packets are smaller in size. UDP packets cannot be greater than 512 bytes. So any
application needs data to be transferred greater than 512 bytes require TCP in place. For
example, DNS uses both TCP and UDP for valid reasons described below. Note that UDP
messages are not larger than 512 Bytes and are truncated when greater than this size. DNS
uses TCP for Zone transfer and UDP for name queries either regular (primary) or reverse.
UDP can be used to exchange small information whereas TCP must be used to exchange
information larger than 512 bytes. If a client doesn't get response from DNS it must re-
transmit the data using TCP after 3-5 seconds of interval.

There should be consistency in DNS Zone database. To make this, DNS always transfer Zone
data using TCP because TCP is reliable and make sure zone data is consistent by transferring
the full zone to other DNS servers who has requested the data.

The problem occurs when Windows 2000 server and Advanced Server products uses
Dynamic ports for all above 1023. In this case your DNS server should not be internet facing
i.e. doing all standard queries for client machines on the network. The router (ACL) must
permitted all UDP inbound traffic to access any high UDP ports for it to work.

LDAP always uses TCP - this is true and why not UDP because a secure connection is
established between client and server to send the data and this can be done only using TCP
not UDP. UDP is only used when finding a domain controller (Kerberos) for authentication.
For example, a domain client finding a domain controller using DNS.

What are the benefits and scenarios of using Conditional Forwarding?

Rather than having a DNS server forward all queries it cannot resolve to forwarders; the DNS
server can forward queries for different domain names to different DNS servers according to
the specific domain names that are contained in the queries. Forwarding according to these
domain-name conditions improves conventional forwarding by adding a second condition to
the forwarding process.
A conditional forwarder setting consists of a domain name and the IP address of one or more
DNS servers. To configure a DNS server for conditional forwarding, a list of domain names
is set up on the Windows Server 2003-based DNS server along with the DNS server IP
address. When a DNS client or server performs a query operation against a Windows Server
2003- based DNS server that is configured for forwarding, the DNS server looks to see if the
query can be resolved by using its own zone data or the zone data that is stored in its cache,
and then, if the DNS server is configured to forward for the domain name that is designated
in the query (a match), the query is forwarded to the IP address of a DNS Server that is
associated with the domain name. If the DNS server has no domain name listed for the name
that is designated in the query, it attempts to resolve the query by using standard recursion.

What is the 224.0.1.24 address used for?

WINS server group address. Used to support auto discovery and dynamic configuration of
replication for WINS servers. For more information, see WINS replication overview WINS
server group address. Used to support auto discovery and dynamic configuration of
replication for WINS servers.

RNDC?
RNDC stands for Remote Name Daemon Control. It is a name server control utility in bind.
To prevent unauthorized users to the named daemon, BIND uses a shared secret key
authentication method to grant privileges to particular hosts.

On which port DNS Server works?

DNS servers use port 53 by default. Incoming and outgoing packets should be allowed on
port 53. Also allow connections on port 921 if you configure a lightweight resolver server.
The DNS control utility, rndc, connects to the DNS server with TCP port 953 by default. If
we are running rndc on the name server, connections on this TCP port from local host should
be allowed. If we are running rndc on additional systems, allow connections to port 953(or
whatever port we have chosen to configure) from these additional systems.

DNS Caching and How It Makes Your Internet Better?

A DNS cache (sometimes called a DNS resolver cache) is a temporary database, maintained
by a computer's operating system, that contains records of all the recent visits and attempted
visits to websites and other internet domains.
In other words, a DNS cache is just a memory of recent DNS lookups that your computer can
quickly refer to when it's trying to figure out how to load a website.
Most people only hear the phrase "DNS cache" when it refers to flushing/clearing the DNS
cache in order to help fix an internet connectivity issue. There's more on that at the bottom of
this page.

The Purpose of a DNS Cache?

The internet relies on the Domain Name System (DNS) to maintain an index of all public
websites and their corresponding IP addresses. You can think of it as a phone book.
With a phone book, we don't have to memorize everyone's phone number, which is the only
way phones can communicate: with a number. In the same way, DNS is used so we can avoid
having to memorize every website's IP address, which is the only way network equipment
can communicate with websites.
This is what happens behind the certain when you ask your web browser to load a
website.
You type in a URL like lifewire.com and your web browser asks your router for the IP
address. The router has a DNS server address stored, so it asks the DNS server for the IP
address of that hostname. The DNS server finds the IP address that belongs to lifewire.com
and then is able to understand what website you're asking for, after which your browser can
then load the appropriate page.
This happens for every website you want to visit. Every time a user visits a website by its
hostname, the web browser initiates a request out to the internet, but this request cannot be
completed until the site's name is "converted" into an IP address.
The problem is that even though there are tons of public DNS servers your network can use
to try to speed up the conversion/resolution process, it's still quicker to have a local copy of
the "phone book," which is where DNS caches come into play.
The DNS cache attempts to speed up the process even more by handling the name resolution
of recently visited addresses before the request is sent out to the internet.
Note:
There are actually DNS caches at every hierarchy of the "lookup" process that ultimately gets
your computer to load the website. The computer reaches your router, which contacts your
ISP, which might hit another ISP before ending up at what's called the "root DNS servers."
Each of those points in the process has a DNS cache for the same reason, which is to speed
up the name resolution process.

How a DNS Cache Works:

Before a browser issues its requests to the outside network, the computer intercepts each one
and looks up the domain name in the DNS cache database. The database contains a list of all
recently accessed domain names and the addresses that DNS calculated for them the first time
a request was made.
The contents of a local DNS cache can be viewed on windows using the command.
ipconfig /displaydns, with results similar to this.
In DNS, the "A" record is the portion of the DNS entry that contains the IP address for the
given host name. The DNS cache stores this address, the requested website name, and several
other parameters from the host DNS entry.

What Is DNS Cache Poisoning?

A DNS cache becomes poisoned or polluted when unauthorized domain names or IP

addresses are inserted into it.
Occasionally a cache may become corrupted due to technical glitches or administrative
accidents, but DNS cache poisoning is typically associated with computer viruses or other
network attacks that insert invalid DNS entries into the cache.

Poisoning causes client requests to be redirected to the wrong destinations, usually malicious
websites or pages full of advertisements.
For example, if the docs.google.com record from above had a different "A" record, then when
you entered docs.google.com in your web browser, you'd be taken somewhere else.
This poses a massive problem for popular websites. If an attacker redirects your request for
Gmail.com, for example, to a website that looks like Gmail but isn't, you might end up
suffering from a phishing attack like whaling.

DNS Flushing: What It Does and How to Do It?

When troubleshooting cache poisoning or other internet connectivity issues, a computer
administrator may wish to flush (i.e. clear, reset, or erase) a DNS cache.

Since clearing the DNS cache removes all the entries, it deletes any invalid records too and
forces your computer to repopulate those addresses the next time you try accessing those
websites. These new addresses are taken from the DNS server your network is set up to use.

So, to use the example above, if the Gmail.com record was poisoned and redirecting you to a
strange website, flushing the DNS is a good first step to getting the regular Gmail.com back
again.

In Microsoft Windows, you can flush the local DNS cache using the ipconfig /flushdns
command in a Command Prompt. You know it works when you see the Windows IP
configuration successfully flushed the DNS Resolver Cache or successfully flushed the DNS
Resolver Cache message.
Through a command terminal, macOS users should use dscacheutil -flushcache, but know
that there is not a "successful" message after it runs, so you're not told if it worked. Linux
users should enter the /etc/rc.d/init.d/nscd restart command.

A router can have a DNS cache as well, which is why rebooting a router is often a
troubleshooting step. For the same reason you might flush the DNS cache on your computer,
you can reboot your router to clear the DNS entries stored in its temporary memory.

Private & Public DNS?

Private DNS for example your internal DNS servers for your Domain.

Public DNS is for external that the public can look up against.
8.8.8.8 & 8.8.4.4  google.com public DNS for speedup browsing experience, improve
security and get the result we expect with absolutely no redirection.

DNS spoofing?
DNS cache poisoning, also known as DNS spoofing, is a type of attack that exploits
vulnerabilities in the domain name system (DNS) to divert Internet traffic away from
legitimate servers and towards fake ones. One of the reasons DNS poisoning is so dangerous
is because it can spread from DNS server to DNS server.
How to Prevent DNS Spoofing?
As a website visitor, there’s not much you can do to prevent DNS spoofing. Rather, this falls
more in the hands of the actual DNS provider that is handling a website’s DNS lookups as
well as the website owner. Therefore, a few tips for site owners and DNS providers includes:
Implement DNS spoofing detection mechanisms - it’s important to implement DNS spoofing
detection software. Products such as XArp help product against ARP cache poisoning by
inspecting the data that comes through before transmitting it.
Use encrypted data transfer protocols - Using end-to-end encryption vian SSL/TLS will help
decrease the chance that a website / its visitors are compromised by DNS spoofing. This type
of encryption allows the users to verify whether the server’s digital certificate is valid and
belongs to the website’s expected owner.
Use DNSSEC - DNSSEC, or Domain Name System Security Extensions, uses digitally
signed DNS records to help determine data authenticity. DNSSEC is still a work in progress
as far as deployment goes, however implement in the Internet root was level in 2010. An
example of a DNS service that fully supports DNSSEC is Google's Public DNS.

By default, if the name is not found in the cache or local hosts file, what is the first step
the client takes to resolve the FQDN name into an IP address?
Performs a recursive search through the primary DNS server based on the network interface
configuration.
Before installing your first domain controller in the network, you installed a DNS server
and created a zone, naming it as you would name your AD domain. However, after the
installation of the domain controller, you are unable to locate infrastructure SRV
records anywhere in the zone. What is the most likely cause of this failure?
The zone you created was not configured to allow dynamic updates. The local interface on
the DNS server was not configured to allow dynamic updates.

At some point during the name resolution process, the requesting party received
authoritative reply. Which further actions are likely to be taken after this reply?
After receiving the authoritative reply, the resolution process is effectively over.

Your company uses ten domain controllers, three of which are also used as DNS servers.
You have one companywide AD-integrated zone, which contains several thousand
resource records. This zone also allows dynamic updates, and it is critical to keep this
zone up-to-date. Replication between domain controllers takes up a significant amount
of bandwidth. You are looking to cut bandwidth usage for the purpose of replication.
What should you do?
Change the replication scope to all DNS servers in the domain.

You are administering a network connected to the Internet. Your users complain that
everything is slow. Preliminary research of the problem indicates that it takes a
considerable amount of time to resolve names of resources on the Internet. What is the
most likely reason for this?

DNS servers are not caching replies. Local client computers are not caching replies. The
cache. DNS file may have been corrupted on the server.

You installed a new AD domain and the new (and first) DC has not registered its SRV
records in DNS. Name a few possible causes.
The machine cannot be configured with DNS client by own.
The DNS service cannot be run.

How to enable Dynamic updates in DNS?

Start>Program>Admin tools> DNS >Zone properties.

What are the properties of DNS server?

INTERFACES, FORWARDERS, ADVANCED, ROUTINGS, SECURITY,
MONITORING, LOGGING, DEBUG LOGGING.

Properties of a Zone?
General, SOA, NAMESERVER, WINS, Security, and ZONE Transfer.

What is scavenging?
Finding and deleting unwanted records.

How do I clear the DNS cache on the DNS server?

Go to cmd prompt and type ipconfig /flushdns
What is the main purpose of SRV records?
SRV records are used in locating hosts that provide certain network services.

What should I do if the domain controller points to itself for DNS, but the SRV records
still do not appear in the zone?
Check for a disjointed namespace, and then run Netdiag.exe /fix.
You must install Support Tools from the Windows 2000 Server or Windows Server 2003
CD-ROM to run Netdiag.exe.

How do I set up DNS for a child domain?

To set up DNS for a child domain, create a delegation record on the parent DNS server for
the child DNS server. Create a secondary zone on the child DNS server that transfers the
parent zone from the parent DNS server.

Note Windows Server 2003 has additional types of zones, such as Stub Zones and forest-
level integrated Active Directory zones, which may be a better fit for your environment. Set
the child domain controller to point to itself first. As soon as an additional domain controller
is available, set the child domain controller to point to this domain controller in the child
domain as its secondary.

DNS Feature in 2016:

DNS Policy is a new feature for DNS in Windows Server® 2016. You can use this guide to
learn how to use DNS policy to control how a DNS server processes name resolution queries
based on different parameters that you define in policies.

DNS Fail Over:

DNS failover helps websites or network services remain accessible in the event of outage.
The Domain Name System (DNS) is the protocol used to translate human readable
hostnames into IP addresses. By providing two or more IP address in a DNS record, each IP
representing an identical server, you can move traffic from a failing server to a live,
redundant server.
DNS failover can work on the client side or on the server side. In either mode, a DNS A
record must be defined with more than one IP address (known as DNS A record failover).
The first IP address should point to the default, production server, and the other IP addresses
should point to identical (or frequently synchronized) redundant servers.
To implement failover on the server side, you’ll need to monitor all the servers listed in the
DNS records—the primary server and additional redundant servers. As soon as a server goes
down, the DNS server should automatically switch the DNS A record to list the IP address
for the working server first.

When DNS resolvers come back to request the IP address for the site, they receive the
updated IP address, and route the user to the redundant server.

There are several DNS providers that offer DNS failover as a managed service, including
monitoring.

I have a domain server running in a virtual machine and when windows updates it
reboot the computer putting the system offline and all devices that are connected to the
network are unable to connect to the internet after that. What my plan is to have
another server in my room and have it act as a fail over encase the main server goes
offline. My main server is a 2012 R2 server and what i want to do is use 2003 or 2008
without R2 as the fail over. How can I do this?
Use 2003 or 2008 without R2 as the fail over. Each of them could achieve the goal. You
could install DNS role on the server, and configure the zones. Then, on client, configure your
domain server as Preferred DNS server and the other server as Alternate DNS server. When
the domain server is down, the clients would query the alternate DNS server if they failed to
get response from the preferred one.
After you build a new host and install DNS role, add a secondary zone on the new host. And
enable zone transfer on your domain server. All the changes made to the zone would be
replicated to the zone on the new host.
Previous versions of Windows Server DNS only provided load balancing by using round
robin responses; but with DNS in Windows Server 2016, you can configure DNS policy for
application load balancing.
When you have deployed multiple instances of an application, you can use DNS policy to
balance the traffic load between the different application instances, thereby dynamically
allocating the traffic load for the application.
Note: "What's new in DNS Server in Windows Server 2016" is new feature called "DNS
Policies"

Example of Application Load Balancing:

Following is an example of how you can use DNS policy for application load balancing.
This example uses one fictional company - Contoso Gift Services - which provides online
gifting services, and which has a Web site named contosogiftservices.com.

The contosogiftservices.com website is hosted in multiple datacentres that each have different
IP addresses.

In North America, which is the primary market for Contoso Gift Services, the Web site is
hosted in three datacentres: Chicago, IL, Dallas, TX and Seattle, WA.

The Seattle Web server has the best hardware configuration and can handle twice as much
load as the other two sites. Contoso Gift Services wants application traffic directed in the
following manner.

Because the Seattle Web server includes more resources, half of the application's clients are
directed to this server
One quarter of the application's clients are directed to the Dallas, TX datacentre
One quarter of the application's clients are directed to the Chicago, IL, datacentre
The following illustration depicts this scenario.
How Application Load Balancing Works:
After you have configured the DNS server with DNS policy for application load balancing
using this example scenario, the DNS server responds 50% of the time with the Seattle Web
server address, 25% of the time with the Dallas Web server address, and 25% of the time
with the Chicago Web server address.

Thus for every four queries the DNS server receives, it responds with two responses for
Seattle and one each for Dallas and Chicago.

One possible issue with load balancing with DNS policy is the caching of DNS records by the
DNS client and the resolver/LDNS, which can interfere with load balancing because the
client or resolver do not send a query to the DNS server.

You can mitigate the effect of this behaviour by using a low Time-to-Live (TTL) value for
the DNS records that should be load balanced.

How to Configure Application Load Balancing:

The following sections show you how to configure DNS policy for application load
balancing.

You must first create the scopes of the zone contosogiftservices.com for the datacentres
where they are hosted.

A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes,
with each zone scope containing its own set of DNS records. The same record can be present
in multiple scopes, with different IP addresses or the same IP addresses.
Note: By default, a zone scope exists on the DNS zones. This zone scope has the same name
as the zone, and legacy DNS operations work on this scope.

You can use the following Windows PowerShell commands to create zone scopes.

Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name

"SeattleZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name
"DallasZoneScope"
Add-DnsServerZoneScope -ZoneName "contosogiftservices.com" -Name
"ChicagoZoneScope"

Add Records to the Zone Scopes:

Now you must add the records representing the web server host into the zone scopes.

In SeattleZoneScope, you can add the record www.contosogiftservices.com with IP address

192.0.0.1, which is located in the Seattle datacentre.

In ChicagoZoneScope, you can add the same record (www.contosogiftservices.com) with IP

address 182.0.0.1 in the Chicago datacentre.

Similarly in DallasZoneScope, you can add a record (www.contosogiftservices.com) with IP

address 162.0.0.1 in the Chicago datacentre.
You can use the following Windows PowerShell commands to add records to the zone
scopes.

Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name

"www" -IPv4Address "192.0.0.1" -ZoneScope "SeattleZoneScope
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name
"www" -IPv4Address "182.0.0.1" -ZoneScope "ChicagoZoneScope"
Add-DnsServerResourceRecord -ZoneName "contosogiftservices.com" -A -Name
"www" -IPv4Address "162.0.0.1" -ZoneScope "DallasZoneScope"

After you have created the partitions (zone scopes) and you have added records, you must
create DNS policies that distribute the incoming queries across these scopes so that 50% of
queries for contosogiftservices.com are responded to with the IP address for the Web server
in the Seattle datacentre and the rest are equally distributed between the Chicago and Dallas
data centres.

You can use the following Windows PowerShell commands to create a DNS policy that
balances application traffic across these three datacentres.

Note: In the example command below, the expression –ZoneScope "SeattleZoneScope,2;

ChicagoZoneScope,1; DallasZoneScope,1" configures the DNS server with an array that
includes the parameter combination <ZoneScope>,<weight>.
Add-DnsServerQueryResolutionPolicy -Name "AmericaPolicy" -Action ALLOW -
ZoneScope "SeattleZoneScope, 2; ChicagoZoneScope,1; DallasZoneScope,1" -ZoneName
"contosogiftservices.com"

You have now successfully created a DNS policy that provides application load balancing
across Web servers in three different datacentres.

You can create thousands of DNS policies according to your traffic management
requirements, and all new policies are applied dynamically - without restarting the DNS
server - on incoming queries.