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

Mark Andrews <marka@isc.org> Wed, 20 February 2019 07:46 UTC

Return-Path: <marka@isc.org>
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 201BE130DC4 for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 23:46:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 BDY7tVPzMc34 for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 23:46:35 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 777BF130DE5 for <dnsop@ietf.org>; Tue, 19 Feb 2019 23:46:33 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0B1C33AB05C; Wed, 20 Feb 2019 07:46:33 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DE93216005B; Wed, 20 Feb 2019 07:46:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BA12816006A; Wed, 20 Feb 2019 07:46:32 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id I3oA9X5lDksQ; Wed, 20 Feb 2019 07:46:32 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 85AAA16005B; Wed, 20 Feb 2019 07:46:31 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca>
Date: Wed, 20 Feb 2019 18:46:28 +1100
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FE58E37-D435-4853-A9CF-10238AB641D5@isc.org>
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> <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca> <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org> <alpine.LRH.2.21.1902200028210.29865@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2XrGeRm_-c7mQdzKNaquOvQxZpU>
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: Wed, 20 Feb 2019 07:46:38 -0000


> On 20 Feb 2019, at 4:35 pm, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Wed, 20 Feb 2019, Mark Andrews wrote:
> 
>> Think disaster recovery and promoting a slave to master.  You have to
>> transfer state between servers.  You can transfer it in band or out of
>> band.  If you transfer it out of band you need to invent / specify
>> yet-another-protocol to do it on top of specifying when records need to
>> be removed.
> 
> That is not very convincing to me. disaster recovery scenarios seem to
> be solvable by proper admin and by the daemon properly writing state to
> disk which can be saved off-site. It also seems a rather rare occurrence.

So you write it to disk then transfer it off site which breaks atomicity
of the zone’s meta state or do it in band with TIMEOUT.

> If the primary does DNSSEC, you also have to transfer private keys and
> that isn't happening in-band either. So I'm not convinced by the
> promotion of secondary to master either.

You can pass the keys before you start to use them.  They are essentially
static information.

> It also seems these two use cases are mostly solved if you keep your
> dynamic update clients within their own zone, which I think is pretty
> normal for DHCP based nodes that can make up their own hostname anyway
> and shouldn't be able to muck with real static records or apex records.

Policy about who can update what is unrelated to making sure content gets
cleaned up.  There isn’t always a DHCP server to do the garbage collection.
This is especially true with IPv6 and SLAAC.

> Paul
> 
>>> On 20 Feb 2019, at 9:26 am, Paul Wouters <paul@nohats.ca> wrote:
>>> 
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org