Dns On Windows Server 1002003 [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Dns On Windows Server 1002003 [Electronic resources] - نسخه متنی

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










2.7 Caching



The whole resolution process may seem
awfully convoluted and cumbersome to someone accustomed to simple
searches through the host table. Actually, though,
it's usually quite fast. One of the features that
speeds it up considerably is
caching.

A name server processing a recursive
query may have to send out quite a few queries to find an answer.
However, it discovers a lot of information about the domain namespace
as it does so. Each time it's referred to another
list of name servers, it learns that those name servers are
authoritative for some zone, and it learns the addresses of those
servers. At the end of the resolution process, when it finally finds
the data the original querier sought, it can store that data for
future reference, too. The Microsoft DNS Server even implements
negative caching: if a name
server responds to a query with an answer that says the domain name
or data type in the query doesn't exist, the local
name server will also temporarily cache that information.

Name servers cache all this data to help speed up successive queries.
The next time a resolver queries the name server for data about a
domain name the name server knows something about, the process is
shortened quite a bit. The name server may have cached the answer,
positive or negative, in which case it simply returns the answer to
the resolver. Even if it doesn't have the answer
cached, it may have learned the identities of the name servers that
are authoritative for the zone the domain name is in and be able to
query them directly.

For example, say our name server has already looked up the address of
eecs.berkeley.edu. In the process, it cached the
names and addresses of the eecs.berkeley.edu and
berkeley.edu name servers (plus
eecs.berkeley.edu's IP
address). Now if a resolver were to query our name server for the
address of baobab.cs.berkeley.edu, our name
server could skip querying the root name servers. Recognizing that
berkeley.edu is the closest ancestor of
baobab.cs.berkeley.edu that it knows about, our
name server would start by querying a
berkeley.edu name server, as shown in Figure 2-16. On the other hand, if our name server
discovered that there was no address for
eecs.berkeley.edu, the next time it received a
query for the address, it could simply respond appropriately from its
cache.


Figure 2-16. Resolving baobab.cs.berkeley.edu


In addition to speeding up resolution, caching obviates a name
server's need to query the root name servers to
answer any queries it can't answer locally. This
means it's not as dependent on the roots, and the
roots won't suffer as much from all its queries.


2.7.1 Time to Live


Name servers can't cache data forever, of course. If
they did, changes to that data on the authoritative name servers
would never reach the rest of the network; remote name servers would
just continue to use cached data. Consequently, the administrator of
the zone that contains the data decides on a
time to
live (TTL) for the data. The time to live is the
amount of time that any name server is allowed to cache the data.
After the time to live expires, the name server must discard the
cached data and get new data from the authoritative name servers.
This also applies to negatively cached data: a name server must time
out a negative answer after a period in case new data has been added
on the authoritative name servers.

Deciding on a time to live for your data is essentially deciding on a
trade-off between performance and consistency. A small TTL will help
ensure that data in your zones is consistent across the network,
because remote name servers will time it out more quickly and be
forced to query your authoritative name servers more often for new
data. On the other hand, this will increase the load on your name
servers and lengthen the average resolution time for information in
your zones.

A large TTL reduces the average time it takes to resolve information
in your zones because the data can be cached longer. The drawback is
that your information will be inconsistent longer if you make changes
to the data on your name servers.

But enough of this theoryI'll bet
you're antsy to get on with things. You have some
homework to do before you can set up your zones and your name servers,
though, and we'll assign it in the next chapter.


/ 163