• DNS Namespace: A top-down hierarchical structure based on domain name. The entire DNS tree.
  • DNS Domains: Portion of the namespace to the right of the host name.
  • Fully QUalified Domain Names: Represents the entire name for a specific host, users can use the FQDN to get the host’s IP address.
  • Hosts and “Hosts File”: A computer on the Internet provides a specific resource is called a host. The hosts file is located in the  “%systemroot%\system32\drivers\etc”  folder. This file has a higher priority than DNS in name resolution.
  • DNS Zones: A collection of connected nodes served by an authoritative DNS name server.
  • BIND ( Berkeley Internet Name Domain project): It is a group that maintains the DNS-related software suite that runs under Linux. The most well known program in BIND is named, the daemon that responds to DNS queries from remote machines.
  • DNS records: It provides the information stored in DNS database. A and AAAA records are the main records.
  • Iterative Queries: The DNS server provides the host client with an answer or referral.
  • Recursive Queries: The DNS server provides the host client with a positive or a negative answer, no referral.
Most environments use a combination of iterative and recursive queries:
1, desktop clients and non-DNS servers perform recursive queries of DNS servers;
2,The DNS server then perform iterative queries to get the information they need to give the clients.
Introducing DNS


The DNS naming hierarchy can be described as an inverted tree with the root at the top (named “.”), top-level domains branching out from the root, and domains and subdomains branching off the top-level domains.


For example, the root of the tree has 13 DNS servers called root servers scattered about the world that keep a database of addresses of other DNS servers managing top-level domain names. These other servers, aptly named, are called top-level domain (TLD) servers. Each top-level domain has servers that maintain addresses of other DNS servers. For example, the .com TLD servers maintain a database containing addresses of DNS servers for each domain name ending with .com,


category of DNS Zones


Depending on the perspective, you can category zone in following ways:

There are two DNS zone categories that define what kind of information is stored in a zone:

  • Forward lookup zone—A forward lookup zone (FLZ) contains records that translate names to IP addresses. The zone name is based on the domain of the resource records it contains. For example, the zone name might be csmtech.local, and it might contain resource records for www, mail, db-server, vpnserver, and so forth, which are hostnames of computers in
    the domain. FLZs can contain a variety of resource record types, as discussed later in “Configuring DNS Resource Records.” Forward lookup zones are used to perform forward lookups, which resolve computer names (FQDNs) to addresses. For example, the following ping command resolves the FQDN to an IP address before the ping program can send a packet to www.csmtech.local:
    ping www.csmtech.local
  • Reverse lookup zone—A reverse lookup zone (RLZ) contains records that map IP addresses to names and is named after the IP network address (IPv4 or IPv6) of the computers whose records it contains. For example, a typical name for an RLZ might be 1.10.in-addr.arpa, and it contains records for computers in the subnet. An RLZ is queried when a net- work application has an IP address for a computer and needs the FQDN for that computer. A simple example of an application that queries an RLZ is ping, as in the following example:
    ping -a
    The -a option in the command tells ping to do a reverse lookup query. If the query is successful, ping displays the FQDN of the computer with IP address This option might be useful if you need to know where packets are coming from and all you have is the IP address of the packet’s source. For example, your DNS server is sluggish, so you begin to monitor traffic to and from this server. You find that the server is receiving queries from an unknown source.

On a Windows server, you can also choose how to store zone data, whether it’s integrated with Active Directory or as a text file:

Active Directory–integrated zone—An Active Directory–integrated zone is stored in an Active Directory partition on a domain controller and is replicated along with other Active Directory data.
Standard zone—A standard zone is stored in a simple text file that can be edited with a text editor, such as Notepad. The text file is named zone-name.dns (with zone- name typically the domain name) and is in the %systemroot%\system32\dns folder on the DNS server. Standard zones are mostly installed on stand-alone servers that need to provide name resolution services for network resources outside the domain or in net- works that don’t use Active Directory at all, such as Linux- or UNIX-based networks. In addition, standard zones are used to resolve names for Active Directory domains in other forests.

Depending on the resource record’s read/write property

Both forward and reverse lookup zones can be one of three types: primary, secondary, or stub, discussed in the following sections.

Primary Zones
A primary zone contains a read/write master copy of all resource records for the zone. Updates to resource records can be made only on a server configured as a primary zone server. A primary DNS server is considered authoritative for the zone it manages. A primary zone can be an Active Directory–integrated or a standard zone.

 If a primary zone is a standard zone, there can be only one server that hosts the primary zone, referred to as the “primary DNS server.” If a primary zone is Active Directory integrated, each DC in the replication scope of the Active Directory partition in which the zone is stored gets a copy of the zone, and changes can be made on any DC that hosts the zone, unless it’s a read only domain controller (RODC).

Secondary Zones
A secondary zone contains a read-only copy of all resource records for the zone. Changes can’t be made directly on a secondary DNS server, but because it contains an exact copy of the pri- mary zone, it’s considered authoritative for the zone. A secondary zone can be only a standard zone, not an Active Directory–integrated zone. However, a file-based secondary zone can be created on a stand-alone server or a DC. Secondary zones are sometimes used to resolve names for domain-based resources outside the domain. For example, if you have two Active Directory forests, Forest1 and Forest2, you can create secondary zones on servers in Forest2 to resolve names for domains in Forest1, and vice versa. Secondary zones are also used in environments without Active Directory, such as for Internet domains and networks that are Linux/UNIX or Mac OS based.
When you’re working with standard zones, a server that holds the primary zone is called the “master DNS server,” and servers that hold secondary zones are called “slave DNS servers.” You must configure zone transfer settings on the master DNS server that holds the pri- mary zone to allow resource records to be transferred, or copied, to one or more slave DNS servers that hold secondary zones.

Stub Zones
A stub zone is a special type of zone containing only an SOA record, one or more NS records, and the necessary glue A records to resolve NS records. A stub zone isn’t authoritative for the zone. Essentially, a stub zone points to another DNS server that is authoritative for the zone. A stub zone can be an Active Directory–integrated or a standard zone. If it’s Active Directory inte- grated, its records, as in other Active Directory–integrated zones, are updated regularly through Active Directory replication. If the stub zone is a standard zone, the SOA and NS records are updated through zone transfers.
The reasons for using stub zones include the following:
• Maintenance of zone delegation information—If changes are made to addresses of the name servers hosting a delegated zone, the NS records on the parent DNS server must be updated manually. If a stub zone is created for the delegated zone on the parent DNS server, the NS records are updated automatically. The use of a stub zone effectively eliminates manual maintenance of the delegated zone’s NS records. Delegated zones are discussed later in “Managing Zones.”
• In lieu of conditional forwarders—If changes are made to addresses of domain name servers that are conditionally forwarded, the IP addresses for the conditional forwarder records must be changed manually. If a stub zone is created instead of using a conditional forwarder, the NS records in the stub zone are updated automatically. In addition, because stub zones can be Active Directory integrated, you need to create the stub zone only once on a DC, and it’s replicated to all other DNS servers running on DCs.
• Faster recursive queries—When a DNS server receives a query for a resource record in the stub zone, it can make a recursive query by using the stub zone’s NS records instead of accessing a root server.
• Distribution of zone information—When a network consists of many zones, distribution of these zones is necessary to make the entire DNS namespace accessible throughout the net- work. Typically, this distribution requires secondary zones or Active Directory–integrated zones. Stub zones can be used strategically to reduce the number of secondary zones or full Active Directory–integrated zones; reducing the number of these zones cuts down network traffic caused by zone transfers and replication.
Type of record:
  • A (address) Maps a host name to an IP address. When a computer has multiple adapter cards or IP addresses, or both, it should have multiple address records.
  • CNAME (canonical name) Sets an alias for a host name. For example, using this record, zeta.microsoft.com can have an alias as www.microsoft.com.
  • MX (mail exchange)
    MX records are used by mail services to find the mail server for a domain. When a user writes an e-mail to mike@csmtech.local, for example, all that’s known from the e-mail address is the recip- ient name and domain name. However, the mail protocol needs the name of a host in the domain that provides mail services, which is where the MX record comes in. When an outgoing mail server, usually an SMTP server, needs to deliver an e-mail message, it performs a DNS lookup for the MX record for the domain name contained in the e-mail address. The MX record points to an A record (much as a CNAME record does).When a client queries for an MX record for the csmtech.local domain, the DNS server returns the name of the server (mail.csmtech.local) and its IP address. T
  • NS (name server)
    Specifies a name server for the domain, which allows DNS lookups within various zones. Each primary and secondary name server should be declared through this record.
    An NS record technically consists of just the name server’s FQDN, but for the name to be useful, there must be a way to resolve it to an IP address. DNS does this with a glue A record, which is an A record containing the name server’s IP address. In DNS Manager, glue records are created automatically, if possible, by a DNS lookup on the NS record’s FQDN;
  • Glue A record: an A record containing the name server’s IP address.
  • PTR (pointer):
    Creates a pointer that maps an IP address to a host name for reverse lookups.
    PTR records are used by some Web-based applications that limit their use to specific domains. When the application is accessed, a reverse lookup is performed, and the domain name of the host at- tempting to access the application is verified against the list of permitted domains. PTR records are also useful for certain applications when only the IP address is known and you want to find the hostname. For example, when you use the tracert command to map the route between your computer and a destination, each router along the way replies with its IP address. The tracert command can then do a reverse lookup to determine the router’s FQDN, which often contains information for determining where the router is located and which ISP it belongs to. PTR records are found only in RLZs.PTR records have much the same information as a host record, including a timestamp and TTL. When you create a host record, you have the option to create the related PTR record for the host automatically, as long as the RLZ already exists. In addition, you can edit an existing host record and select the “Update associated pointer (PTR) record” check box to create or up-date the PTR associated with the host.

    • If your email server with domain name frankfu.click has IP address, then the format of PTR record is:
  • SOA (start of authority)
    Declares the host that’s the most authoritative for the zone and, as such, is the best source of DNS information for the zone. Each zone file must have an SOA record (which is created automatically when you add a zone).
    • Serial number—A revision number that increases each time data in the zone changes. This
    number is used to determine when zone information should be replicated or transferred.
    • Primary server—On a primary Active Directory–integrated zone, this field displays the name of the server where DNS Manager is currently running. For a standard zone, it displays the primary DNS server’s name.
    • Responsible person—The e-mail address of the person responsible for managing the zone. A period rather than an @ sign is used to separate the username from the domain name (according to RFC 1183, which defines DNS resource record types).
    • Minimum (default) TTL—This setting specifies a default TTL value for zone data when a TTL isn’t supplied in a resource record. The TTL value tells other DNS servers and clients caching records from this zone how long they should keep cached data; this value should be adjusted according to how often data in the zone is likely to change.
  • SVR record:
    An SRV record specifies a hostname and port number for servers that supply specific services. For example, servers that provide Kerberos authentication or Lightweight Directory Access Protocol (LDAP) services can register an SRV record with a DNS server so that clients requiring these services can find them. SRV records are queried by client computers in the following format:
    For example, a client looking for an LDAP (Active Directory) server using the TCP protocol
    for the csmtech.local domain sends a query that looks like this:
    In DNS Manager, several SRV records are in the _msdcs subdomain created for every Active Directory domain.Netlogon service creates a log file that contains all the locator resource records stored in netlogon.dns, which located in %system%\system32\Netlogon.dns.

    • Domain—The name of the domain in which the service is located. This field is filled in for
      you, and you can’t change it.
      Service—Choose a service in this list. The name is prefaced with an underscore character, so the Kerberos service, for example, is listed as _kerberos. Services you can choose from are finger, FTP, HTTP, Kerberos, LDAP, MSDCS, NNTP, Telnet, and Whois.
      Protocol—The Transport-layer protocol the service uses. The choices are TCP and UDP. • Priority—The priority of this record if more than one server is providing the same service.
      Lower numbers are higher priority. The default value is 0.
      Weight—If two of the same service records have equal priority, the weight value determines which record the host should use. Unlike the priority, where the record with the highest priority (lowest value) is always used, the weight value is used more as a proportion. The higher the weight, the higher the proportion. So if there are two records with equal priority, and Record1 has a weight of 40 and Record2 has a weight of 20, Record1 is used twice as often as Record2. Records with equal weight are used equally. The default value is 0.
      Port number—This value is filled in automatically with the default port number for the selected service. However, you can change it if the service uses a nonstandard port number.
      Host offering this service—The FQDN of the host providing the service, ending with a dot.