expiring secondary zones and parent delegation on Bind9

[Kevin Darcy]

Jan Gyselinck wrote:
> The following situation exists:
>
> parent zone x.com (running on company-ns-1 and company-ns-2),
> delegates child.x.com to
>
> company-ns-1
> company-ns-2
> customer-ns-1
> customer-ns-2
>
> child zone child.x.com, runs on company-ns-1 and company-ns-2, slaving
> off customer-ns-1.
>
> Now child.x.com expires on company-ns-1 and company-ns-2 after not being
> able to reach customer-ns-1 for some time.  No worries, since the
> parent also delegates to the customers' nameservers directly.  But,
> now company-ns-1 and company-ns-2 do not return the 4 ns records
> for child.x.com which are defined in x.com (it only returns SERVFAIL),
> hereby breaking child.x.com completely (delegation to customer-ns-1
> and customer-ns-2 becomes effectively 'invisible').
>
> As far as I can tell this didn't happen with bind 8.  We've recently
> upgraded to bind 9 and this issue suddenly pops up.  Should I consider
> this as normal behaviour?
>
>   
BIND 8 used to "mix glue" between parent and child zones which was a Bad 
Idea because in some cases you need those to be different temporarily. 
BIND 9 now observes a strict interpretation of glue. If you do a zone 
transfer of the parent zone, you'll still see the NS records delegating 
child.x.com, but if you do an ordinary query of child.x.com or anything 
under child.x.com, named will attempt to answer from the closest 
enclosing zone it has defined, i.e. child.x.com, and since that zone has 
expired, you'll get a SERVFAIL. Solution: remove or comment out the zone 
definition for child.x.com until the connectivity problem can be fixed.

I would disagree with the term "invisible" with reference to the current 
state of the delegation. SERVFAIL is about as *visible* a failure as you 
can possibly get. "Invisible" would be if a referral to x.com was 
returned. An ordinary user sitting in front of a browser or custom GUI 
probably isn't going to notice the difference between different kinds of 
"lookup failures", but many apps care about the distinction between "no 
such host" (which is how the referral would be interpreted) and 
"temporarily lookup failure" (SERVFAIL).

- Kevin