Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02

Ondřej Surý <ondrej.sury@nic.cz> Fri, 17 June 2011 14:15 UTC

Return-Path: <ondrej.sury@nic.cz>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352D611E80D5 for <dnsext@ietfa.amsl.com>; Fri, 17 Jun 2011 07:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Y0UMLcs3X7m for <dnsext@ietfa.amsl.com>; Fri, 17 Jun 2011 07:15:25 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A881D11E8087 for <dnsext@ietf.org>; Fri, 17 Jun 2011 07:15:21 -0700 (PDT)
Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 02C852A0BE8; Fri, 17 Jun 2011 16:15:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308320116; bh=QQYNHFAfCZGJklQ8n8iXPKI8ApfnrmWPLl0cyeL/zMU=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aawRsJIctPQnbmAIquYdna8rgr0JRSbq0j+6hSeKjS+zeBHexL/9rsGhnQyrAg+ND wPJJSSDCL7AEpsygEWq7D6Ukz39/ymipqo81ERFGPr7scat2Clz4ERHtGoRxvKUGgo DXBXBUctIx59XBJ2STbm9vQFISWHwXBsjbMPhrRA=
Message-ID: <4DFB6173.5080802@nic.cz>
Date: Fri, 17 Jun 2011 16:15:15 +0200
From: Ondřej Surý <ondrej.sury@nic.cz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10
MIME-Version: 1.0
To: Edward Lewis <Ed.Lewis@neustar.biz>
References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <a06240803ca1fd7525c50@10.31.201.23> <BANLkTinjRDHyKH-tLEoejodXb2+7qQLO7w@mail.gmail.com> <a06240801ca2102b8b4f2@[10.31.201.23]>
In-Reply-To: <a06240801ca2102b8b4f2@[10.31.201.23]>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: Alfred Hoenes <ah@TR-Sys.de>, dnsext@ietf.org
Subject: Re: [dnsext] Fwd: New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 14:15:28 -0000

On 17.6.2011 15:29, Edward Lewis wrote:
> At 16:48 -0400 6/16/11, Brian Dickson wrote:
> 
>> Actually, it does, right at the beginning of section 4. Quoting the text:
>>
>> 4. Response Format
>>
>>
>>    If incremental zone transfer is not available, the entire zone is
>>    returned.  The first and the last RR of the response is the SOA
>>    record of the zone.  I.e. the behavior is the same as an AXFR
>>    response except the query type is IXFR.
> 
> No, that is not a fallback to AXFR.  The spec is not saying that an
> unsatisfactory IXFR session leads to an AXFR session (with the same
> remote address).
> 
> What is confusing is the phrase "is the same as."
> 
> If the query type is IXFR, the response will be an IXFR response that
> contains all of the records in one (UDP) datagram, which functionally is
> the same as a AXFR having all of the records appear in multiple DNS
> messages over a stream - the same for only small to very small zones. 
> The response is limited to 512 bytes or whatever is in the EDNS0 buffer
> size of the requestor.
> 
> Think of it this way.  If I send an IXFR request over UDP, how could a
> response be an AXFR?  AXFR can only be sent on TCP.
> 
> In a way, the net result of an AXFR-Style IXFR (as I've heard that
> called) and an AXFR is that you get the entire zone in one shot.
> Functionally the result is the same.  But the delivery mechanism is much
> different.  No spec ever said that an implementation had to back up IXFR
> with AXFR (except for backwards compatibility - the passage I quoted).

But the fact is that you get a full zone.

Also the new draft says:

   In case of fallback to AXFR, the answer contains the same RRs (and is
   subject to the same ordering rules) as specified in Sections 2.2
   through 3 of RFC 5936, with the single difference being the echoed
   QCODE (i.e., IXFR) in the Question section.

The fact is that the it's the behaviour which is "AXFR" (that is what we
talk about), but the QCODE/RCODE is not "AXFR", but IXFR.

>> Those fall under the scope of operator, rather than implementer, issues.
>> Presumably the operator will act sensibly, trying all available
>> sources for IXFR-ONLY, before giving up and doing an explicit AXFR.
> 
> Operators generally use the tools implementers give them.
> 
>>
>> The need for IXFR-ONLY is the desire to have interoperable
>> implementations.
> 
> I said this in another context earlier this week, the desire to have
> interoperable implementations is subsidiary to having features that make
> sense.

The IXFR-only is backwards compatible both ways in Client+, Server- and
Client-,Server+ scenarios.

Client+,Server-

C: Query IXFR-ONLY
S: NotImpl
C: Query IXFR
S: ...

Client-,Server+

C: Query IXFR
S: ...

> IXFR-all-sources-before-AXFR makes more sense
> than IXFR-only.  And even that is what I would consider an
> implementation optimization.

It is optimization (look into archive, we talked about that before and
it should be written in Motivations for IXFR-only section of the I-D).

And you cannot do IXFR-all-sources-before-AXFR without IXFR-only.

O.
P.S.: I'll reply to your first mail later, but bear in mind that it's
written in context of AXFR clarify.
-- 
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:ondrej.sury@nic.cz    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------