Re: Caching nameserver
From: Cameron Kerr (cameron.kerr_at_paradise.net.nz)
Date: 06/29/04
- Next message: Dan McDaid: "Re: IP Forwarding problems."
- Previous message: Nuno Paquete: "Re: IP Forwarding problems."
- In reply to: Randy Sparks: "Caching nameserver"
- Next in thread: Chris Richmond - MD6-FDC ~: "Re: Caching nameserver"
- Reply: Chris Richmond - MD6-FDC ~: "Re: Caching nameserver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 30 Jun 2004 04:59:18 +1200
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!
- Next message: Dan McDaid: "Re: IP Forwarding problems."
- Previous message: Nuno Paquete: "Re: IP Forwarding problems."
- In reply to: Randy Sparks: "Caching nameserver"
- Next in thread: Chris Richmond - MD6-FDC ~: "Re: Caching nameserver"
- Reply: Chris Richmond - MD6-FDC ~: "Re: Caching nameserver"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
