If you would like to read the next part of this article series please go to Windows Server 2012 DNS (Part 2).
Windows Server 2012 has been designed to operate more on a service-centric, rather than a server-centric, network. That is a welcome change because managing network services is even more important than managing any individual server in today’s network environment.
This first article of our network services series is dedicated to the Domain Name System (DNS). DNS is at the very heart of most enterprise networks these days. Without DNS, you wouldn’t be able to send or receive email, browse the Internet or have access to other critical services like Active Directory. It’s DNS that has made it possible for you to find and read this article online.
Why have we become so dependent on DNS? It’s a human shortcoming really: we are not that good at memorizing long numbers. It’s easier to remember a name like amazon.com rather than an IPv4 address, i.e. 206.178.205.143, or an IPv6 address, like 2000:12DC:20A7:3C48:78DA:C096:B10A:E387. The TCP/IP protocol that is used on the Internet by both corporate networks and millions of homes across the world needs those IP addresses to communicate and route network traffic. DNS provides the service that allows the translation between user-friendly names and those unfriendly IP address numbers.
Another benefit from a user standpoint is that you can use host names that do not change while the underlying IP addresses can be changed without the users having to learn the new address. With DNS they won’t notice the difference, and that is the way it should be.
The host name can be up to 255 characters long, and may include alphabetic and numeric characters, periods, and hyphens. The host name is combined with the domain name to form a Fully Qualified Domain Name (FQDN). For example, www.google.com is an FQDN where “www” is the host and “google.com” is the domain component. The Windows Server 2012 DNS can be configured to resolve FQDNs and other host names to IPv4 and IPv6 addresses.
Windows Server 2012 has added some new advanced DNS features and a new service called Internet Protocol Address Management (IPAM) that allows system administrators to manage DNS and DHCP services from a central console providing a unified view of your DNS zones and IP addressing configuration and usage.
DNS is most frequently used to:
- Resolve host names to IP addresses
- Locate domain controllers and global catalog servers
- Locate mail servers
- Resolve IP addresses to names
DNS is a client/server service that may involve hundreds of computers, starting with a user trying to reach a website from within a corporate office, going all the way to the DNS root servers on the Internet. Let’s review the name resolution process, first from the DNS client side and then on to the DNS server side.
DNS Client
If an application requires using Windows sockets and host names, Windows operating systems try to resolve the host names in the following order:
- Check to see if the host name is the same as the local host name.
- Search the DNS client resolver cache. Any entries from the hosts file are preloaded to the resolver cache.
- Send a DNS name resolution query to its configured DNS server.
The DNS client goes from one step to the next only if it cannot get the host name resolved on the previous one. If none of the preceding steps work and NetBIOS over TCP/IP is enabled, the DNS client will proceed as follows:
- Convert the host name to a single label (NetBIOS name) and check its local NetBIOS name cache.
- Contact its configured WINS server.
- Broadcast a NetBIOS name query up to three times in the local subnet.
- Search the Lmhosts file.
All Windows clients since Windows Vista, Windows Server 2008 and Windows Server 2012 support resolving names to IP addresses by using the Link-Local Multicast Name Resolution (LLMNR) protocol. LLMNR may be used in the local network to resolve names to IPv4 and IPv6 addresses when a DNS server is not configured. This protocol may be more important to provide local name resolution on IPv6 networks, as NetBIOS only works on IPv4 environments. All nodes on the local subnet must have Network Discovery turned on for LLMNR to work properly.
DNS server
When you install the DNS service on a Windows Server 2012 server, a list of the Internet root servers is preloaded by default. These servers are known as the root hints; I will talk more about them later.
Let’s follow the process of how this DNS server would handle name resolution queries from client computers and other devices.
- A user types something like www.google.com or clicks on a hyperlink for google.com on a browser.
- If the local DNS server does not know the IP address of www.google.com, it queries a root DNS server asking for the location of the .com DNS servers.
- After getting a response from a root DNS server, the local DNS server queries a .com DNS server requesting the location of the google.com DNS servers.
- Once the .com DNS server has responded, the local DNS server contacts the google.com DNS server asking for the IP address of www.google.com.
- After the google.com DNS server provides that information, the local DNS server returns www.google.com’s IP address back to the user computer to make it possible for that computer to complete a connection to www.google.com.
Not every name resolution query to a DNS server will follow the preceding steps. Caching and forwarding configuration can change how DNS servers handle the process.
Caching – Let’s say that a local DNS server goes through these 5 steps to resolve a new name to an IP address. Once the local DNS server learns that information, it caches the results for a few hours. From that point on, any new name resolution query for the same name will be served off the DNS server cache. This speeds up the name resolution process.
Forwarding – When forwarding is configured, a DNS server will forward name resolution requests to another DNS server instead of querying the root servers on the Internet. It is possible to configure conditional forwarding; a conditional forwarder is a DNS server that forwards DNS queries according to the domain name included in the query.
DNS Zones and Records
The DNS data is kept in a database that can be stored in a text file or in the active directory database when the DNS service is configured on a domain controller.
The DNS data is organized into zones; each zone is a specific portion of DNS namespace that is stored in a separate file or as a unit of replication when stored in active directory. DNS servers can host one or more zones of a particular domain. When creating an active directory domain, a corresponding DNS zone with the same name as the new domain must exist or be created during the process to ensure proper functionality of the directory services.
DNS zones contain different resource records. Resource records specify a resource type, and the IP address to locate the resource. DNS zones can resolve names to IP addresses or IP addresses to names for devices running the TCP/IP protocol like workstations, servers, routers, switches, etc.
In the case of Active Directory domain services, a special type of DNS record (SRV) is used to locate domain controllers and global catalog servers. The two types of common DNS zones configured on most DNS implementations are forward lookup and reverse lookup zones.
Forward Lookup Zones
Forward lookup zones resolve host names to IP addresses, and they answer to name queries by replying with the corresponding IP addresses that match the names in those queries.
Forward lookup zones host common resource records including IPV4 host (A), IPv6 host (AAAA), alias (CNAME), service (SRV), mail exchanger (MX), start of authority (SOA), and name server (NS) resource records. Both IPv4 and IPv6 host names can be included in the same forward lookup zone on Windows Server 2012.
Reverse Lookup Zones
Reverse lookup zones resolve IP addresses to domain names. When an IP address is part of the query, the reverse lookup zone returns the corresponding host name. Reverse lookup zones host SOA, NS, and pointer (PTR) resource records. Separate reverse lookup zones must be created for IPv4 and IPv6 on Windows Server 2012. It is possible to run a DNS infrastructure without configuring reverse lookup zones, but some important functionalities will be missing as a result and the service will generate numerous warnings and error messages.
Reverse lookup zones can be used to fight spam. Spammers use open relays (SMTP servers) on the internet to send their massive unsolicited emails and hide their identity. A mail server can perform reverse lookups to try to detect open relays; this would allow the application of traffic filtering from those open relays which can prevent or minimize unwelcome spam.
Another important benefit of reverse lookup zones is that their data is frequently used to validate forward zone information. For example, if the forward lookup specifies that support.mycompany.com is resolved to 172.16.0.8, you can use a reverse lookup to confirm that 172.16.0.8 is really associated with support.mycompany.com.
Recursive and Iterative DNS Queries
A DNS server answers recursive and iterative DNS queries. Recursive queries require a fully resolved IP address from the DNS server. These types of queries are usually originated from DNS clients to a DNS server. After receiving a recursive query, a DNS server will either respond with the corresponding IP address or generate a negative response. The DNS server will not refer the DNS client to another DNS server to continue its query.
Iterative queries are typically initiated by a DNS server after receiving a name resolution query that it cannot answer using its local database or its cache lookups. In this case, the DNS server uses an iterative query to send the same question to another DNS server. If the other DNS server has the answer, it responds with the IP address for the requested name, but if it doesn’t know the answer, it sends back a referral to the DNS servers that are accountable for the domain being queried. This process goes on until an authoritative DNS is found or a time-out condition is reached.
Root Hints and Iterative Queries
Earlier I mentioned that when installing DNS on Windows Server 2012 a list of Internet root server addresses (root hints) is preloaded by default. These root hints point to the top level DNS servers on the internet. These servers hold intelligence about the top level domains like .com, .org, .net, .edu, etc. When installing the DNS service, this information is copied from the cache.dns file which is by default located on the %windir%\system32\dns directory.
The root hint servers are not configured to respond to recursive queries, and DNS servers only send iterative queries to the root hints. This may be a little confusing for some people because to stop a DNS server from sending queries to the root hints, the option Do Not Use Recursion For This Domain must be selected. However, recursion on a DNS server and recursive queries are two different things.
When recursion is enabled on a DNS server, it means that the server may send DNS queries to its configured root hints or to other DNS servers when acting as a forwarder. Recursive queries are name resolution requests made to a DNS server in which the requester asks the DNS server to provide a complete yes or no answer. The DNS server cannot respond with a referral for the requestor to contact another DNS server.
Summary
In this article I reviewed the importance and fundamentals of DNS by sharing with you the context in which DNS operates and how name resolution queries are handled on local Windows Server 2012 DNS servers and across the Internet. In the next article, we will go over the installation and configuration of the DNS role as well as some of the advanced features available on Windows Server 2012 DNS.
This article was originally published by Intense School.
If you would like to read the next part of this article series please go to Windows Server 2012 DNS (Part 2).
Such a very detailed article. I am not that much familiar with the depths of a server. But at least, this helps me understand a little bit which I can do on my Windows.
Wow Amazing Content I like this website very much because that is providing a piece of content we really encourage thanks again and again…
very informative article. I am currently setting up my own server.