Skip to main content

How DNS Works ? How Query works -Recursive and Iterative Queries for DNS Server





How DNS Works ?
A DNS domain name is used in a program on the local computer. The request is then passed to the DNS Client service for resolution using locally cached information. If the queried name can be resolved, the query is answered and the process is completed.
The local resolver cache can include name information obtained from two possible sources:
  • If a Hosts file is configured locally, any host name-to-address mappings from that file are preloaded into the cache when the DNS Client service is started.
For linux /unix the file is # vi /etc/hosts
For windows :  c:\Windows\System32\drivers\etc
The file is hosts
  • Resource records obtained in answered responses from previous DNS queries are added to the cache and kept for a period of time.
  • If the query does not match an entry in the cache, the resolution process continues with the client querying a DNS server to resolve the name.
  • The cache can be cleared using the command
Ipconfig /flushdns

 

 

Querying a DNS server


The client queries a preferred DNS server from the network settings . The actual server used during the initial client/server query part of the process is selected from a global list. For more information about how this global list is compiled and updated, see Client features.
When the DNS server receives a query, it first checks to see if it can answer the query authoritatively based on resource record information contained in a locally configured zone on the server. If the queried name matches a corresponding resource record in local zone information, the server answers authoritatively, using this information to resolve the queried name.

If no zone information exists for the queried name, the server then checks to see if it can resolve the name using locally cached information from previous queries. If a match is found here, the server answers with this information. Again, if the preferred server can answer with a positive matched response from its cache to the requesting client, the query is completed.

If the queried name does not find a matched answer at its preferred server -- either from its cache or zone information -- the query process can continue, using recursion to fully resolve the name. This involves assistance from other DNS servers to help resolve the name. By default, the DNS Client service asks the server to use a process of recursion to fully resolve names on behalf of the client before returning an answer.


In order for the DNS server to do recursion properly, it first needs some helpful contact information about other DNS servers in the DNS domain namespace. This information is provided in the form of root hints, a list of preliminary resource records that can be used by the DNS service to locate other DNS servers that are authoritative for the root of the DNS domain namespace tree. Root servers are authoritative for the domain root and top-level domains in the DNS domain namespace tree.
By using root hints to find root servers, a DNS server is able to complete the use of recursion. In theory, this process enables any DNS server to locate the servers that are authoritative for any other DNS domain name used at any level in the namespace tree.
For example, consider the use of the recursion process to locate the name "host-b.example.microsoft.com." when the client queries a single DNS server. The process occurs when a DNS server and client are first started and have no locally cached information available to help resolve a name query. It assumes that the name queried by the client is for a domain name of which the server has no local knowledge, based on its configured zones.
First, the preferred server parses the full name and determines that it needs the location of the server that is authoritative for the top-level domain, "com". It then uses an iterative (that is, a nonrecursive) query to the "com" DNS server to obtain a referral to the "microsoft.com" server. Next, a referral answer comes from the "microsoft.com" server to the DNS server for "example.microsoft.com".
Finally, the "example.microsoft.com." server is contacted. Because this server contains the queried name as part of its configured zones, it responds authoritatively back to the original server that initiated recursion. When the original server receives the response indicating that an authoritative answer was obtained to the requested query, it forwards this answer back to the requesting client and the recursive query process is completed.
Although the recursive query process can be resource-intensive when performed as described above, it has some performance advantages for the DNS server. For example, during the recursion process, the DNS server performing the recursive lookup obtains information about the DNS domain namespace. This information is cached by the server and can be used again to help speed the answering of subsequent queries that use or match it. Over time, this cached information can grow to occupy a significant portion of server memory resources, although it is cleared whenever the DNS service is cycled on and off.

 

 Alternate query responses

 

The previous discussion of DNS queries assumes that the process ends with a positive response returned to the client. However, queries can return other answers as well. These are the most common:
  • An authoritative answer
  • A positive answer
  • A referral answer
  • A negative answer
An authoritative answer is a positive answer returned to the client and delivered with the authority bit set in the DNS message to indicate the answer was obtained from a server with direct authority for the queried name.

A positive response can consist of the queried RR or a list of RRs (also known as an RRset) that fits the queried DNS domain name and record type specified in the query message.

A referral answer contains additional resource records not specified by name or type in the query. This type of answer is returned to the client if the recursion process is not supported. The records are meant to act as helpful reference answers that the client can use to continue the query using iteration. A referral answer contains additional data such as resource records (RRs) that are other than the type queried. For example, if the queried host name was "www" and no A RRs for this name were found in this zone but a CNAME RR for "www" was found instead, the DNS server can include that information when responding to the client.If the client is able to use iteration, it can make additional queries using the referral information in an attempt to fully resolve the name for itself.

A negative response from the server can indicate that one of two possible results was encountered while the server attempted to process and recursively resolve the query fully and authoritatively:
  • An authoritative server reported that the queried name does not exist in the DNS namespace.
  • An authoritative server reported that the queried name exists but no records of the specified type exist for that name.

The resolver passes the results of the query, in the form of either a positive or negative response, back to the requesting program and caches the response.

If the resultant answer to a query is too long to be sent and resolved in a single UDP message packet, the DNS server can initiate a failover response over TCP port 53 to answer the client fully in a TCP connected session.

Disabling the use of recursion on a DNS server is generally done when DNS clients are being limited to resolving names to a specific DNS server, such as one located on your intranet. Recursion might also be disabled when the DNS server is incapable of resolving external DNS names, and clients are expected to fail over to another DNS server for resolution of these names.

How iteration works in DNS ?

Iteration is the type of name resolution used between DNS clients and servers when the following conditions are in effect:
  • The client requests the use of recursion, but recursion is disabled on the DNS server.
  • The client does not request the use of recursion when querying the DNS server.
An iterative request from a client tells the DNS server that the client expects the best answer the DNS server can provide immediately, without contacting other DNS servers.
When iteration is used, a DNS server answers a client based on its own specific knowledge about the namespace with regard to the names data being queried. For example, if a DNS server on your intranet receives a query from a local client for "www.google.com", it might return an answer from its names cache. If the queried name is not currently stored in the names cache of the server, the server might respond by providing a referral -- that is, a list of NS and A resource records for other DNS servers that are closer to the name queried by the client.
When a referral is made, the DNS client assumes responsibility to continue making iterative queries to other configured DNS servers to resolve the name. For example, in the most involved case, the DNS client might expand its search as far as the root domain servers on the Internet in an effort to locate the DNS servers that are authoritative for the "com" domain. Once it contacts the Internet root servers, it can be given further iterative responses from these DNS servers that point to actual Internet DNS servers for the "google.com" domain. When the client is provided records for these DNS servers, it can send another iterative query to the external Microsoft DNS servers on the Internet, which can respond with a definitive and authoritative answer.

When iteration is used, a DNS server can further assist in a name query resolution beyond giving its own best answer back to the client. For most iterative queries, a client uses its locally configured list of DNS servers to contact other name servers throughout the DNS namespace if its primary DNS server cannot resolve the query.
 
  


 

Comments

Popular posts from this blog

Password Expiry notification for the users in zimbra 8.x within 7 Days for the email users

This Script will run as cron tab daily basis and it will alert the users for whom password is going to expire within 7 days. It will also alert admin for the users for whom password expired. Kindly replace the domain.com with your own domain name and the  /opt/zimbra/postfix-2.10.3.2z/sbin/sendmail  path to the actual path of postfix #!/bin/bash #Script for zimbra password expiry email notification. # Meant to be performed as daily cronjob run as zimbra user.  # redirect output to a file to get a 'log file' of sorts. # Time taken of script; echo "$SECONDS Started on: $(date)" # Set variables: # First notification in days, then last warning: FIRST="7" LAST="3" # pass expiry in days, we are assuming passwd exiry is 150 Days POLICY="150" # Sent from: FROM="admin@domain.com" # Get all users - it should run once only. USERS=$(ionice -c3 /opt/zimbra/bin/zmprov -l gaa domain.com) #Todays date, in seconds: DATE

How to Create a Delegated Admin Account in Zimbra 8.x

How to Create a Delegated Admin Account in Zimbra 8.x. Create a File as shown below with the contents .  Replace the domain.com and helpdesk Email id with your domain and helpdesk (Delegated Admin ) Name. #vi admindelegate #!/bin/bash # $1 domain.com # $2 helpdesk zmprov ma $2 zimbraIsDelegatedAdminAccount TRUE zmprov ma $2 zimbraAdminConsoleUIComponents cartBlancheUI zimbraAdminConsoleUIComponents domainListView zimbraAdminConsoleUIComponents accountListView zimbraAdminConsoleUIComponents DLListView zmprov ma $2 zimbraDomainAdminMaxMailQuota 0 zmprov grantRight domain $1 usr $2 +createAccount zmprov grantRight domain $1 usr $2 +createAlias zmprov grantRight domain $1 usr $2 +createCalendarResource zmprov grantRight domain $1 usr $2 +createDistributionList zmprov grantRight domain $1 usr $2 +deleteAlias zmprov grantRight domain $1 usr $2 +listDomain zmprov grantRight domain $1 usr $2 +domainAdminRights zmprov grantRight domain $1 usr $2 +configureQuota zmprov g

sendmail complete cofiguration with pop3 and squirrelmail

Sendmail Introduction Sendmail implements a general purpose internetwork mail routing facility. This document explain how to install sendmail and run an email server which will send and receive mail using the SMTP protocol. An IMAP or POP3 server is required to retrieve mail using Eudora or MS Outlook. Sendmail does not offer POP3 or IMAP services. Installation Prerequisites You should have a basic knowledge of UNIX and DNS. The server should allow incoming connections to the SMTP service which will be listening on TCP port 25. The server should have a fully qualified hostname (FQDN) such as mail.example.net. The hostname should resolve to an A record. It should not be a CNAME. The MX record for the domain for which you wish to receive mail should point to the hostname of your server. There should a PTR record for the IP address of your server. Mail from your server may be rejected if there is no reverse DNS. Installing sendmail Download the sendmail