About DNS and Windows Active Directory

What is DNS?

Ever curious about how your internet browser knows how how to get to a particular website? When you browse to a website, for example, http://technet.microsoft.com, the name has to be resolved to its server's numerical IP address, 207.46.172.248, because
computers communicate by using an IP address. Humans prefer to use website names for the obvious reason, names are easier to remember than a string of numbers.

DNS is used to map resource names to their corresponding IP address in order to communicate with TCP/IP networking equipment. You can think of DNS as being like a "phone book". DNS integration with Windows Server 2008 and Active Directory has the advantages of being able to utilize both Windows security and networking services.

DNS stands for Domain Name System and was invented by Dr. Paul V. Mockapetri in 1983, in the early Internet, ARPAnet. DNS names are created in a hierarchical, distributed database, called a domain namespace, grouped into different levels of domains. Below, is a brief history of DNS taken from http://en.wikipedia.org/wiki/Domain_Name_System#History,

At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and wrote the first implementation. The original specifications were published by the Internet Engineering Task Force in RFC 882 and RFC 883, which were superseded in November 1987 by RFC 1034^[3] and RFC 1035.^[5] Several additional Request for Comments have proposed various extensions to the core DNS protocols.

In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou—wrote the first Unix implementation, called The Berkeley Internet Name Domain (BIND) Server.^[8] In 1985, Kevin Dunlap of DEC significantly re-wrote the DNS implementation. Mike Karels, Phil Almquist, and Paul Vixie have maintained BIND since then. BIND was ported to the Windows NT platform in the early 1990s.

BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in use on the Internet.^[9] With the heavy use and resulting scrutiny of its open-source code, as well as increasingly more sophisticated attack methods, many security flaws were discovered in BIND^{[citation needed]}. This contributed to the development of a number of alternative name server and resolver programs. BIND version 9 was written from scratch and now has a security record comparable to other modern DNS software.^{[citation needed]}

The DNS Hierarchy

DNS names are resolved by starting at the root domain, which is really a dot, a null label (not included when referencing the name) located after the technet.microsoft.com. The namespace is an inverted tree structure, and the name is resolved by starting at the root, going from right to left.

The top-level domain (TLD), .com, .net, .org, .gov, .mil, .edu, and such have name servers highly regulated by the Internet Society (ISOC). Country regions also have TLDs, like .us, .ca, .uk, .au, and .za. The second-level domain, microsoft, for example, is normally an organization or country region. Second-level domains can be further sub-divided up to 127 levels.

The host name in the above example is technet, the individual computer name within the domain.

Every computer is identified by its FQDN - fully qualified absolute domain name in the hierarchical DNS tree structure. Each node or level in the DNS hierarchy is a boundary representing the responsibility of some delegated authority.

DNS Zones

In order to resolve queries for an IP address of another computer, the DNS server has a database, called a  zone. A zone supports resolution for a distinct portion of the DNS namespace.

There can be one or more domains in each zone. The server hosting a domain zone is authoritative for that domain, responsible for naming and mapping the domains within that zone.

Subdomains
A domain can include subdomain(s). The DNS server is authoritative for the subdomains and includes all records necessary to support resolution for the subdomain.

A delegation links to a subdomain. A delegation is created by a NS record that points to a name or IP address of an authoritative name server for the subdomain. The NS records are created automatically when you create the delegation. However, if you need to change the IP addresses or names of the namespace servers, you must update the NS records manually.

A delegation is done if the namespace is divided up for management purposes. Sometimes an organization may want to delegate part of the namespace to another department or section of the company. 

The namespace may need to be divided up to distribute traffic more evenly among servers to improve performance, or for zone replication. Each new zone that is created needs delegation records in other zones pointing to the authoritative name servers to process referrals.

A Stub zone is a copy of a zone whose sole function is to contain a list of authoritative name servers for that zone. A Stub zone resolves names between separate DNS namespaces. 

The Stub zone is similar to a delegation, however the NS records are updated automatically in the parent zone. The Stub zone consists of the SOA records, the NS records, and the glue A resource records for the delegated zone, along with the IP address of the master server.

The Stub zone is hosted from another DNS. http://technet.microsoft.com/en-us/library/cc779197(WS.10).aspx contains a more detailed description about Stub zones. A Stub zone keeps a DNS server hosting a parent zone aware of the authoritative name servers for its child zones. Use stub zones to:

1. Keep delegated zones current
2. Improve name resolution by enabling the DNS server to perform recursion using the Stub zone's list of name servers, so as not to have to query the internet or the internal root servers.
3. Simplify DNS administration

Resource Records?

Zones are the administrative portion of the DNS namespace and each zone contains different DNS record types or resource records. If a domain has two zones on different name servers, each one has resource records containing pointers to the other one. Some types of DNS record types are:

• Address records (A or AAAA): or host records, A record resolves a name to an IPv4 IP address record, AAAA records resolve a name to an IPV6 IP address. 
• Alias or Canonical Name (CNAME): maps an alias to the Address record. The CNAME allows you to have more than one name associated with a single IP address. You only have to manually change one record when the server's IP address is changed. For example, sometimes you may have more than one service resolving to the same IP address of your server, such as an ftp or a web service on the same machine. A common example is when you use a web address, such as pcrepairnorthshore.com, to resolve to the A record, www.pcrpairnorthshore.com. Or, the CNAME is useful when you want to change the name and you need to temporarily provide access to both the new name and the old name.
• Mail Exchange (MX): points to an e-mail server for email messaging for the domain
• Name Service (NS): contain the authoritative DNS servers in the domain. You can do a NS lookup to find out who is hosting your domain. The NS record has a pointer to the name or IP address of a subdomain's name server, and is created automatically when you create a delegation in Active Directory. If you need to change the names or IP addresses of the name servers, then you have to update the NS records manually.
• SRV Service Locator Records: allow DNS clients to locate TCP/IP based services, resolves a query for a network service, such as Active Directory domain controllers.
• PTR Records: When you add an A or AAAA resource record, there is an option to automatically create a pointer (PTR) record. The PTR record is for mapping a reverse DNS domain name based on the IP address of the computer that points the DNS name of the computer.

Management of Resource Records
Resource records can be maintained manually or dynamically. Only an administrator can do manual updates.

Dynamic updates can be enabled so that systems can register their own DNS records. Dynamic updates reduce the management overhead because clients can add, delete, and update their own resource records.


Dynamic updates are good for clients who use Dynamic Host Configuration Process (DHCP) to obtain an IP address and move regularly. 


Windows Server 2008 DNS Server supports secure dynamic updates and can be set using DNS Manager. Clients have to be authenticated to the domain to make an update to the zone, and clients can only update the DNS records that they own.

A computer that is configured to use Dynamic Host Configuration Protocol (DHCP) to obtain IP addresses can automatically register its IP address and Domain Name System (DNS) name with the DNS server that is authoritative for the zone that hosts its domain. This eliminates the need for an administrator to manage host (A or AAAA) resource records for client computers. Problems with automatic registration do not prevent a computer from accessing the network, but they can prevent other network computers from being able to locate the computer.

Event ID 11162 — DNS Client Registration 
Example: Suppose an application server configured to use DHCP just moved from one branch office to another branch office. The network was initially down at the destination office when the move was made. The users in the new branch office can access the application server by name or IP address, but the users in the other branch offices cannot access the application server by name, but can ping the client computer by its IP address. You need to make the application server available to all network users as quickly as possible and you don't want to interrupt service to the users already connected to the application server:


Run ipconfig /registerdns at the application server. Because the link was down initially, there server most likely had not updated its DNS information. The ipconfig command will force the server to register itself in the DNS database with its new IP address and is the fastest way to correct the problem without interfering with users already connected to the server.

Secure Dynamic Updates help to reduce the possibility of spoofing. When a zone has dynamic updates, there is a possibility of spoofing. Spoofing is when a hacker creates a rogue record that points to a Web server other than the correct one for that particular domain.

DNS Client Resolver
When a client application like Internet Explorer, needs to connect to a host such as technet.microsoft.com, the host name is passed to the DNS Client service. DNS first checks the DNS resolver cache on the local client. The DNS resolver cache is preloaded with the HOSTS file located at %systemroot%\system32\drivers\etc\hosts) when the cache is initialized at system startup and when the HOSTS file is modified. If the name is resolved, it is added to the cache. The resource record (RR) has a time-to-live (TTL) value. The TTL indicates how long the record stays in the cache and the record is removed when the TTL is reached. The following are useful commands for troubleshooting DNS:

• Use ipconfig /displaydns command to check the contents of the local DNS resolver cache.
• Use ipconfig /flushdns command to flush the cache and reload it with the contents of the HOSTS file. If the DNS server's response is negative, the negative response is also cached. Once the negative response is cached, future queries will fail until the negative response is removed from the cache. This is a good time to use the ipconfig /flushdns command to force the client to flush the cache and reload with the contents of the HOSTS file, and re-query the DNS server.
• Use the nslookup.exe command to query the DNS server directly, and bypass the cache.

Recursive Query
A recursive query is when a client queries DNS and the DNS server processes the query in an attempt to resolve it and return a response that is definitive. If the DNS server has no cache, the server queries the root DNS servers. The DNS server has a list of the root servers in its "root hints".

The DNS server sends the root DNS server an iterative query for technet.microsoft.com, as an example, to get the best response. The server parses the full name and sees that it needs the "com" server for the TLD for a referral to microsoft.com. Next, a referral comes from the "microsoft.com" server for the "technet.microsoft.com" server. When the DNS server for "technet.microsoft.com" is contacted, the server responds authoritatively back to the original server that initiated the recursion.

Over time, the DNS server builds up a cache to speed up the query process, even though the process above is resource intensive.

Below, is Microsoft's description of how DNS works. This is the best explanation I have found on this complicated subject. Let me here your feedback!

Reviewing DNS Concepts

Updated: April 11, 2008

Applies To: Windows Server 2008, Windows Server 2008 R2

Domain Name System (DNS) is a distributed database that represents a namespace. The namespace contains all of the information needed for any client to look up any name. Any DNS server can answer queries about any name within its namespace. A DNS server answers queries in one of the following ways:

• If the answer is in its cache, it answers the query from the cache.
• If the answer is in a zone hosted by the DNS server, it answers the query from its zone. A zone is a portion of the DNS tree stored on a DNS server. When a DNS server hosts a zone, it is authoritative for the names in that zone (that is, the DNS server can answer queries for any name in the zone). For example, a server hosting the zone contoso.com can answer queries for any name in contoso.com.
• If the server cannot answer the query from its cache or zones, it queries other servers for the answer.

It is important to understand the core features of DNS, such as delegation, recursive name resolution, and Active Directory–integrated DNS zones, because they have a direct impact on your Active Directory logical structure design.

For more information about DNS and Active Directory Domain Services (AD DS), see DNS and AD DS.

Delegation

For a DNS server to answer queries about any name, it must have a direct or indirect path to every zone in the namespace. These paths are created by means of delegation. A delegation is a record in a parent zone that lists a name server that is authoritative for the zone in the next level of the hierarchy. Delegations make it possible for servers in one zone to refer clients to servers in other zones. The following illustration shows one example of delegation.

The DNS root server hosts the root zone represented as a dot ( . ). The root zone contains a delegation to a zone in the next level of the hierarchy, the com zone. The delegation in the root zone tells the DNS root server that, to find the com zone, it must contact the Com server. Likewise, the delegation in the com zone tells the Com server that, to find the contoso.com zone, it must contact the Contoso server.

This system of zones and delegations creates a hierarchical tree that represents the DNS namespace. Each zone represents a layer in the hierarchy, and each delegation represents a branch of the tree.

By using the hierarchy of zones and delegations, a DNS root server can find any name in the DNS namespace. The root zone includes delegations that lead directly or indirectly to all other zones in the hierarchy. Any server that can query the DNS root server can use the information in the delegations to find any name in the namespace.

Recursive name resolution

Recursive name resolution is the process by which a DNS server uses the hierarchy of zones and delegations to respond to queries for which it is not authoritative.

In some configurations, DNS servers include root hints (that is, a list of names and IP addresses) that enable them to query the DNS root servers. In other configurations, servers forward all queries that they cannot answer to another server. Forwarding and root hints are both methods that DNS servers can use to resolve queries for which they are not authoritative.

Resolving names by using root hints

Root hints enable any DNS server to locate the DNS root servers. After a DNS server locates the DNS root server, it can resolve any query for that namespace. The following illustration describes how DNS resolves a name by using root hints.

In this example, the following events occur:

1. A client sends a recursive query to a DNS server to request the IP address that corresponds to the name ftp.contoso.com. A recursive query indicates that the client wants a definitive answer to its query. The response to the recursive query must be a valid address or a message indicating that the address cannot be found.
2. Because the DNS server is not authoritative for the name and does not have the answer in its cache, the DNS server uses root hints to find the IP address of the DNS root server.
3. The DNS server uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. An iterative query indicates that the server will accept a referral to another server in place of a definitive answer to the query. Because the name ftp.contoso.com ends with the label com, the DNS root server returns a referral to the Com server that hosts the com zone.
4. The DNS server uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso.com zone.
5. The DNS server uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. The Contoso server finds the answer in its zone data and then returns the answer to the server.
6. The server then returns the result to the client.

Resolving names by using forwarding

Forwarding enables you to route name resolution through specific servers instead of using root hints. The following illustration describes how DNS resolves a name by using forwarding.

In this example, the following events occur:

1. A client queries a DNS server for the name ftp.contoso.com.
2. The DNS server forwards the query to another DNS server, known as a forwarder.
3. Because the forwarder is not authoritative for the name and does not have the answer in its cache, it uses root hints to find the IP address of the DNS root server.
4. The forwarder uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Because the name ftp.contoso.com ends with the name com, the DNS root server returns a referral to the Com server that hosts the com zone.
5. The forwarder uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso.com zone.
6. The forwarder uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. The Contoso server finds the answer in its zone files, and then returns the answer to the server.
7. The forwarder then returns the result to the original DNS server.
8. The original DNS server then returns the result to the client.

This link is another good description of How DNS query works