Mark.Andrews@isc.org writes:
> Server 1 master for example.com and slave for division.example.com.
[ and division.example.com decides to change its NS records: ]
> You receive email with the new delegation information. You update
> example.com
Your hypothetical scenario breaks down here, for two reasons:
(1) That configuration violates RFC 1034.
(2) My software doesn't allow that configuration.
Consequently, your claims of failure have no connection to reality. The
situation simply doesn't occur. (What actually happens is that the NS
record is updated when the child zone is transferred, as it should be.)
In more detail:
(1) RFC 1034, sections 4.2.1 and 4.2.2, make crystal clear that the
NS record for division.example.com is supposed to be exactly the
same in the example.com zone and the division.example.com zone.
(2) When my software is handling both zones, it enforces the RFC 1034
requirement, by unifying the data for the two zones. There isn't
a division.example.com NS record in the example.com zone separate
from the same NS record in the division.example.com zone.
I realize that, in BIND, there are two independent disk files with the
two zones, so it's possible to separately change the NS record in the
division.com zone. But that violates RFC 1034, and my software simply
doesn't allow it.
You're going to have to learn that the protocol is not defined by BIND's
implementation decisions. If you persist in viewing everything through
the language of BIND's configuration files, you're going to keep making
false claims about the behavior of other DNS software. I strongly
recommend that you read the specifications of the standard DNS protocol,
specifically RFC 1034 and RFC 1035, before you comment further.
---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago