expiring secondary zones and parent delegation on Bind9
kcd at daimlerchrysler.com
Sat May 5 02:13:50 UTC 2007
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
> 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).
More information about the bind-users