I've setup a caching namerserver using Fedora Core Linux. I took the easy
route and installed the Bind RPM, along with the caching-nameserver RPM.

It works fine and "dig" proves that it's looking up addresses.

The problem is the speed at which its cached DNS records expire. If I dig,
say, google.com, it takes around 500ms to get the record. I presume this is
because it's querying the TLDs. After this, a "dig" of google.com takes
around 3ms, which I again presume is because it's cached.

So far so good. The trouble is that 10 or so minutes later, digging
google.com means a fresh TLD lookup, and another half second wait. Then
after this it's back to 3ms.

I believe that the TLDs themselves set the expiration time for each record,
but surely 10 minutes is too brief a time? Is there any way to override
this setting? Ideally I'd like records to be cached for 24 hours.

Many thanks in anticipation of any help. If anybody can recommend a good
(and preferably plain English) guide to Bind, I'd be really grateful.

On Tue, 29 Jun 2004 20:05:35 +0000 (UTC), Randy Sparks <none@none.com> wrote:
>
>
> I've setup a caching namerserver using Fedora Core Linux. I took the easy
> route and installed the Bind RPM, along with the caching-nameserver RPM.
>
> It works fine and "dig" proves that it's looking up addresses.
>
> The problem is the speed at which its cached DNS records expire. If I dig,
> say, google.com, it takes around 500ms to get the record. I presume this is
> because it's querying the TLDs. After this, a "dig" of google.com takes
> around 3ms, which I again presume is because it's cached.
>
> So far so good. The trouble is that 10 or so minutes later, digging
> google.com means a fresh TLD lookup, and another half second wait. Then
> after this it's back to 3ms.
>
> I believe that the TLDs themselves set the expiration time for each record,
> but surely 10 minutes is too brief a time? Is there any way to override
> this setting? Ideally I'd like records to be cached for 24 hours.
>
> Many thanks in anticipation of any help. If anybody can recommend a good
> (and preferably plain English) guide to Bind, I'd be really grateful.

There's a DNS howto. Starts with setting up a caching nameserver.

<quote>

1.4 Updated versions

You should be able to find updated versions of this HOWTO both at http://
langfeldt.net/DNS-HOWTO/ and on http://www.linuxdoc.org/. Go there if this
document is dated more than 9 months ago.

</quote>


AC

Randy Sparks <none@none.com> wrote:

> So far so good. The trouble is that 10 or so minutes later, digging
> google.com means a fresh TLD lookup, and another half second wait. Then
> after this it's back to 3ms.
>
> I believe that the TLDs themselves set the expiration time for each record,
> but surely 10 minutes is too brief a time?

That decision would be made by Google usually (in this case, they can
tell their registrar to specify a particular TTL for their NS and glue A
records.

Specifying short TTLs is useful for a number of reasons, but it does
come as a tradeoff to DNS server load (in this case, Google's, not yours).
Here are the common motivations for using short TTLs

* Allows the administrator to change DNS data and know that everyone
should have the new data in a reasonably short timeframe. Examples of
this could be DynDNS, so that when someones IP address changes, the A
record in the DNS system will be the old value only for a short
period of time.

Another common scenario for changing TTL value to a smaller value is
when you can know you are about to change the address of a machine
(perhaps you're moving a machine to a different provider). You
minimise the TTL so that the change can be picked up quickly, then
when you get it into its new location, you put the TTL to its
original value.

* When doing round-robin DNS for doing load-distribution of webservers,
using a shorter TTL helps to smooth out the load.

Using dig, we can see what the TTL for google.com is

$ dig google.com

;; ANSWER SECTION:
google.com. 98 IN A 216.239.57.99
google.com. 98 IN A 216.239.37.99
google.com. 98 IN A 216.239.39.99

As you can see, google is distributing the load (this may also be for
redundancy), and each query should be cached only for 98 seconds (or at
least, this is how long _my_ DNS server has left before it expires that
record. To get the original TTL, query googles DNS servers directly.

$ dig +short -t ns google.com
ns2.google.com.
ns3.google.com.
ns4.google.com.
ns1.google.com.

$ dig @ns1.google.com google.com

;; ANSWER SECTION:
google.com. 300 IN A 216.239.39.99
google.com. 300 IN A 216.239.37.99
google.com. 300 IN A 216.239.57.99

So we can see, the entries are to be cached for no longer than 300
seconds (5 minutes).

> Is there any way to override
> this setting? Ideally I'd like records to be cached for 24 hours.

You should _not_ do this. I don't believe standard Bind can rewrite data
in this anyway.

If you want to speed up lookups, I urge you to use your ISPs nameservers
as forwarders.

--
Cameron Kerr
cameron.kerr@paradise.net.nz : http://nzgeeks.org/cameron/
Empowered by Perl!

In article <40e19fe4@news.maxnet.co.nz>,
Cameron Kerr <cameron.kerr@paradise.net.nz> writes:
>If you want to speed up lookups, I urge you to use your ISPs nameservers
>as forwarders.

It seems I've seen conflicting advice here about whether or not to do this.
I too have a local bind server, and have and have not used my ISP
hosts as forwarders. Is the functionality that DNS requests get
forwarded after you determine you don't have them cached?

Why wouldn't want to do this? It does cause local downtime when the
ISP changes name server IP addresses.

What's the proper syntax again?

thx, Chris

--
Chris Richmond | I don't speak for Intel & vise versa

"Chris Richmond - MD6-FDC ~" <crichmon@filc8604.fm.intel.com> wrote in
message news:cbsp1j$mqe$3@news01.intel.com...
> In article <40e19fe4@news.maxnet.co.nz>,
> Cameron Kerr <cameron.kerr@paradise.net.nz> writes:
> >If you want to speed up lookups, I urge you to use your ISPs nameservers
> >as forwarders.
>
> It seems I've seen conflicting advice here about whether or not to do
this.
> I too have a local bind server, and have and have not used my ISP
> hosts as forwarders. Is the functionality that DNS requests get
> forwarded after you determine you don't have them cached?
>
> Why wouldn't want to do this? It does cause local downtime when the
> ISP changes name server IP addresses.
>
> What's the proper syntax again?
>
> thx, Chris
>
> --
> Chris Richmond | I don't speak for Intel & vise versa
>

I'm not sure I agree. Surely your ISPs nameservers are almost always the
fastest servers since they are normally on the closest network. Fair enough
they are down _sometimes_ but in my experience, not very often.
Maybe I am missing somthing?

Cheers
Dan

In article <cbsp1j$mqe$3@news01.intel.com>, Chris Richmond - MD6-FDC ~ wrote:
>
> It seems I've seen conflicting advice here about whether or not to do this.
> I too have a local bind server, and have and have not used my ISP
> hosts as forwarders. Is the functionality that DNS requests get
> forwarded after you determine you don't have them cached?

That is one way to set things up.

> Why wouldn't want to do this? It does cause local downtime when the
> ISP changes name server IP addresses.

It depends on how much you trust your ISP's name servers and what the
consequences will be if they are unavailable or are returning poisoned
records.