Re: DNSEXT WGLC AXFR-02 SHORT last call

"D. J. Bernstein" <djb@cr.yp.to> Fri, 06 July 2001 11:22 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27025 for <dnsext-archive@lists.ietf.org>; Fri, 6 Jul 2001 07:22:02 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15ITM2-000LiJ-00 for namedroppers-data@psg.com; Fri, 06 Jul 2001 04:00:58 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15ITM1-000LiD-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:57 -0700
Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15ITM1-00029Z-00 for namedroppers@ops.ietf.org; Fri, 06 Jul 2001 04:00:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org
Subject: Re: DNSEXT WGLC AXFR-02 SHORT last call
References: <Pine.BSF.4.21.0106221025140.33035-100000@hlid.dc.ogud.com> <E15GWo7-0000bB-00@psg.com> <E15HA66-000Am6-00@psg.com> <E15HfRH-000IqJ-00@psg.com> <E15Hr5n-000OJC-00@psg.com> <E15IMbv-0009b3-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15ITM2-000LiJ-00@psg.com>
Date: Fri, 06 Jul 2001 04:00:58 -0700
Content-Transfer-Encoding: 7bit

Andreas Gustafsson writes:
> IDs and RCODEs are checked in all other contexts of the DNS protocol,
> and I don't think it was the intent of RFC1034/1035 to make AXFR an
> exception.

I think it would help if you read the DNS specifications. ID checking
and RCODE checking are explicitly given as part of the recommended
resolution algorithm in RFC 1034 section 5.3.3. They are not part of the
zone-transfer protocol in section 4.3.5.

Zone-transfer clients are not resolvers. The principle that they should
follow resolver rules is a figment of your imagination.

> RFC1034 says the records in the parent "should" (not "must") be
> exactly the same as those in the child.

RFC 1034 also says that a node with a CNAME record ``should'' have no
other data, and that in the last step of delegation one ``should'' add
NS records to the parent zone, and that lame delegations ``should'' be
ignored, and that it is essential that temporary errors ``should not''
be signalled as permanent errors.

> I have no idea what you are talking about here.

I've been told, by a source I believe, that some recent versions of BIND
reject zones of the type I described as containing ``non-glue records.''
Please investigate, and then explain the facts to us.

> The requirement to send a response is already implicit in the nature
> of the DNS protocol as a query-response protocol.

Nonsense. Unauthorized clients do not have any right to a response.

---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.