|
|
 |  |
Re: Honest Base ConfigFrom: Global Homes Webmaster Date: Friday, March 10, 2000
Time: 12:06:00 amOn 03/09/00 at 17:24, Clarence Kwei wrote:
> Maybe I'm not fully understanding DNS traffic... please let me know if I'm
> off-base with this...
>
> I thought that every time a user visits your site, your DNS server gets
> queried for information. That happens only once per unique visitor since
> after the first successful query, the information is pretty much set for the
> entire session - that is future hits from the user during the session do not
> need repeated DNS queries.
Close, but not quite. Users (i.e. web browsers) should never be querying your
name server directly. When someone visits your web site, their browser asks
the name server that _their_ system is configured to use (usually their ISP's
name server or a name server on their LAN) to resolve the domain name of the
web site. If their local name server already has the relevant information
cached (from a previous look-up), it will respond to the user with the cached
info without having to send a query to your name server. If the user's name
server does _not_ already have the info cached, then it will send a query to
your name server. This is where the TTL comes into play. The TTL is the
maximum amount of time that a name server can keep a given record in its
cache.
For example, say you have a web site at www.domain.com, and the SOA record for
the domain.com. zone has a TTL of 1 day. Consider what happens when User A and
User B, who both use the same ISP, visit your site. Suppose User A makes a
visit to your site at 8:00 a.m. His browser will query his ISP's name server
to resolve 'www.domain.com'. The ISP's name server will send a query to your
name server, save the response in its cache, and send the answer to User A's
browser (User A's computer should also cache the response so that it won't
have to keep asking the ISP name server for it). Now suppose that User B
visits your site at 10 p.m. that evening. User B's browser will query the
ISP's name server to resolve 'www.domain.com'. Since the ISP name server
looked up that name earlier in the day, and the TTL (1 day) has not expired,
it will still have the answer in its cache and will not need to query your
name server. So the ISP name server will be able to send a response to User B
without any traffic to your name server.
The above is somewhat simplified, but what it boils down to is that the number
of requests your name server receives should be significantly smaller than the
number of hits your web server receives. In my example, your name server would
have received only one request for two visits to your web site. In the real
world, medium to large ISP's have name servers caching information for
hundreds or thousands of users, so the ratio of DNS queries to web hits for a
popular site could be very small indeed.
> That's one part of DNS traffic, the other part is SOA information, which I
> really don't have a clue how it works. Do the main DNS servers hit your DNS
> server according to the refresh value in your SOA record? Is it the
> Expiration or the TTL value?
I'm not sure what you mean by 'the main DNS servers.' Name servers should
cache information for no longer than the TTL value. Longer TTLs will result in
less traffic to your name server, since other servers can serve your data from
their caches for longer periods of time. What you set your TTLs to depends on
how often your DNS data changes. For a domain that's relatively stable, you'll
probably want your TTLs to be a day or two. For a domain that sees frequent
changes, you may want shorter TTLs. For a domain that's about to undergo a
one-time major change, you may want to temporarily shorten the TTL in order to
minimize your 'down-time' when the change occurs. But that's another
discussion... 8^]
The 'refresh' and 'expire' values in the SOA are used by the secondary name
servers for a given zone. The 'refresh' is how often the secondary should
check with the primary to see if the zone data it has is up-to-date. The
'expire' value is the maximum amount of time a secondary server should hold
onto data when the primary is unreachable.
Christopher Bort
|

Return to Digital Point Solutions' Home Page |