TTL problem wih bind 8.3.6 cache

[Jim Reid]

On Apr 29, 2005, at 07:11, Matus UHLAR - fantomas wrote:
> Are you sure that BIND will query .sk TLD nameservers for 
> opalmultimedia.sk
> NS, if it has the _authoritative_ NS record for opalmultimedia.sk?

Yes. If the targets  of the NS records for opalmultimedia.sk are inside 
that zone and their entries have expired from the server's cache, the 
server will have to query the parent zone(s) to get the addresses of 
the name servers for opalmultimedia.sk. How else would it be able to 
resolve names in this domain?

I'm not sure what you mean by "authoritative NS record for 
opalmultimedia.sk". If a server was authoritative for that NS record 
RRset, it would imply that the server was authoritative for the 
opalmultimedia.sk zone. That in turn would mean it already knew 
everything about that zone and wouldn't need to query another server to 
resolve anything in opalmultimedia.sk. Unless there were subdelegations 
of course.

If there is anything wrong, it's very likley to be a misconfiguration 
of your name servers and/or zone files. IIRC Mark told you yesterday 
that the delegation for this zone was broken because the NS target was 
a CNAME. There should have been 2 or more NS records and these would 
point at hostnames with A or AAAA records. I suggest you fix that and 
get yourself a second name server for the zone before making further 
investigations.

FYI  even though you've made some changes, the delegation for this zone 
is still broken. The sk servers say opalmultimedia .sk delegated to 
ns.opalmultimedia.sk and ns2.opalmultimedia.sk. [These have the same IP 
address, which is dumb but not illegal. The whole point of having >1 
name server for a zone is to eliminate a Single Point of Failure. 
Adding a second NS record which resolves to the same IP address just 
preserves that SPoF.] The name server for opalmultimedia .sk says the 
zone is served by opal.opalmultimedia.sk. This is  wrong: the NS record 
sets -- and any related glue --  in the parent and child zones should 
be identical.

I suspect that the behaviour you're seeing may be caused by a 
combination of a broken delegation, tinkering with the zone files and 
negative cacheing: eg the parent is delegating the zones to names that 
didn't exist in the child zone when the resolving server made the 
query. It got an NXDOMAIN response (which it's cached) and then you've 
later updated the child zone to add the missing records that were in 
the parent.

Rather than waste any more time making sense of what you might or might 
not have done, I suggest you first get the delegation for 
opalmultimedia .sk in order. Get a real slave (secondary) name server, 
ideally somewhere off-site. Fix the zone files. Then get the info in 
the parent zone corrected. Restart your name servers to be sure you've 
got rid of any cruft that may be lying about their caches. If after all 
that's been done, you still think there's a problem, post the info.