Re: Extra records in zone transfers

[Masataka Ohta <[e-mail]>]

Dan;

> > "supposed to be" is not a protocol standard but a best current practice.
> 
> False. Please read RFC 1034. The paragraph that I cited says, among
> other things, that the non-authoritative NS records in the parent zone
> should be ``exactly the same as the corresponding RRs in the top node of
> the subzone.'' The current cs.princeton.edu NS records flunk this test.

"should be" is not a protocol standard but a best current practice.

RFC 1034 says:

: 4.3.5. Zone maintenance and transfers
: 
: Part of the job of a zone administrator is to maintain the zones at all
: of the name servers which are authoritative for the zone.

The fundamental property of distributed database is that there will
be some inconsistencies.

Accept it.

> The problem is that this document, in violation of RFC 2119 section 6,
> imposes requirements that aren't needed for interoperability. If I'm
> transferring both princeton.edu and cs.princeton.edu, I'm going to throw
> away the bogus set of NS records in favor of the authoritative set, and
> everything will work.

Your intelligent intermediate entities are not allowed to try to
administrate the zones, even if the administrators are dumb.

Zone administrators are responsible for the content of zones.

If you want to reduce the inconsistency prolem, you should develop
tools for zone administrators to maintain the zones at all of the
                                                       ^^^^^^^^^^
name servers.

							Masataka Ohta


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.