$TTL issue?

[Kevin Darcy]

Well, first of all, whether or not your own master zones are loading properly
shouldn't really affect your nameserver's ability to resolve name in other
domains (unless you're doing something strange like "mirroring" the Internet
root zone).

Moreover, as you said, in the absence of a $TTL directive, BIND should be using
the SOA negative caching TTL as the default TTL.

I would look elsewhere for the cause. Check the logs. Turn on debugging.


- Kevin

Borgia Joe A Contr AFRL/IFOS wrote:

> And to make matters worse...it seems like sporadically, the secondary
> DNS server loses the ability to resolve domains that the primary still
> can resolve.
>
> What would cause this?
>
> -----Original Message-----
> From: Borgia Joe A Contr AFRL/IFOS [mailto:Joe.Borgia at rl.af.mil]
> Sent: Tuesday, February 20, 2001 8:53 AM
> To: 'comp-protocols-dns-bind'
> Subject: $TTL issue?
>
> We had a mail issue over the weekend such that gradually, domains seemed to
> stop resolving
> properly. Domains like aol.com, prodigy.com, earthlink.net...and so on. Many
> of the big name
> domains anyway.
>
> At the end of last week, we upgraded a couple of our servers to 8.2.3.
> Because the folks
> here are using some automated tools, utilizing Oracle to manage their
> tables, I was not able
> to add the $TTL line to the top of each zone file as it wants. So, BIND told
> me that it was going
> to use the SOA minimum instead.
>
> That seemed fine to me, since it looks like the SOA minimum is the same as
> what I would have
> set the $TTL to anyway.
>
> When I got in this morning, I tried a couple of nslookups, and sure enough,
> these domains would
> not resolve. Once I restarted named on each, and did my nslookups again,
> these domains reappeared
> again.
>
> I was wondering if this $TTL line being missing from zone files could be the
> culprit in this case.
>
> Regards,
> Joe