Microsoft defines the Domain Name System (DNS) as a hierarchical distributed database that contains mappings of fully qualified domain names (FQDNs) to IP addresses. DNS enables finding the locations of computers and services through user-friendly names and also enables the discovery of other types of records used for additional resources in the DNS database.
A much broader definition comes from the original Request For Comment (RFC), which was first released way back in November of 1983. RFC 882 (http://tools.ietf.org/html/rfc882) describes DNS conceptually, explaining how various components (domain name space, name servers, resolvers) come together to provide a domain name system.
As you can imagine, a number of changes have been made to the original RFC.
In fact, there have been three major RFC releases since the original debuted 25 years ago: RFC 883, RFC 1034, and RFC 1035.
As you probably came to realize by looking at the date of the original DNS RFC, Microsoft was certainly not the first company to develop DNS services. In fact, the first Unix-based DNS service was written by four college students way back in 1984. Later, the code was rewritten by an engineer at Digital Equipment Corporation (DEC) and renamed Berkeley Internet Name Domain, or BIND, as it is more commonly known. Since the original DNS code was written, it has been rewritten by several companies, including Microsoft, Novell, Red Hat, and many others.
There are various record types that can be held inside a DNS database. The record type will determine what information is provided to a DNS client requesting data. For instance, if the DNS server is configured to use an “A” record (a naming resource record), it converts an IP address to a hostname. As an example, consider using 18.104.22.168 as the IP address, and www.microsoft.com as the hostname. This would be a good example of how DNS resolution works. Another example of a record in use is the MX record. This record type is used when an e-mail server is trying to determine the IP address of another e-mail server.
Common DNS Record Types
• Host (A). Maps a domain name (such as.www.microsoft.com) to an IP address
• Canonical Name (CNAME). Maps an alias domain name to another server name
• Mail exchanger (MX). Maps a domain name to a system that controls mail flow
• Pointer (PTR). Reverses the mapping process; used to convert domain names to IP addresses
• Service location (SRV). Used to map domain names to a specific service
Regardless of the type of DNS you’re using—Microsoft, Linux, or another vendor— the DNS database holds a nearly identical format. Several components make up a DNS database.
Let’s take a moment to discuss some of the other information held in the database file.
• IN – Internet Name. This calls out that the information preceding the IN is the common name of the server. In the first line of the preceding database file, it indicates that the name at the top-left is the domain name this server supports. The names shown after the IN are the actual names of the server.
• SOA – Start of Authority. This indicates that the server is authoritative over this particular domain. Thus, it has rights to add, remove, and change records for the domain.
• 1 – Serial number. Each time a change is made to a DNS database, a new serial number is assigned. Other servers—known as secondary servers—can copy DNS databases for local storage. If this serial number changes, the secondary servers know they need to update their copy.
• 900 – Refresh Rate. How often—in seconds—the secondary computer checks to see if it needs to update its database.
• 600 – Retry. How long a secondary DNS server should wait before requesting another update, should an update fail.
• 86400 – Expire. How long a secondary server can hold a database—without update—before it must purge its records.
• 3600 – Time to Live (TTL). How long a client machine can store a requested record before it must request a refreshed record.
The worldwide DNS structure is just incredibly massive—and continues to grow on a daily basis as new domains are brought online. As large as it is, the general structure behind it is relatively simple. DNS is based on a “tree” format—and an upside-down tree, at that. At the top of the tree is the root— the root is the beginning of all DNS naming conventions and has total authority over all naming conventions beneath it. DNS Root is essentially a period—yes, a period. Technically speaking, if you decide to shop online at Elsevier’s Web site, you are shopping at “www.elsevier.com.” If that doesn’t make sense, let’s break it down. Basically, domains (and domain server names) are really read from right-to-left in the computer world. The “.” is assumed in any DNS resolution, but is still the highest level. Com would be the second-highest level, followed by another period for separation, and then Elsevier. So, in regards to DNS hierarchy, the top level domain would be “.”, followed by the second-highest level domain, which would be com, followed by the third-highest level domain, Elsevier. When combined to form an FQDN, the result would be “Elsevier.com.”
WWW represents nothing more than the name of a server that exists in the Elsevier.com domain. WWW has become commonplace for World Wide Web services, but it could just as easily be supercalafragalisticexpialidotious.elsevier.com.
The summit of the DNS namespace hierarchy is the root, which has several servers managed by the Internet Name Registration Authority (INRA). Immediately below the root are the COM, NET, EDU. Each of these domains is further divided into namespaces that are managed by the organizations that register them. For example, syngress.com is managed by a different organization than umich.edu.
Domain Suffixes Used on the Internet
.mil - United States military
.edu - Educational facilities
.com - Commercial organizations
.net - Networks
.org - Nonprofit organizations
.gov - United States government—nonmilitary
.us - United States
.uk - United Kingdom
.au - Australia
.de - Germany
Other two-letter abbreviations (.xx) Other countries
In addition to the domain suffixes shown, you will also find the occasional privately used domain suffix .local. The .local suffix is not managed by a DNS root server, so the namespace cannot be published on the Internet when you design the namespace for an Active Directory network, you can choose to use the .local suffix for domains that will not have any hosts on the Internet. Keep in mind that using the .local namespace internally will not prevent an organization from using Internet resources, such as browsing the Web.
Organizations often split the ownership of their DNS namespace. One team might be responsible for everything inside the firewall, while another team may be responsible for the namespace that faces the public. Since Active Directory often replaces Windows NT as an upgrade, the team responsible for Windows NT will often take over the DNS namespace management for Active Directory domains. Since Active Directory DNS design and implementation does differ somewhat from the standard DNS design and implementation, you can often find the two types of tasks split between two different groups in the same organization. Those are the basics on how Domain Name Services function on a much grander scale.
Source of Information : Syngress The Best Damn Windows Server 2008 Book Period 2nd Edition
One of the misconceptions about cloud storage is that it is only useful for storing files. This assumption comes from the popularity of file...
On today’s Internet, IPv4 has the following disadvantages: • Limited address space. The most visible and urgent problem with using IPv4 on ...
The following are the advantages of WAP: ● Implementation near to the Internet model; ● Most modern mobile telephone devices support WAP; ...
Many of the virus, adware, security, and crash problems with Windows occu when someone installs a driver of dubious origin. The driver suppo...