Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification
Joe Abley <jabley@hopcount.ca> Wed, 04 April 2018 03:31 UTC
Return-Path: <jabley@hopcount.ca>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00D4126CE8 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 20:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM32bYEueJb7 for <dnsop@ietfa.amsl.com>; Tue, 3 Apr 2018 20:31:26 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1F3126CD8 for <dnsop@ietf.org>; Tue, 3 Apr 2018 20:31:26 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id y128so24540825iod.4 for <dnsop@ietf.org>; Tue, 03 Apr 2018 20:31:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wg2Iif9EeqweQ/7XnY4cMfhrkqXhoHWIhPGnP8hodW0=; b=k4pPNsqLoBGSWkIeuPcGmfCJQFtZ7KN6KMvuZ3MX8uR2rorDIn/FHtYNRn6PvSi81U yohq5Sr8HGmkPUNr4FXhR9s33KyQIFFT13WoDMOZT+RO3CAqzR1QK9dlCb0jS/k1DDDB yApebot90adLhz9oPmFgK6mOetDS4EVZ/rAdg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wg2Iif9EeqweQ/7XnY4cMfhrkqXhoHWIhPGnP8hodW0=; b=q2MIAo3THqTZhn9lCvIXS/jY2nP/W+6EjzBE3wu2+7sg+S/roQ4R6gqGABncGbdAfZ GBJCcBu0FrOTaDR7d1wSwp6iASwQsGSkTybO9fqt0odV/vIaYmobRPhJVbmn667wOPUs RZetf2oP3wQsbBAtHfkDDejOzy8Njfvp+z70/3ItdJcX69M2Gpm7aih/J2wClNd0gfGk kB1q/+UYBP2sLhKUoGh1RyfNW1rlttklHYc/CuXW/cDrb0PULix0c0WB/fqCGK/E0Qze 6L4Jx/OE2k2FkzrKNbcH4tZAcW/6ko9fUJ5y9f/bDN1Pv74Py/WjBupAi9GCxdFWZbXH kVEw==
X-Gm-Message-State: AElRT7FsZRzDG2P4RgTp4EkpO/IvlsTmW4m+/dmhvh0fPIFEX8MekGPB Cyw0oMC9VuCIzZ2kGkKSgfnqN7DsUUA=
X-Google-Smtp-Source: AIpwx48JhHOE3x+R4/rRudJG4tm/7Ju8RYmwro4mQdK/QxjAy8F3gV6AgWobEmpFAJ2uLIKCP33qnA==
X-Received: by 10.107.163.82 with SMTP id m79mr14048530ioe.26.1522812685146; Tue, 03 Apr 2018 20:31:25 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:101:3:5c4a:9675:f654:166b? ([2607:f2c0:101:3:5c4a:9675:f654:166b]) by smtp.gmail.com with ESMTPSA id w130sm2456409iod.25.2018.04.03.20.31.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 20:31:24 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (15D100)
In-Reply-To: <20180404013246.GE10662@registro.br>
Date: Tue, 03 Apr 2018 23:31:23 -0400
Cc: Matthijs Mekking <matthijs@pletterpet.nl>, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6000B001-F8B5-4BD0-B3FD-42806BDA335A@hopcount.ca>
References: <20180329184513.GF62218@registro.br> <c62db666-fc1b-8ef8-8fbb-42443e1b69a0@pletterpet.nl> <20180404013246.GE10662@registro.br>
To: Frederico A C Neves <fneves@registro.br>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nIpZ0zaipZ-YIZcNIhp5H1j4JwM>
Subject: Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2018 03:31:28 -0000
On Apr 3, 2018, at 21:32, Frederico A C Neves <fneves@registro.br> wrote: >> On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking wrote: >> Hi Frederico, >> >>> On 03/29/2018 08:45 PM, Frederico A C Neves wrote: >>> I was looking at our server to evaluate the MIXFR implementation and >>> it seams to me that the current text covering dnssec aware client >>> logic don't take in account that a posterior record at the addition >>> section, by an MIXFR DNSSEC aware server, will implicitly replace the >>> RRSIG RRset. >> >> I am unclear what case you are covering. > > Any situation that you have an updated RRset. It is implicit that > you'll have to update the signature, so I was arguing that this is > afterward covered by 3.6 Replace a RRset. My "simplified" logic take > this in account to don't impose this extra logic at the client for > updated RRsets, only for removed RRsets, explicit or when a removal of > RR causes it. I have not been reading this thread in depth and so I have not commented up until now. But I sense that there is a proposed shift of responsibility for coherency in the contents of a zone, specifically with resapect to DNSSEC. Quite possibly I am wrong, in which case I will enjoy being told as much. If I am a zone administrator, responsible for the self-consistent contents of my zone, and I make a mistake, the behaviour today (with zones distributed by AXFR, IXFR, rsync, ftp, avian carrier) is that a DNS zone is a DNS zone and the RRSets contained within are simply that, no appreciation, understanding or accommodation of DNSSEC required. The line of thinking inherent in the lowest quoted paragraph above suggests that distribution of sets of RRSets (together forming a zone) must with this new transfer mechanism be completed with semantic appreciation for the relationship between non-RRSIG-type RRSets and the corresponding RRSIG-type RRSets that accompany them in a signed zone. This worries me. The protocol requirements for DNSSEC as described in RFC 4035 are non-trivial to implement already (cf. the treatment of RRSets in a response with their accompanying RRSIG RRSets as an atomic unit in the cache, to be expired together regardless of differences in TTL) and I don't think we want to extend them without good reason. If we expect MIXFR (or whatever it is eventually called) to behave differently in this respect to AXFR, IXFR or any number of out-of-band transfer mechanisms, we should have a good reason for it. I don't know that I see one, yet. Joe
- [DNSOP] mixfr - issue #10 - Client RRSIG logic si… Frederico A C Neves
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Matthijs Mekking
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Mark Andrews
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Matthijs Mekking
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Frederico A C Neves
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Joe Abley
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Matthijs Mekking
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Matthijs Mekking
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Mark Andrews
- Re: [DNSOP] mixfr - issue #10 - Client RRSIG logi… Matthijs Mekking