TTL's set to 1 second

[Bell, William IT]

Thanks to everyone for their assistance.

I was pretty sure that such a low TTL was bad, but I wasn't sure if I was
overlooking something regarding DNS caching (you know how things are always
changing ;).  Now you've confirmed what I suspected.

We were never notified of this TTL change.  I just happened to notice it
while debugging some bouncing email problems (reverse lookups on our domains
are failing).  When I asked why they lowered our TTL's to 1 second, our DNS
host said they did it because we change our RR's frequently.  According to
my records, "frequently" means every 3-4 months minimum.  I'm at a loss???
:(

So I've been trying to get our DNS host to up the TTL's to something more
appropriate (like anywhere between 3 and 24 hours), but they seem unable to
handle such a request.  In fact, when they finally attempted to make the
changes (they were going to up our TTL's to 1 hour), they only updated one
of their nameservers and screwed up the serial numbers, causing a serial
number mismatch.  And to top it off, they never actually changed the TTL's;
I'm not sure what they updated.  :/

We hope to fix these problems soon, one way or another.

Thanks again for the help!
-Bill


-----Original Message-----
From: Bill Larson [mailto:wllarso at swcp.com]
Sent: Friday, January 31, 2003 6:43 PM
To: Bell, William IT
Subject: Re: TTL's set to 1 second


For a TTL of 1sec, "is this correct?".  Yes, this TTL is apparently what is
defined on your DNS server, so it is "correct".

Now, is a 1sec TTL a reasonable value for all resource records?  My response
would be an unqualified - no way!  This short of a TTL is causing all
resource
resource records involved in the lookup to NOT be cached for any significant
period of time.  This would include the "NS" records for the zone, and the
"A"
records for the name servers.  What this means is that every time someone
would query for information in your domain, they would first have to query
the
root name servers to identify the names and IP addresses of the delegated
servers for your zone.  Then they would have to query one of these servers
for
the requested information, which would finally be returned to the requesting
system.  Because the information has such a short TTL, this request process
would have to be repeated for every query.

The choice for a value for the TTL should be determined by identifying the
approximate minimum time that could be expected for changes in the data.
For
example, "NS" records along with the "A" records for the servers should be
quite static.  This means that the TTL for these records SHOULD be quite
long
(at least compared to 1 minute!).  These TTLs should be set to something
like
one day, or even longer.  Not having such a short TTL for these NS/A records
would mean that at least these repeated queries to the root servers can be
avoided.

A very short TTL, such as one minute, is only appropriate for a situation
where you really need to switch servers for every query.  This is done for
things like Yahoo and Akemi, and can be used to provide load balancing in a
cheap manner - but it is NOT appropriate for everything in a zone.

Bill Larson

"Bell, William IT" wrote:

> Hi all,
> Our internet DNS host has set the TTL's for our DNS data to 1 second.  As
I
> understand it, such a small TTL essentially causes our DNS data to not get
> cached anywhere, expiring nearly immediately after being looked up and
> cached.  This then increases the load on our authoritative DNS servers
(our
> DNS host's servers) and the network/internet because the data is never
> cached anywhere longer than 1 second.  Is this correct?
>
> Here's a query for our SOA record (with pertinent details ommitted):
>
> bash-2.03# dig @ds1.ourdnshost.com ourdomain.com SOA
>
> ; <<>> DiG 9.1.3 <<>> @ds1.ourdnshost.com ourdomain.com SOA
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3747
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;ourdomain.com.             IN      SOA
>
> ;; ANSWER SECTION:
> ourdomain.com.      1       IN      SOA     ds1.ourdnshost.com.
> support.ourdnshost.com. 2003012807 10800 3600 604800 1
>
> ;; AUTHORITY SECTION:
> ourdomain.com.      1       IN      NS      ds1.ourdnshost.com.
> ourdomain.com.      1       IN      NS      ds2.ourdnshost.com.
>
> ;; ADDITIONAL SECTION:
> ds1.ourdnshost.com.   1       IN      A       XXX.XXX.96.2
> ds2.ourdnshost.com.   1       IN      A       XXX.XXX.97.214
>
> ;; Query time: 9 msec
> ;; SERVER: XXX.XXX.96.2#53(ds1.ourdnshost.com)
> ;; WHEN: Fri Jan 31 18:08:36 2003
> ;; MSG SIZE  rcvd: 160
>
> Thanks in advance for any info.
> -BB