Domain Name System (DNS) is the name resolution protocol for TCP/IP networks. Client computers query a DNS server to resolve easy to remember DNS names to the IP addresses that computers use to communicate with each other. The DNS name is used to locate computers and services with user-friendly names.
The DNS is implemented as a hierarchical and distributed database containing various types of data, such as host names and domain names. The names in a DNS database form a hierarchical tree structure called the domain namespace. Domain names consist of individual labels separated by dots, for example: example.contoso.com.
A fully qualified domain name (FQDN) uniquely identifies a host position within the DNS hierarchical tree by specifying a list of names separated by dots in the path from the referenced host to the root. For example: Server1.fabrikan.co.jp.
There are five categories used to describe DNS domain names by their function in the namespace:
- Root domain
This is the top of the tree, representing an unnamed level. It is represented by a period (.) to designate that the name is located at the root or highest level of the domain hierarchy. At this point, the DNS domain name is considered to be complete and points to an exact location in the tree of names. Names stated this way are called fully qualified domain names (FQDNs).
- Top level domain
A name used to indicate a country/region or the type of organization using a name, such as .com. and .gov. or country-specific DNS addresses such as .uk. or .jp.
- Second level domain
This are names registered to an individual or organization for use on the Internet. These names can be of Variable-length and are always based upon an appropriate top-level domain, depending on the type of organization or geographic location where a name is used. For example: contoso.com.
Additional names that an organization can create that are derived from the registered second-level domain name. For example: example.contoso.com.
- Host or resource name
Typically, the leftmost label of a DNS domain name identifies a specific resource, such as a computer on the network.
The figure shows an example of the DNS hierarchical structure. At the top of the DNS hierarchy is the Root Domain. Name servers at the Root Domain contain information for all of the generic Top Level Domains such as .com or .jp. Name servers for each of the Top Level Domains contains information of the Second Level Domains within that Top Level Domain, and so on. For example, the name server for .com will contain information about contoso.com but will not contain information about fabrikan.co.jp. The figure also shows a host called Server1 within the fabrikan.co.jp. domain. The FQDN for the host would be Server1.fabrikan.co.jp.
All DNS records actually end with a dot (.) which represents the root of the DNS hierarchy, but it’s rarely printed and is usually just assumed.
DNS can be installed manually as a role, using the Server Manager, PowerShell, or with the Active Directory Domain Services Installation wizard (When promoting the server to a Domain Controller)
A DNS query is a request for DNS resource records of a specified resource record type with a specified DNS name. DNS queries can be sent from a DNS client (resolver) to a DNS server, or between two DNS servers.
There are two types of DNS queries that may be sent to a DNS server: Recursive and Iterative
With a recursive name query, a DNS server is forced to respond to a DNS client request with either the requested resource record or an error message stating that the record or domain name does not exist.
If after receiving a recursive query a DNS server does not have the requested information, the DNS server must contact (query) any other DNS servers until it gets the information, or until the name query fails.
Recursive queries are generally made by a DNS client to a DNS server, or by a DNS server configured to use a forwarder (configured to pass unresolved queries to another DNS server). A forwarder is another DNS server configured to handle requests forwarded to it.
With an iterative name query, the DNS client allows the DNS server to respond with the best answer it can give (the answer will be based on its cache or zone data).
If the DNS server processing the iterative query does not have an exact match for the query, it will respond with the best possible information it can return. This information is known as a referral, or a pointer to another DNS server authoritative for a lower level of the domain namespace. The DNS client can then query that other DNS server for which it obtained a referral. The DNS client will continue this process until it locates a DNS server that is authoritative for the queried name, or until it receives a negative response.
If a DNS server processing a recursive query cannot resolve the query, the recursive query must be escalated to a root DNS server by sending an iterative query. Standard implementations of DNS server include a cache file (or root-hints) that contains entries for the root DNS servers of the Internet domains. Note that, if the DNS server is configured to use a forwarder, the forwarder is used before a root server is used.
In the figure:
① Recursive query for http://www.contoso.com
② Query escalated to a root DNS server. Iterative query for http://www.contoso.com
③ Referral to the .com name server
④ Iterative query for http://www.contoso.com
⑤ Referral to the contoso.com name server
⑥ Iterative query for http://www.contoso.com
⑦ Answer to the iterative query from contoso.com server (www.contoso.com’s IP address)
⑧ Answer to the original recursive query from local DNS server to the client (www.contoso.com’s IP address)
Root hints contain information needed to resolve names outside the authoritative DNS domain. In other words, it contains names and addresses of Root DNS servers. By default, the DNS Server service implements root hints using a file, Cache.dns, stored in the systemroot\System32\Dns folder on the server computer.
This file normally contains the resource records for the Internet root servers (13 root servers; a.root-server.net ~ m.root-server.net). However, you can edit or replace this file with similar records. For example, if you are using a DNS Server on a private network, one way of increasing security is to avoid DNS servers to contact root servers on the internet, to do this you can delete all the resource records for the internet root servers, and add similar records that point to your own internal root DNS server.
To configure the Root hints:
- Open the DNS Manager. (On server manager click tools, then select DNS).
- Right click your server name and select properties.
- Click the Root Hints tab. From there you can Add, Edit or Remove root hints.
It should be noted that a Root server is not just one physical server. A root server is installed in a high availability cluster, and some of root hint server use anycast making them available from multiple locations.
A forwarder is a DNS server used to forward DNS queries for external DNS names to DNS servers outside of that network. A DNS server is designated as a forwarder by setting other DNS servers in the network forward queries they cannot resolve locally to that DNS server.
By using a forwarder, you can improve the security of your network. If you haven’t designated a specific DNS server as a forwarder, all DNS servers in your network can send queries outside of the network using their root hints. Therefore, internal, DNS information can be exposed on the Internet. Remember that if a DNS server is configured to use a forwarder, the forwarder is used before a root hints are used. So, when you designate a DNS server as a forwarder, that forwarder will be responsible for handling external traffic, therefore limiting the exposure of other DNS servers to the Internet. Additionally, when you configure a forwarder you have the option to prevent DNS servers from using their root hints if the forwarder is offline.
You do not need to perform any special configuration on the computer designated as a forwarder. You must configure the DNS servers that needs to forward queries by providing the IP address of the forwarder.
As I mentioned above, DNS forwarding can be set up so that if the DNS server do not receive a reply from the forwarder, the DNS server will then attempt to resolve it by using it root hints. This is called nonexclusive forwarding. On the other hand, it is called exclusive forwarding, if the DNS forwarding is set so that only the forwarder can resolve external queries (by disabling the check box; Use root hints if no forwarders are available).
When the DNS server receives a query, it attempts to resolve this query. If the query cannot be resolved using this local data, then it will forward the query to the DNS server designated as a forwarder. The DNS server will wait briefly for an answer from the forwarder before attempting to contact the DNS servers specified in its root hints (if root hints are not disable). In this case the DNS server is called slave DNS server.
You can configure a DNS to use a forwarder by commands as follow:
dnscmd <server_name> /ResetForwarders <IP_address> [/TimeOut <time>] [/Slave]
The IP address or host name of a remote or local DNS server you want to configure to use a forwarder. If this parameter is omitted, the local server is used.
Forwarder’s IP address. IP addresses to which the DNS server will forward unresolved queries.
Sets the number of seconds that the DNS server waits for a response from the forwarder. By default, this value is five seconds.
Set exclusive forwarding.
A common scenario for using forwarders you should know:
Internal DNS servers are placed on the office network, and externally accessible DNS servers (External DNS) are placed in the DMZ network. Configure all Internal DNS servers on the office network to use forwarders, and set exclusive forwarding on all of them. In this scenario the External DNS server are used as Forwarders.
The DNS namespace database can be partitioned into multiple zones. Therefore, a zone is a contiguous portion of the DNS namespace, divided for administration purposes. A zone stores name information about one or more DNS domains.
You shouldn’t confuse Zones with Domains, a zone will start as a storage for a single DNS domain name. If you add other domains below the domain where the zone was created, these domains can either be part of the same zone or belong to another zone. If you add a subdomain, the subdomain can either be included and managed as part of the original zone records, or delegated to another zone created for the subdomain.
The figure above shows the contoso.com domain. When the contoso.com domain was first created at a single server, it was configured as a single zone for all of the Contoso DNS namespace. If, later, the contoso.com domain needs to use subdomains, those subdomains must be included in the zone or delegated to another zone. In the figure, the new added subdomain example.contoso.com was delegated to a zone different from the contoso.com zone. However, the contoso.com zone needs to contain a few resource records to provide the delegation information that references the DNS servers that are authoritative for the delegated example.contoso.com subdomain. On the other hand, the subdomain dev.contoso.com was not delegated to a different zone, therefore it is managed by the contoso.com zone.
DNS server normally provides for three types of zones:
- Primary zone
Primary is a zone to which all updates for the records that belong to that zone are made.
- Secondary zone
A secondary zone is a full read-only copy of the primary zone. Any changes made to the primary zone file will be replicated to the secondary zone file.
- Stub zone
A stub zone is a read-only copy of the primary zone that contains only the resource records that identify the DNS servers that are authoritative for a DNS domain name.
Additionally, if you have installed Active Directory (AD), you will have two options for storing and replicating your zones when operating the DNS server at the new domain controller:
- Standard zone storage
Zones stored this way are located in .dns files that are stored in the systemroot\System32\dns folder on each computer operating a DNS server. Zone file names correspond to the name you choose for the zone when creating it.
- Active Directory-integrated zone storage
Zones stored this way are located in the Active Directory database
A DNS server hosting a primary zone is said to be the primary DNS server for that zone, and a DNS server hosting a secondary zone is said to be the secondary DNS server for that zone.
DNS server can host multiple zones. For example, a DNS server can host both a primary zone and a separate secondary zone. However, it should be noted that a secondary or stub zone cannot be hosted on a DNS server that hosts a primary zone for the same domain name. Also, keep in mind that two primaries zones cannot be hosted in the same DNS server. Finally, you should remember that a secondary zone cannot be and Active Directory-integrated zone.
Because of the important role of DNS zones, it is important for zones to be available in more than one DNS server on the network. For additional servers to host a zone, zone transfers are required to replicate and synchronize all copies of the zone used at each server configured to host the zone.
Therefore, zone transfer is the process of copying a zone’s data from the primary DNS server (ServerA) to the secondary DNS servers (ServerB). The secondary DNS server (ServerB) can also transfer its zone data to other secondary DNS server/s (ServerC). In this case ServerC is beneath ServerB in the DNS hierarchy, and ServerB is regarded as the master DNS server to ServerC.
When using Active Directory-Integrated Zones there is no need to create a secondary zone (therefore, this option is disable) or to perform zone transfer because Active Directory takes the responsibility for replicating the data.
With Standard zone, DNS updates are conducted based on a single-master update model (as explained above with zone transfers). In this model, a single authoritative DNS server for a zone is designated as the primary source for the zone. This server maintains the master copy of the zone in a local file. With this model, the primary server for the zone represents a single fixed point of failure. If this server is not available, update requests from DNS clients are not processed for the zone.
Active directory-integrated zones, use a multi-master update model. In this model, any authoritative DNS server, such as a Domain Controller (DC), is designated as a primary source for the zone. With AD zone transfer is not needed because the master copy of the zone is maintained in the Active Directory database; therefore, the zones are fully replicated to all DCs along with all other AD data. You can update the DNS resource records on any DNS servers operating at any DC, because AD will automatically update all other DCs. (Note: an Authoritative DNS server for a zone, is any DNS server that stores a full copy of all records in that zone).
Active Directory Database, Partitions and Zones Replication
The Active Directory database is organized in partitions, each holding specific object types and following a specific replication pattern.
Schema Partition: The data in the Schema partition is replicated to all domain controllers in the forest. Schema partition contains all object types that can be created in Active Directory. This data is common to all domains in the domain tree or forest.
Configuration Partitions: Contains replication topology and related metadata. Active Directory-aware services store information in the Configuration directory partition. This data is common to all domains in the domain tree or forest. Configuration data is replicated to all domain controllers in the forest.
Domain Partitions: Contains all of the objects in the directory for this domain. Domain data in each domain is replicated to every domain controller in that domain, but not beyond its domain. DNS zones data are stored on this partition.
From the figure you can see that in Active Directory the domain partition data is replicated only to the domain controllers within the same domain. Therefore, because Active directory-integrated zones are stored in the Domain partition, they cannot be replicated to other domains.
To overcome the limitation of the AD Integrated zones on Windows 2000, starting with Windows server 2003 there was an additional partition added to the AD database; the Application Partition. With the application partition, two additional storage locations were added specifically to store DNS data. These locations are the DomainDnsZones and ForestDnsZones Application Partitions. Now it is possible to store an AD Integrated zone in either of these new application partitions instead of the Domain partition.
If DNS data is stored in the DomainDnsZones application partition, the DNS data will be available only in that domain. If you store the DNS data in the ForestDnsZones application partition, data will be available to any DC/DNS server in the whole forest.
In Windows 2012, you can select (or change) a zone replication scope from the DNS manager, just select the Zone you want to modify, right-click on it and select Properties.
In the zone’s properties, on the General Tab, click on the Change button next to the Replication with the current zone replication type. The Change Scope Replication windows will open, there you will see 3 options:
To all DNS servers running on domain controllers in this forest: contoso.com: This option stores the zone in the ForestDnsZones Application Partition. This setting will allow the zone data to replicate to all domain controllers on every domain of the forest.
To all DNS servers running on domain controllers in this domain: contoso.com: This option means the zone is in the DomainDnsZones Application Partition. Allowing the zone to be replicated to all domain controllers within that specific domain.
To all domain controllers in this domain (for Windows 2000 compatibility): contoso.com: This option means the zone is in the Domain partition of the AD database. This is only for Windows 2000 compatibility.
Dynamic update enables DNS client to register and dynamically update their resource records with a DNS server whenever changes occur. Therefore, reducing the need for manual administration of zone records, especially for clients that change their locations frequently and use DHCP to obtain an IP address.
Dynamic updates can be sent when:
- An IP address is added, removed, or modified.
- An IP address lease changes or renews with the DHCP server.
- Manually forcing a refresh of the client name registration in DNS ( ipconfig/registerdns command).
- When the computer is turned on.
- When a server is promoted to a domain controller.
To configure Dynamic Updates on a client computer. First, access the TCP/IPv4 Properties. There, click the Advance button; the Advance TCP/IP Settings windows will open. On this windows, click the DNS tab, then check the box Register this connection’s addresses in DNS, and click OK.
To configure Dynamic Updates on a DHCP server. First, on server manager, click on Tools and then select DHCP. On the console tree, under the server name right-click Ipv4 and select Properties. On the IPv4 Properties windows select the DNS tab. Check the box Enable DNS dynamic updates according to the settings bellow:. There, you can choose between two settings:
Dynamically update DNS records only if requested by the DHCP clients: This is the default configuration for DHCP servers. In this mode, the DHCP client can request the way in which the DHCP server performs updates of its host (A) and pointer (PTR) resource records. If possible, the DHCP server accommodates the client request for handling updates to its name and IP address information in DNS. In this mode, the client registers its DNS A record, and the DHCP server registers the DNS PTR record of the client.
Always dynamically update DNS records: In this mode, the DHCP server always performs updates of the client’s FQDN, leased IP address information, and both its host (A) and pointer (PTR) resource records, regardless of whether the client has requested to perform its own updates. (The DHCP server sends updates to the DNS server for the host (A) resource record and for the pointer (PTR) resource record.)
To configure Dynamic Updates on the DNS server. Open the DNS manager, select the Zone you to modify, right-click on it and select Properties. In the zone’s properties, on the General Tab you can select 3 options on the dropdown list next to Dynamic Updates:.
None: This option disable Dynamic updates.
Nonsecure and secure: Allow dynamic updated from all DNS clients.
Secure only: This option is not available with Standard zones. It will be available only for active-directory integrated zones, and can be selected only on Domain controller DNS servers. With this option, only dynamic updated from computers that have been authenticated to the Active Directory will be allowed.
Nslookup is a command-line tool for testing, diagnosing and troubleshooting DNS servers. Normally, when you start Nslookup, first it shows the host name and IP address of the DNS server that is configured for the local system, and then display the piece of information you requested or a command prompt for further queries, depending on the mode you wish to work with.
Nslookup has two modes: interactive and noninteractive.
Use the noninteractive mode if you need to look up only a single piece of data. The syntax for noninteractive mode is:
nslookup [-option] [hostname] [server]
Use the interactive mode by invoking nslookup without arguments (just type nslookup in the command prompt). You will be presented with the nslookup prompt (>), there you can start issuing parameter configurations or requests.
Main parameters in nslookup are:
Changes configuration settings that affect how lookups function.
Shows the current values of the configuration settings
Changes the default Domain Name System (DNS) domain name to the name specified.
set [querytype] or set type
set q=<ResourceRecordType> set querytype=<ResourceRecordType> set type=<ResourceRecordType>
Changes the resource record type for the query.
As mentioned before, the DNS database consists of one or more zone files. Each zone holds a collection of resource records. Resource records contain the information that a zone maintains about the resources (such as hosts) that the zone contains. The following figure shows the types of Resource Records for the set type command.
To add a bit more of information about most common types of record:
- A record: An A record is used to find the address (IP) of a computer connected to the internet from a name: E.g. google-public-dns-a.google.com –> 188.8.131.52
- PTR record: PTR or Pointer records are used to map an IP address to a host name. These are primarily used for reverse DNS. E.g. 184.108.40.206 –> google-public-dns-a.google.com
- CNAME record: A CNAME or Canonical Name record can be used to map an alias (nickname) to the real (canonical) name. E.g. Alias -> docs.contoso.com –> documents.contoso.com <- Real name
- MX record: A MX or Mail eXchange record will redirect email sent to any user’s machine to a designated mailhost. E.g. Mail sent to user email@example.com will be delivered to server mail1.contoso.com
- TXT record: TXT or text record associates text with a host or other name. The most common uses for TXT records are Sender Policy Framework (SPF), DomainKeys (DK), and DomainKeys Identified E-mail (DKIM).
Finally I’ll finish this blog with a tip I consider important for the exam.
If when you start Nslookup, you see the following:
Default Server: Unknown
Meaning, your DNS server is still able to answer queries and host Active Directory. The resolver cannot locate the PTR resource record for the name server that it is configured to use.
To solve this, make sure that a reverse lookup zone that is authoritative for the PTR resource record exists. Also check that the reverse lookup zone includes a PTR resource record for the name server, and that the name server you are using for your lookup can query the server that contains the PTR resource record and the reverse lookup zone.