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
Post a Comment