Re: transfering vs. loading a zone

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 13 August 2008 10:56 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F28B3A6CD5; Wed, 13 Aug 2008 03:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.283
X-Spam-Level: **
X-Spam-Status: No, score=2.283 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9s8hTj4X2RN; Wed, 13 Aug 2008 03:56:00 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 45E2E3A6CEA; Wed, 13 Aug 2008 03:56:00 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KTDsp-000C5T-SS for namedroppers-data@psg.com; Wed, 13 Aug 2008 10:47:15 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <mohta@necom830.hpcl.titech.ac.jp>) id 1KTDsl-000C4v-Ki for namedroppers@ops.ietf.org; Wed, 13 Aug 2008 10:47:14 +0000
Received: (qmail 19845 invoked from network); 13 Aug 2008 10:50:39 -0000
Received: from bmdi2217.bmobile.ne.jp (HELO necom830.hpcl.titech.ac.jp) (202.221.174.217) by necom830.hpcl.titech.ac.jp with SMTP; 13 Aug 2008 10:50:39 -0000
Message-ID: <48A2BB7D.90408@necom830.hpcl.titech.ac.jp>
Date: Wed, 13 Aug 2008 19:46:21 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Edward Lewis <Ed.Lewis@neustar.biz>
CC: namedroppers@ops.ietf.org
Subject: Re: transfering vs. loading a zone
References: <a06240800c4c752b74d81@[192.168.50.50]>
In-Reply-To: <a06240800c4c752b74d81@[192.168.50.50]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Edward Lewis wrote:

> The issue begins with the question "what is in a zone?"  That question
> is what derailed the document a half decade ago.  The question is not
> that easy to answer.

The issue is vaguely recognized but not addressed in RFC1034 and a
solution was given 15 years ago or so in initial versions of IXFR
draft.

That is, glue As in zone information must be tagged by refferal point,
though neither zone file format nor AXFR allows to do so, which is why
I tried to fix it with IXFR.

The result was that no one else even tried to understand the issue,
which now resulted in Kaminsky's variation of ID attack with glue A.

> Here's an open question.  If a name server gets a zone via AXFR 
> (presumably the name server had a reason to ask for it) and decides the 
> zone is bad and returns SERVFAIL to all queries for data in the zone, 

Hugh? If a name server tries to receive a new version of a zone and fails,
it should continue to use an older version of the zone until it expires.

						Masataka Ohta


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>