Re: Extra records in zone transfers

"D. J. Bernstein" <djb@cr.yp.to> Mon, 19 March 2001 06:02 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Mar 2001 03:05:35 -0000
Message-ID: <20010319030535.15805.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org
Subject: Re: Extra records in zone transfers
References: <20010318060729.2828.qmail@cr.yp.to> <200103190217.LAA06070@necom830.hpcl.titech.ac.jp>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Masataka Ohta writes:
> "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.

> What is the problem, then?

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.

---Dan

to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.

Re: Extra records in zone transfers D. J. Bernstein
Re: Extra records in zone transfers Masataka Ohta