Forwarding to a Cache

[Kevin Darcy]

Kimi Ostro wrote:

>Hello,
>I little while ago I posted to the list about setting up two authorative
>servers and a caching server.
>
>My current config works, although not overly satisfied that it is "correct":
>
>cache.kimi.home's named.conf:
>options {
>  directory "/etc/namedb";
>  pid-file "/var/run/named/pid";
>  recursion yes;
>  allow-transfer { none; };
>  //allow-update { none; };
>  allow-notify { none; };
>  allow-query { none; };
>  allow-recursion { none; };
>  listen-on { 192.168.1.0/24; 127.0.0.1/32; };
>  listen-on-v6 { none; };
>  query-source address 192.168.1.210 port 5353;
>  //dnssec-enable yes;
>};
>/*
>trusted-keys {
>  include "Kkimi.home.+005+15825.key";
>};
>*/
>logging {
> channel "named_log" {
> // send most BIND logs to a dedicated log file
>  file "/var/log/named.log" versions 10 size 500k;
>  severity dynamic;
>  print-category yes;
>  print-severity yes;
>  print-time yes;
> };
> channel "query_log" {
> // query logs go to a separate file
>  file "/var/log/query.log" versions 10 size 500k;
>  severity debug;
>  print-severity yes;
>  print-time yes;
> };
> category default { named_log; };
> category queries { query_log; };
> //category lame-servers { null; };
>};
>
>view "internal.kimi.home" {
>
> match-clients { 192.168.1.0/24; 127.0.0.1/32; };
> allow-recursion { 192.168.1.0/24; 127.0.0.1/32; };
> allow-query { 192.168.1.0/24; 127.0.0.1/32; };
>
> zone "." {
>  type hint;
>  file "master/root.cache";
> };
>
> zone "localhost" in {
>  type master;
>  file "master/mst.localhost.db";
> };
>
> zone "0.0.127.in-addr.arpa" in {
>  type master;
>  file "master/mst.loopback.rv";
> };
>
> zone "kimi.home" in {
>  type forward;
>  forwarders { 192.168.1.212; 192.168.1.211; };
> };
>
> zone "8.8.10.in-addr.arpa" in {
>  type forward;
>  forwarders { 192.168.1.212; 192.168.1.211; };
> };
>
>};
>
>view "ultimate-chaos" chaos {
>
> recursion no;
>
> zone "." {
>  type hint;
>  file "/dev/null";
> };
>
> zone "bind" {
>  type master;
>  file "master/named.bind";
> };
>
>};
>
>I was wondering if it at all possible and better that the authorative name
>servers actually forward all querys to the cache that aren't from my local
>domain kimi.home?
>
>No doubt the answer will be why change what works.
>
Not quite. My answer is "try it and see". In some situations, forwarding 
opportunistically (i.e. forward "first" instead of forward "only") makes 
sense from a performance standpoint. There are a number of factors that 
play into this, but they basically boil down to cache-hit ratios, the 
reliability/performance of your forwarders, and the latency of your 
connectivity to those forwarders, relative to your latency, and their 
latency, to the Internet at large. To expand a little bit on cache-hit 
ratios: if the names you're looking up are very popular (e.g. yahoo.com, 
msn.com, google.com, chrysler.com :-) with the forwarder's other 
clients, and happen to have reasonable TTL values, then the chances of a 
particular name being in the cache are high, and when the answer comes 
from cache, from a non-overloaded nameserver, with good, non-overloaded 
network infrastructure between that nameserver and yours, then it's 
going to be fast. Sometimes cache-hit ratios can be affected by things 
like timezone, e.g. one of the forwarder's big clients is in a time zone 
1 hour ahead of yours, so their users logging on in the morning populate 
the forwarders' cache with, say, www.ebay.com, etc. entries and so the 
cache is "hot" by the time your users are logging on, and you reap the 
benefits of their query-latency times. Bear in mind that since you're 
caching locally, in addition to your forwarders caching, and since DNS 
is designed for all cache entries derived from the same lookup from an 
authoritative nameserver, to time out simultaneously, that TTL values do 
not primarily determine the cache-hit-ratio benefit you get by 
forwarding. If you're the *only* client looking up a particular name 
through a particular forwarder, for example, then it doesn't matter 
whether the TTL is set to 1 second or 1 year, your cache entry for that 
name, and the forwarder's cache entry, are going to time out 
simultaneously, so there is going to be a latency hit on the next lookup 
(obviously the TTL values are, as always, going to have a *local* impact 
in terms of the latency-versus-memory tradeoff). What is more important 
than TTLs in an absolute sense, is whether the timing and frequency of 
the forwarders' other clients' lookups, *relative* to the pertinent TTL 
values, is going to result in them taking the latency hits for you to 
populate the forwarders' cache in such a way as to speed up your 
lookups. That's going to be a highly-situational thing, something that 
is very subject to tuning and, in extreme cases, perhaps even a bit of a 
Prisoner's Dilemma (e.g. if they have a big batch job that looks up a 
bunch of domain names, and you have a similar batch job looking up many 
of the same names, and you schedule your job to follow theirs by a 
particular time increment, in order to benefit from the cache-hit ratio 
that their batch job enhances, they may eventually give up forwarding 
because it's not giving them any benefit, and you both may end up having 
to fend for yourselves).

But, more often than not, forwarding is used inappropriately, without 
the proper testing and measurement to see if it is warranted or not. 
Folks often forward for bureaucratic reasons, because of legacy 
configurations left over from a time when their Internet connectivity 
was less reliable than it is today, or simply because of bad habits or 
ignorance ("we know this configuration works, but we don't know why and 
don't want to try anything else, for fear of breaking stuff").

                                                                         
                                                         - Kevin