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

Paul Wouters <paul@nohats.ca> Tue, 19 February 2019 22:27 UTC

Return-Path: <paul@nohats.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 3264C130FA8 for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 14:27:11 -0800 (PST)
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=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: DNS error: query timed out)" header.d=nohats.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 d7AM-2ddDrvP for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 14:27:01 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723A9128BCC for <dnsop@ietf.org>; Tue, 19 Feb 2019 14:27:01 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 443wMQ1dhqzHVf for <dnsop@ietf.org>; Tue, 19 Feb 2019 23:26:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550615218; bh=XIu1qov9DALUQkszaReAc6YmqoPT2V7MNOYbaotkgY4=; h=Date:From:To:Subject:In-Reply-To:References; b=kmu5Gx6rlHCAe2zc9THYJzUJ97bQUObdXN9/DXbkWA4iAhE6CLNRHdGEW0KblVXhe LOGYoFTyefa/DnK86NgeTdzXyiQ5RikQ7eP/3qkWpB3auIOyqaz6uDjW3RX34nSHVs fM8PCP/UKFLUsK7kxWB93ZyD13G2GHW8CTYK2sIs=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dPGiLuXjc6Nd for <dnsop@ietf.org>; Tue, 19 Feb 2019 23:26:56 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for <dnsop@ietf.org>; Tue, 19 Feb 2019 23:26:55 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1065F2FCBF; Tue, 19 Feb 2019 17:26:55 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 1065F2FCBF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 01EA840D358A for <dnsop@ietf.org>; Tue, 19 Feb 2019 17:26:54 -0500 (EST)
Date: Tue, 19 Feb 2019 17:26:54 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <0DE33073-93B1-4CF5-B12D-B7266E21E8B2@timwattenberg.de>
Message-ID: <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca>
References: <155053239541.25848.12960190085730298684.idtracker@ietfa.amsl.com> <969D8BA1-6ED3-47E8-AFFD-2BEE8EA3E66B@bangj.com> <alpine.DEB.2.20.1902191219070.766@grey.csi.cam.ac.uk> <0DE33073-93B1-4CF5-B12D-B7266E21E8B2@timwattenberg.de>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rnyh6uHpUsUPmqFXq9RK4oav_UM>
Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 19 Feb 2019 22:27:11 -0000

I have read the document.

I have a question about:

    A zone administrator may
    want to enforce a default lifetime for dynamic updates (such as the
    DHCP lease lifetime) or the DNS Update may contain a lifetime using
    an EDNS(0) Update Lease option [I-D.sekar-dns-ul].

This seems a local policy and local implementation issue only.

   However, this
   lease lifetime is not communicated to secondary servers and will not
   endure through server software restarts.

Why does the secondary server need to know the lease lifetime? Only the
primary needs to know this because it will need to purge the records and
update the appropriate DNSSEC entries, something the secondary cannot do
anyway? In fact, Section 8 agrees with me:

    A secondary server MUST NOT expire the records in a zone it maintains
    covered by the TIMEOUT resource record and it MUST NOT expire the
    TIMEOUT resource record itself when the last record it covers has
    expired.  The secondary server MUST always wait for the records to be
    removed or updated by the primary server.

So why is the TIMEOUT record needed? If the secondary argument is
gone, the only argument left from the Introduction is server software
restart. Which seems to me to be an application issue and not a protocol
issue?

As others pointed out, introducing SHA3 into the DNS right now is not
appropriate.

I see a use for clients telling the dns update server what the maximum
possibly lifetime can be, so it can go and perform a delete request on
behalf of vanished clients. But again I don't see this as a protocol
issue needing a TIMEOUT RRTYPE ?

Did I miss anything?

Paul