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

Paul Wouters <paul@nohats.ca> Wed, 20 February 2019 05:35 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 9A31612D84D for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 21:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 u6AZfdmh1aaz for <dnsop@ietfa.amsl.com>; Tue, 19 Feb 2019 21:35:17 -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 A3AAF129619 for <dnsop@ietf.org>; Tue, 19 Feb 2019 21:35:16 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4445sY2qZ6z3Td for <dnsop@ietf.org>; Wed, 20 Feb 2019 06:35:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1550640913; bh=k7niIgCZ7cesKyoZbaGaBLpKm+xVCerWz44SeTpmI3Q=; h=Date:From:To:Subject:In-Reply-To:References; b=siEwFWg9kWQdCB3yGKpSMf/CVxczn6DTP39e45QhHSE9ADSC2/6yoiZG3GzYM9pZH B5/aO3Ue7FD3K/CTC2TYBMFlMqR1h4FW8Iz1qmKpCKcx7Ug5MyjJ1fQmt8TgQToXeI SLbSuBVFd6N8/v2SfWKgaXCtT2nD8jsg8WjcxtmI=
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 8gjbgQRuxCSJ for <dnsop@ietf.org>; Wed, 20 Feb 2019 06:35:11 +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>; Wed, 20 Feb 2019 06:35:10 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id C7B7F2FCBF; Wed, 20 Feb 2019 00:35:09 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C7B7F2FCBF
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BCFF440D358A for <dnsop@ietf.org>; Wed, 20 Feb 2019 00:35:09 -0500 (EST)
Date: Wed, 20 Feb 2019 00:35:09 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org>
Message-ID: <alpine.LRH.2.21.1902200028210.29865@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> <alpine.LRH.2.21.1902191715230.30381@bofh.nohats.ca> <1F461BFA-638A-4607-84BD-F8B8597A1114@isc.org>
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/JbBsyNdNZsdI6llPZ3JmFzzoCMo>
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 05:35:20 -0000

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 occurance.

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.

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.

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
>