How can I increase the TTL for the cached entries in my local dns serveder?

Fri Mar 28 07:02:53 UTC 2014

On Thu, Mar 27, 2014 at 11:09 PM, Hongyi Zhao <hongyi.zhao at gmail.com> wrote:

> Hi all,
>
> Currently, I use bind9 as the local dns cache server and a forwarder only
> server.
>
> I set the dnscrpyt-proxy running on local port 50 as the upstream dns
> server  for my bind9 dns cache server.
>
> In addtition, I also want to have long TTL so that I can obtain a short
> inquiry respond time.
>
> For all of the above purposes, I use the following configure file:
>
> -------------------
> $ cat /etc/bind/named.conf.options
> options {
>     directory "/var/cache/bind";
>
>     // If there is a firewall between you and nameservers you want
>     // to talk to, you may need to fix the firewall to allow multiple
>     // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
>
>     // If your ISP provided one or more IP addresses for stable
>     // nameservers, you probably want to use them as forwarders.
>     // Uncomment the following block, and insert the addresses replacing
>     // the all-0's placeholder.
>
>     // forwarders {
>     //     0.0.0.0;
>     // };
>
>         forward only;
>         forwarders {127.0.0.1 port 50 ;} ;
>
>         cleaning-interval 1440;
>     max-cache-ttl 2419200;
>     max-ncache-ttl 86400;
>     max-cache-size unlimited;
>     stacksize unlimited;
>     datasize unlimited;
>     coresize unlimited;
>
>
> //========================================================================
>     // If BIND logs error messages about the root key being expired,
>     // you will need to update your keys.  See
> https://www.isc.org/bind-keys
>
> //========================================================================
> //    dnssec-validation auto;
>
>     auth-nxdomain no;    # conform to RFC1035
>     listen-on-v6 { any; };
> };
> -----------------------
>
> Then I restart my dns server with the followoing command to let the above
> config take in effect:
>
> sudo service bind9 restart
>
> But, I still have low TTL, because I've tried that the following command:
>
> ----------------
> werner at debian:~$ dig ssh.sshcenter.info
>
> ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> ssh.sshcenter.info
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 676
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;ssh.sshcenter.info.        IN    A
>
> ;; ANSWER SECTION:
> ssh.sshcenter.info.    60    IN    CNAME    c-ssh.cloudkvm.net.
> c-ssh.cloudkvm.net.    60    IN    A    23.226.226.124
> c-ssh.cloudkvm.net.    60    IN    A    69.197.147.93
> c-ssh.cloudkvm.net.    60    IN    A    96.44.134.231
> c-ssh.cloudkvm.net.    60    IN    A    107.150.4.170
> c-ssh.cloudkvm.net.    60    IN    A    162.211.227.83
> c-ssh.cloudkvm.net.    60    IN    A    173.254.237.179
> c-ssh.cloudkvm.net.    60    IN    A    192.3.23.197
> c-ssh.cloudkvm.net.    60    IN    A    192.161.175.143
> c-ssh.cloudkvm.net.    60    IN    A    192.227.161.20
> c-ssh.cloudkvm.net.    60    IN    A    199.119.224.224
> c-ssh.cloudkvm.net.    60    IN    A    199.233.236.200
> c-ssh.cloudkvm.net.    60    IN    A    23.90.4.124
> c-ssh.cloudkvm.net.    60    IN    A    23.92.50.22
> c-ssh.cloudkvm.net.    60    IN    A    23.94.104.29
>
> ;; Query time: 1208 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fri Mar 28 14:04:01 2014
> ;; MSG SIZE  rcvd: 292
> --------------------
>
> Though in above query, the query time is 1208 msec, if I immediately do
> the second query, the query time will be dramtically shorttened.  But after
> several minites, I will still obtain a long  query time as the above one.
> The OS used by me is Debian GNU/Linux 7.4 (wheezy).
>
> Any hints on this issue?
>
> Regards
> --
> Hongyi Zhao <hongyi.zhao at gmail.com>
> Xinjiang Technical Institute of Physics and Chemistry
> Chinese Academy of Sciences
> GnuPG DSA: 0xD108493
>
>
TTL is specified in the RR  that you get back from the remote server.. That
time is both the default and the maximum TTL for data placed into cache.
Lengthening TTL beyond the value in the RR violates the specification and
potentially badly breaks DNS. If an RR response says that the TTL is 1
minute, you can shorten it, but you cannot increase it. That is why all of
the parameters are maximum times.

Of course, this will result in your server re-querying an authoritative
server after the TTL has expired and this will take longer, but holding
data longer than the TTL can (an often does) result the wrong data. For
example, if a server is about to move to a new address, it is normal to
decrease the TTL to a very small value so that the old address will not be
used after the server is moved. Not honoring this TTL will result in
attempts to access the wrong address which probably will result in a
failure, but may result in getting old data. from a system that is no
longer updating.

Also beware of using too great an ncache TTL. This is the time to wait to
retry querying after an authoritative failure (NDOMAIN). It is to prevent
flooding a server with queries that will always fail until something
changes. Should a link be created before the server it points to is up, the
time to wait before bothering to ask again is the ncache time. One day is
very, very long. Times like 1 minute are more appropriate, but again, this
is a maximum, so the large value may not be an issue.

Sorry.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140328/e0d977c2/attachment-0001.html>