TTL problem wih bind 8.3.6 cache

[Matus UHLAR - fantomas]

Hello,

please, don't treat me as that big lamer as I might look like.
I know about all inconsistencies and errors that are in the delegation of
the given domain, and I already sent a note to our customer to fix it.

But I found that there is probably different problem that might cause
problems, if domain is delegated only to servers in the same domain.

> 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?

On 29.04 19:43, Jim Reid wrote:
> 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?

Some time ago I've read that it might be a problem, if NS record for
particular zone has longer TTL than its destinations.
It's mentioned here:
http://marc.theaimsgroup.com/?l=bind-users&m=107695360714375&w=

<CITE>
Let's say that you have an 1800
second TTL on the A records for ns1.example.com and ns2.example.com,
the 2 NS records for example.com.  Let's say you try to get the MX
record for example.com after the 1800 seconds has passed, but before
the 3600 second TTL you gave to your NS record.  If this happens, the
DNS resolver knows to go to ns1.example.com and ns2.example.com, but
it now can't get to them.  The problem is that to get the A record for
ns1.example.com and ns2.example.com, the DNS resolver must go to the
NS records for example.com -- but, it can't get to them without the A
record, and you're stuck in a loop.
</CITE>

If this is a still problem for bind 8.3.6, then I encountered the problem:

opalmultimedia.sk.      38400   IN      NS      opal.opalmultimedia.sk. 
opal.opalmultimedia.sk. 38385   IN      A       195.168.11.130

and between expiration of those two, server will only know which server the
domain is delegated to, but not the servers' IP address.

> 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.

I mean the records above, that were received with 'AA' flag set.

They were fetched from authoritative source, so they should overwrite glue
records fetches from .sk domain. (and it seems they did).

[deleted]

After checking different nameserver (ns2.dialteelcom.sk) with different bind
version, it gives different behaviour. It does NOT overwrite old "NS" record
with the new one, so it does NOT show different TTL, unlike bind 8.3.6 on
rns3 and bind 9.2.1 

uhlar at fantomas% dig any opalmultimedia.sk @ns2.dialtelecom.sk

;; ANSWER SECTION:
opalmultimedia.sk.      86400   IN      NS      ns2.opalmultimedia.sk.
opalmultimedia.sk.      86400   IN      NS      ns.opalmultimedia.sk.

;; AUTHORITY SECTION:
opalmultimedia.sk.      86400   IN      NS      ns2.opalmultimedia.sk.
opalmultimedia.sk.      86400   IN      NS      ns.opalmultimedia.sk.

- This shows that ns2.dialtelecom.sk does have NO evidence of
opalmultimedia.sk domain.

uhlar at fantomas% dig www.opalmultimedia.sk @ns2.dialtelecom.sk

;; ANSWER SECTION:
www.opalmultimedia.sk.  38400   IN      CNAME   opal.opalmultimedia.sk.
opal.opalmultimedia.sk. 38400   IN      A       195.168.11.130

;; AUTHORITY SECTION:
opalmultimedia.sk.      38400   IN      NS      opal.opalmultimedia.sk.

- these records of opalmultimedia.sk were fetched from authoritative source
and stored into the cache.

uhlar at fantomas% dig mx opalmultimedia.sk @ns2.dialtelecom.sk

;; ANSWER SECTION:
opalmultimedia.sk.      38400   IN      MX      16 opal.opalmultimedia.sk.

;; AUTHORITY SECTION:
opalmultimedia.sk.      38394   IN      NS      opal.opalmultimedia.sk.

;; ADDITIONAL SECTION:
opal.opalmultimedia.sk. 38394   IN      A       195.168.11.130

- A-HA. the 'MX' record was fetched, but the 'NS' record was NOT updated,
and the old record remains - the TTL is the same as for the 'A' record.

Remember that rns3 returned different times after the same query:

opalmultimedia.sk.      38400   IN      NS      opal.opalmultimedia.sk. 
opal.opalmultimedia.sk. 38385   IN      A       195.168.11.130


It seems that BIND behaviour changed between version 9.2.1 (that updated the
NS record) and the version running on ns2.dialtelecom.sk (fpdns says: BIND
9.2.3rc1 -- 9.4.0a0)

I was trying to find this change in changelog, but ithout luck,
could anyone point me to place where I could find bug reports?
(if there is one). 

Thank you.
-- 
Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.