Slaves doesn't handle "expire" time correctly?

[Mark Andrews]

	Named implements sanity checks on SOA values.

                zone->refresh = RANGE(refresh,
                                      zone->minrefresh, zone->maxrefresh);
                zone->retry = RANGE(retry,
                                    zone->minretry, zone->maxretry);
                zone->expire = RANGE(expire, zone->refresh + zone->retry,
                                     DNS_MAX_EXPIRE);

	Mark

> Hi all,
> 
> I did some tests with BIND recently and I found problem with zone
> expiration:
> 
> Master: 9.5.0b1 (fec0::f101:216:3eff:fe38:dec6)
> named.conf:
> ...
> zone "lh" IN {
>         type master;
>         file "lh";
>         allow-update { none; };
>         allow-transfer { fec0::f101:216:3eff:fe4c:be9d; };
>         notify no;
> };
...
> 
> lh file:
> 
> $TTL 1D
> @       IN SOA  ns1.lh. rname.invalid. (
>                                         6       ; serial
>                                         5       ; refresh
>                                         5       ; retry
>                                         20      ; expire
>                                         5 )     ; minimum
> @       NS      ns1.lh.
> @       NS      ns2.lh.
> ns1.lh. IN AAAA fec0::f101:216:3eff:fe38:dec6
> ns2.lh. IN AAAA fec0::f101:216:3eff:fe4c:be9d
> a.lh.   A       1.1.1.1
> ---------------------------------------------------------------
> Slave: 9.3.3rc2 (I don't see any change related to this to 9.3.5b1)
>  - fec0::f101:216:3eff:fe4c:be9d
> named.conf:
> ...
> zone "lh" IN {
>         type slave;
>         file "slaves/lh";
>         masters { fec0::f101:216:3eff:fe38:dec6; };
> };
> ...
> 
> 
> When I start master and slave zone is transferred to secondary NS as
> expected. But network traces & logs shows that secondary doesn't check
> master zone every 5 seconds as it should. Also when I stop master and
> try query secondary for a.lh. record one minute after master has been
> stopped a.lh. record is all along avaliable. Could someone point me
> where will be problem?
> 
> Regards, Adam
> 
> -- 
> Adam Tkac, Red Hat, Inc.
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org