Domain Name System (DNS)

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Domain Name System (DNS) is one of the industry-standard suite of protocols that comprise TCP/IP, and together the DNS Client and DNS Server provide computer name-to-IP address mapping name resolution services to computers and users.

In addition to this topic, the following DNS content is available.

In Windows Server 2016, DNS is a server role that you can install by using Server Manager or Windows PowerShell commands. If you are installing a new Active Directory forest and domain, DNS is automatically installed with Active Directory as the Global Catalogue server for the forest and domain.

Active Directory Domain Services (AD DS) uses DNS as its domain controller location mechanism. When any of the principal Active Directory operations is performed, such as authentication, updating, or searching, computers use DNS to locate Active Directory domain controllers. In addition, domain controllers use DNS to locate each other.

The DNS Client service is included in all client and server versions of the Windows operating system, and is running by default upon operating system installation. When you configure a TCP/IP network connection with the IP address of a DNS server, the DNS Client queries the DNS server to discover domain controllers, and to resolve computer names to IP addresses. For example, when a network user with an Active Directory user account logs in to an Active Directory domain, the DNS Client service queries the DNS server to locate a domain controller for the Active Directory domain. When the DNS server responds to the query and provides the domain controller’s IP address to the client, the client contacts the domain controller and the authentication process can begin.

The Windows Server 2016 DNS Server and DNS Client services use the DNS protocol that is included in the TCP/IP protocol suite. DNS is part of the application layer of the TCP/IP reference model, as shown in the following illustration.

What’s New in DNS Server in Windows Server

Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

This topic describes the Domain Name System (DNS) server functionality that is new or changed in Windows Server 2016.

In Windows Server 2016, DNS Server offers enhanced support in the following areas.

Functionality	New or Improved	Description
DNS Policies	New	You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS responses can be based on client IP address (location), time of the day, and several other parameters. DNS policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other scenarios.
Response Rate Limiting (RRL)	New	You can enable response rate limiting on your DNS servers. By doing this, you avoid the possibility of malicious systems using your DNS servers to initiate a denial of service attack on a DNS client.
DNS-based Authentication of Named Entities (DANE)	New	You can use TLSA (Transport Layer Security Authentication) records to provide information to DNS clients that state what CA they should expect a certificate from for your domain name. This prevents man-in-the-middle attacks where someone might corrupt the DNS cache to point to their own website, and provide a certificate they issued from a different CA.
Unknown record support	New	You can add records which are not explicitly supported by the Windows DNS server using the unknown record functionality.
IPv6 root hints	New	You can use the native IPV6 root hints support to perform internet name resolution using the IPV6 root servers.
Windows PowerShell Support	Improved	New Windows PowerShell cmdlets are available for DNS Server.

DNS Policies

You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and more. The following items provide more detail about these capabilities.

Application Load Balancing. When you have deployed multiple instances of an application at different locations, you can use DNS policy to balance the traffic load between the different application instances, dynamically allocating the traffic load for the application.

Geo-Location Based Traffic Management. You can use DNS Policy to allow primary and secondary DNS servers to respond to DNS client queries based on the geographical location of both the client and the resource to which the client is attempting to connect, providing the client with the IP address of the closest resource.

Split Brain DNS. With split-brain DNS, DNS records are split into different Zone Scopes on the same DNS server, and DNS clients receive a response based on whether the clients are internal or external clients. You can configure split-brain DNS for Active Directory integrated zones or for zones on standalone DNS servers.

Filtering. You can configure DNS policy to create query filters that are based on criteria that you supply. Query filters in DNS policy allow you to configure the DNS server to respond in a custom manner based on the DNS query and DNS client that sends the DNS query.

Forensics. You can use DNS policy to redirect malicious DNS clients to a non-existent IP address instead of directing them to the computer they are trying to reach.

Time of day based redirection. You can use DNS policy to distribute application traffic across different geographically distributed instances of an application by using DNS policies that are based on the time of day.

You can also use DNS policies for Active Directory integrated DNS zones.

For more information, see the DNS Policy Scenario Guide.

Response Rate Limiting

You can configure RRL settings to control how to respond to requests to a DNS client when your server receives several requests targeting the same client. By doing this, you can prevent someone from sending a Denial of Service (Dos) attack using your DNS servers. For instance, a bot net can send requests to your DNS server using the IP address of a third computer as the requestor. Without RRL, your DNS servers might respond to all the requests, flooding the third computer. When you use RRL, you can configure the following settings:

Responses per second. This is the maximum number of times the same response will be given to a client within one second.

Errors per second. This is the maximum number of times an error response will be sent to the same client within one second.

Window. This is the number of seconds for which responses to a client will be suspended if too many requests are made.

Leak rate. This is how frequently the DNS server will respond to a query during the time responses are suspended. For instance, if the server suspends responses to a client for 10 seconds, and the leak rate is 5, the server will still respond to one query for every 5 queries sent. This allows the legitimate clients to get responses even when the DNS server is applying response rate limiting on their subnet or FQDN.

TC rate. This is used to tell the client to try connecting with TCP when responses to the client are suspended. For instance, if the TC rate is 3, and the server suspends responses to a given client, the server will issue a request for TCP connection for every 3 queries received. Make sure the value for TC rate is lower than the leak rate, to give the client the option to connect via TCP before leaking responses.

Maximum responses. This is the maximum number of responses the server will issue to a client while responses are suspended.

Allowlist domains. This is a list of domains to be excluded from RRL settings.

Allowlist subnets. This is a list of subnets to be excluded from RRL settings.

Allowlist server interfaces. This is a list of DNS server interfaces to be excluded from RRL settings.

DANE support

You can use DANE support (RFC 6394 and 6698) to specify to your DNS clients what CA they should expect certificates to be issued from for domains names hosted in your DNS server. This prevents a form of man-in-the-middle attack where someone is able to corrupt a DNS cache and point a DNS name to their own IP address.

For instance, imagine you host a secure website that uses SSL at www.contoso.com by using a certificate from a well-known authority named CA1. Someone might still be able to get a certificate for www.contoso.com from a different, not-so-well-known, certificate authority named CA2. Then, the entity hosting the fake www.contoso.com website might be able to corrupt the DNS cache of a client or server to point www.contoto.com to their fake site. The end user will be presented a certificate from CA2, and may simply acknowledge it and connect to the fake site. With DANE, the client would make a request to the DNS server for contoso.com asking for the TLSA record and learn that the certificate for www.contoso.com was issues by CA1. If presented with a certificate from another CA, the connection is aborted.

Unknown record support

An «Unknown Record» is an RR whose RDATA format is not known to the DNS server. The newly added support for unknown record (RFC 3597) types means that you can add the unsupported record types into the Windows DNS server zones in the binary on-wire format. The windows caching resolver already has the ability to process unknown record types. Windows DNS server will not do any record specific processing for the unknown records, but will send it back in responses if queries are received for it.

IPv6 root hints

The IPV6 root hints, as published by IANA, have been added to the windows DNS server. The internet name queries can now use IPv6 root servers for performing name resolutions.

Windows PowerShell support

The following new Windows PowerShell cmdlets and parameters are introduced in Windows Server 2016.

Add-DnsServerRecursionScope. This cmdlet creates a new recursion scope on the DNS server. Recursion scopes are used by DNS policies to specify a list of forwarders to be used in a DNS query.

Remove-DnsServerRecursionScope. This cmdlet removes existing recursion scopes.

Set-DnsServerRecursionScope. This cmdlet changes the settings of an existing recursion scope.

Get-DnsServerRecursionScope. This cmdlet retrieves information about existing recursion scopes.

Add-DnsServerClientSubnet. This cmdlet creates a new DNS client subnet. Subnets are used by DNS policies to identify where a DNS client is located.

Remove-DnsServerClientSubnet. This cmdlet removes existing DNS client subnets.

Set-DnsServerClientSubnet. This cmdlet changes the settings of an existing DNS client subnet.

Get-DnsServerClientSubnet. This cmdlet retrieves information about existing DNS client subnets.

Add-DnsServerQueryResolutionPolicy. This cmdlet creates a new DNS query resolution policy. DNS query resolution policies are used to specify how, or if, a query is responded to, based on different criteria.

Remove-DnsServerQueryResolutionPolicy. This cmdlet removes existing DNS policies.

Set-DnsServerQueryResolutionPolicy. This cmdlet changes the settings of an existing DNS policy.

Get-DnsServerQueryResolutionPolicy. This cmdlet retrieves information about existing DNS policies.

Enable-DnsServerPolicy. This cmdlet enables existing DNS policies.

Disable-DnsServerPolicy. This cmdlet disables existing DNS policies.

Add-DnsServerZoneTransferPolicy. This cmdlet creates a new DNS server zone transfer policy. DNS zone transfer policies specify whether to deny or ignore a zone transfer based on different criteria.

Remove-DnsServerZoneTransferPolicy. This cmdlet removes existing DNS server zone transfer policies.

Set-DnsServerZoneTransferPolicy. This cmdlet changes settings of an existing DNS server zone transfer policy.

Get-DnsServerResponseRateLimiting. This cmdlet retrieves RRL settings.

Set-DnsServerResponseRateLimiting. This cmdlet changes RRL settigns.

Add-DnsServerResponseRateLimitingExceptionlist. This cmdlet creates an RRL exception list on the DNS server.

Get-DnsServerResponseRateLimitingExceptionlist. This cmdlet retrieves RRL excception lists.

Remove-DnsServerResponseRateLimitingExceptionlist. This cmdlet removes an existing RRL exception list.

Set-DnsServerResponseRateLimitingExceptionlist. This cmdlet changes RRL exception lists.

Add-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Get-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Remove-DnsServerResourceRecord. This cmdlet was updated to support unknown record type.

Set-DnsServerResourceRecord. This cmdlet was updated to support unknown record type

For more information, see the following Windows Server 2016 Windows PowerShell command reference topics.

What Is a DNS Server?

Everything you need to know about network DNS servers

A DNS server is a computer server that contains a database of public IP addresses and their associated hostnames, and in most cases serves to resolve, or translate, those names to IP addresses as requested. DNS servers run special software and communicate with each other using special protocols.

You may see a DNS server referred to by other names, such as a name server or nameserver, and a domain name system server.

The Purpose of DNS Servers

It’s easier to remember a domain or hostname like lifewire.com than it is to remember the site’s IP address numbers 151.101.2.114. So when you access a website, like Lifewire, all you have to type is the URL https://www.lifewire.com.

However, computers and network devices don’t work well with domain names when trying to locate each other on the internet. It’s far more efficient and precise to use an IP address, which is the numerical representation of what server in the network (internet) the website resides on.

The DNS server sits in the space between humans and computers to help facilitate their communication.

How DNS Servers Resolve a DNS Query

When you type a website address into your browsers address bar and press Enter, a DNS server goes to work to find the address that you want to visit. It does this by sending a DNS query to several servers, each of which translates a different part of the domain name you entered. The different servers queried are:

• A DNS Resolver: Receives the request to resolve the domain name with the IP address. This server does the grunt work in figuring out where the site you want to go actually resides on the internet.
• A Root Server: The root server receives the first request, and returns a result to let the DNS resolver know what the address of the Top Level Domain (TLD) server that stores the information about the site. A top level domain is the equivalent of the .com or .net portion of the domain name you entered into the address bar.
• A TLD Server: The DNS resolver then queries this server, which will return the Authoritative Name Server where the site is actually returned.
• An Authoritative Name Server: Finally, the DNS resolver queries this server to learn the actual IP address of the website you’re trying to deliver.

Once the IP address is returned, the website you wanted to visit is then displayed in your web browser.

It sounds like a lot of back and forth, and it is, but it all happens very quickly with little delay in returning the site you want to visit.

The process described above happens the first time you visit a site. If you visit the same site again, before the cache on your web browser is cleared, there’s no need to go through all these steps. Instead, the web browser will pull the information from the cache to serve the website to your browser ever faster.

Primary and Secondary DNS Servers

In most cases, a primary and a secondary DNS server are configured on your router or computer when you connect to your internet service provider. There are two DNS servers in case one of them happens to fail, in which case the second is used to resolve hostnames you enter.

Several publicly accessible DNS servers are available for you to use. If you want to change the DNS servers your network connects to, see our Free & Public DNS Servers List for an up-to-date listing, and How Do I Change DNS Servers?.

Why You Might Change Your DNS Server Settings

Some DNS servers can provide faster access times than others. This is often a function of how close you are to those servers. If your ISP’s DNS servers are closer to you than Google’s, for example, you may find domain names are resolved quicker using the default servers from your ISP than with an external server.

If you experience connection problems where it seems no websites will load, it’s possible there’s an error with the DNS server. If the DNS server isn’t able to find the correct IP address that’s associated with the hostname you enter, the website can’t be located and loaded.

A computer or device, including smartphones and tablets, connected to your router can use a different set of DNS servers to resolve internet addresses. These will supersede those configured on your router and will be used instead.

How to Obtain Internet Server Information

The nslookup command is used to query your DNS server on Windows PCs.

Start by opening the Command Prompt tool and then typing the following:

This command should return something like this:

In the example above, the nslookup command tells you the IP address, or several IP addresses in this case, that the lifewire.com address translates to.

DNS Root Servers

There are 13 important DNS root servers on the internet that store a complete database of domain names and their associated public IP addresses. These top-tier DNS servers are named A through M for the first 13 letters of the alphabet. Ten of these servers are in the US, one in London, one in Stockholm, and one in Japan.

The Internet Assigned Numbers Authority (IANA) keeps this list of DNS root servers if you’re interested.

Malware Attacks That Change DNS Server Settings

Malware attacks against DNS servers are not at all uncommon. Always run an antivirus program because malware can attack your computer in a way that changes the DNS server settings.

For example, if your computer uses Google’s DNS servers (8.8.8.8 and 8.8.4.4) and you open your bank’s website, you naturally expect that when you enter its familiar URL, you’ll be sent to the bank’s website.

However, if malware changes your DNS server settings, which can happen without your knowledge after an attack on your system, your system no longer contacts Google’s DNS servers but instead a hacker’s server that poses as your bank’s website. This fake bank site might look exactly like the real one, but rather than logging you into your bank account, it harvests the username and password you just typed, giving the hackers the essential information they need to get into your bank account.

Malware attacks that hijack your DNS server settings may also redirect traffic away from popular websites to ones that are full of advertisements or to a fake site designed to scare you into believing your computer has been infected with a virus, and that you must buy their advertised software program to remove it.

Don’t fall for websites that suddenly pop up with flashing warnings telling you your computer has been infected with a virus, and that you must purchase some software to get rid of it. They’re always scams.

Protecting Yourself From DNS Attacks

There are two things you should do to avoid becoming a victim of a DNS settings attack. The first is to install antivirus software so that malicious programs are caught before they can do any damage.

The second is to pay close attention to the appearance of important websites you visit regularly. If you visit one and the site looks off in some way—maybe the images are all different or the site’s colors have changed, or menus don’t look right, or you find misspellings (hackers can be dreadful spellers)—or you get an «invalid certificate» message in your browser, it might be a sign that you’re on a faked website.

How DNS Redirection Can Be Positively Used

This ability to redirect traffic can be used for positive purposes. For example, OpenDNS can redirect traffic to adult websites, gambling websites, social media websites, or other sites network administrators or organizations don’t want their users visiting. Instead, they may be sent to a page with a «Blocked» message.