Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Tom Pusateri <pusateri@bangj.com> Fri, 24 August 2018 16:38 UTC

Return-Path: <pusateri@bangj.com>
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 8277D12F1AC for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 09:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ReKKn6FeNj7Z for <dnsop@ietfa.amsl.com>; Fri, 24 Aug 2018 09:38:26 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB35C12F1AB for <dnsop@ietf.org>; Fri, 24 Aug 2018 09:38:26 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3E6182F4F; Fri, 24 Aug 2018 12:34:12 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <C8BEDE9A-34F1-4871-BA6E-980DCF703AB9@hopcount.ca>
Date: Fri, 24 Aug 2018 12:38:24 -0400
Cc: Paul Vixie <paul@redbarn.org>, dnsop WG <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>, Tim Wattenberg <mail@timwattenberg.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2D0F529-978F-4A7A-AAA7-E592CDA12827@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <AFB90F6F-5D99-4403-AAB6-1123727973E6@bangj.com> <5B7F5E07.5080100@redbarn.org> <7F91FFF7-71C3-4F8E-82CD-266B170983E0@bangj.com> <C0EE2719-B662-4231-AF51-D3B98B00AD0D@fugue.com> <6D607922-393D-4549-AAFA-49279C260CA4@bangj.com> <C8BEDE9A-34F1-4871-BA6E-980DCF703AB9@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/R2p7CZvbMu83QHx6aXKhoIZXIk4>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 24 Aug 2018 16:38:29 -0000


> On Aug 24, 2018, at 10:11 AM, Joe Abley <jabley@hopcount.ca>; wrote:
> 
> Hi Tom,
> 
>> On Aug 24, 2018, at 09:52, Tom Pusateri <pusateri@bangj.com>; wrote:
>> 
>>> If a zone is signed, are the TIMEOUT records signed?
>> 
>> No. The draft says they are skipped.
> 
> New RRTypes are supposed to be handled by old software that pre-dates them because they can be treated as opaque types. That's not the case if new RRTypes are encumbered with requirements for special handling at query or signing time (as described in your section 2).
> 
> This seems like a significant architectural change that in effect updates 1034 and 1035 as well as 3597. This would be a much more straightforward and uncontroversial proposal if it was simply a specification for use of a new RRType that made no changes at all to the rest of the protocol.
> 
> I have not read your draft in detail but I think you probably would also need to spend more time considering the cases of old, non-TIMEOUT authority servers that wind up serving zones that contain TIMEOUT RRSets (e.g. third-party hosting services). Client handling of rogue RRSIGs, RCODE=NOERROR with ANSWER sections containing TIMEOUT RRSets, etc.

Yes, the draft says the primary has to agree to send them to the secondary and the secondary has to agree to accept them (administratively). This prevents old authority servers from having to deal with them.

The position of not having them signed is a consequence of not having them returned in a query. If you can’t see them in a query, you can’t do NSEC/NSEC3/NSEC5 next record semantics so we skip them.

By simply making them returned in a query, we can avoid most of your objections. Mark Andrews suggested they not be returned in a query in a hallway discussion and I’m happy to change if that’s the preferred approach.

Thanks for the feedback!

Tom