Mark(_dot_)Andrews(_at_)isc(_dot_)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.
It does not.
(2) My software doesn't allow that configuration.
Well as we keep pointing out your software is BROKEN.
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.
But the parent version *IS* a exact copy in both of the
senarios given. Just because it is not what is in the *old*
copy of the child zone doesn't make it not a exact copy.
(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.
Which is a problem in your software as it is a problem in BIND4
and BIND 8.
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.
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
--
to unsubscribe send a message to
namedroppers-request(_at_)ops(_dot_)ietf(_dot_)org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:
Mark(_dot_)Andrews(_at_)isc(_dot_)org