TTL problem wih bind 8.3.6 cache
Jim Reid
jim at rfc1035.com
Thu Apr 28 21:32:33 UTC 2005
On Apr 28, 2005, at 20:23, Matus UHLAR - fantomas wrote:
> It seems that BIND updates the NS record for the zone, as long as it
> came in
> AUTHORITY section, but does NOT update the A record, because it came in
> ADDITIONAL section. Then, in 38385 seconds, bind will know that
> multimedia.sk is delegated to 'opal.multimedia.sk' but won't know its
> IP
> address and thous won't be able even to find it.
>
> Can anyone tell me, if this behaviour is correct? Did I made a mistake
> somwehere? Or, where lies the main problem, except the fact that the
> domain
> really should be delegated to more servers, probably in more domains?
There is nothing wrong with BIND's behaviour in the scenario you
outlined. When the TTL for
opal.multimedia.sk expires, the name will be removed from the name
server's cache. If it is then asked for that name again, the name
server will resolve it in precisely the same way as it resolved the
name before it was in the cache. ie By iteratively querying the root
(maybe) and .sk name servers, following the delegation chain.
The difference in TTL values you showed is because you queried
different name servers. In the first examples,
you're querying a caching server. It's populating the Additional
Section of the reply with relevant data from its cache. Any TTL values
will reflect the time to live that cached data had at the moment it
was fetched from cache and put in the answer. You presumably got a
longer TTL for the MX record because this hadn't been cached so your
server had to query an authoritative server to get that answer and then
cache it. In the second examples, you're querying the authoritative
server for opalmultimedia.sk. The TTL values for names in that zone
will not change unless you modify the entries in the zone file.
And yes, your zone really should have a second name server. Please read
and follow the advice in RFC2182.
More information about the bind-users
mailing list