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

Paul Vixie <vixie@fsi.io> Sat, 25 August 2018 18:53 UTC

Return-Path: <vixie@fsi.io>
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 82BC2130EE4 for <dnsop@ietfa.amsl.com>; Sat, 25 Aug 2018 11:53:25 -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 aJ3EJy2QwPXm for <dnsop@ietfa.amsl.com>; Sat, 25 Aug 2018 11:53:24 -0700 (PDT)
Received: from mail.fsi.io (mail.fsi.io [104.244.13.188]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F610130EE3 for <dnsop@ietf.org>; Sat, 25 Aug 2018 11:53:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at fsi.io
Sender: vixie@fsi.io
Received: from linux-9daj.localnet (dhcp-181.access.lah1.vix.su [24.104.150.181]) (Authenticated sender: vixie) by mail.fsi.io (Postfix) with ESMTPSA id 78A66601EF; Sat, 25 Aug 2018 18:53:19 +0000 (UTC)
From: Paul Vixie <vixie@fsi.io>
To: dnsop@ietf.org
Cc: Tom Pusateri <pusateri@bangj.com>, Ted Lemon <mellon@fugue.com>
Date: Sat, 25 Aug 2018 18:53:17 +0000
Message-ID: <2127542.Mqhh3nicbA@linux-9daj>
Organization: Farsight Security, Inc.
In-Reply-To: <AC3FE6CF-CC11-44D3-8C50-BC19C295F001@bangj.com>
References: <153507165910.12116.7113196606839876181.idtracker@ietfa.amsl.com> <CAPt1N1=cafnVmnNM2eSF67QbgRk8hUEAd2Gwuqx4OUehPZSmyQ@mail.gmail.com> <AC3FE6CF-CC11-44D3-8C50-BC19C295F001@bangj.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Et-FEVRQMzBqLq9ehsbVO3HgxhE>
Subject: Re: [DNSOP] 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: Sat, 25 Aug 2018 18:53:25 -0000

On Saturday, August 25, 2018 6:11:48 PM UTC Tom Pusateri wrote:
> ...
> 
> In most cases, having the primary remember the lease lifetime should be
> enough. But if the outage is longer than the lease lifetime, it would
> better if the secondary would also have that information.

you seem to be proposing that the "secondary" servers, by which i mean those 
not the primary master, alter the zone contents in a way that's visible to 
query initiators, independently. if so, i oppose this, in the form proposed.

to have more than one source of DNS truth requires "multi-master", so that 
zone identity can be partitioned and healed, following partitions and healings 
of the connectivity of each responder and its cloud of reachable clients. one 
of the hard problems here is split horizon. another is incompatible deltas at 
heal time. the database world has grappled with this topic, having varying 
degrees of success, for as long as there have been computer networks.

i would like to see DNS add "multi-master". several proprietary vendor 
extensions do various parts of this -- though none of them that i know of can 
handle split horizon or incompatible deltas. and tellingly, none has been 
opened to the community in the form of a standardization effort.

if on the other hand you only intend to carry the timeout information as zone 
data transferred in AXFR/IXFR in case a sysop decides that the primary master 
will be offline indefinitely and wants to manually promote one of the 
"secondary" servers to the role of primary master, then i have no objection. 
that's why the TUU and TUD RR's of my 1996 "defupd" proposal are in-zone data 
rather than stored in some ancillary location reachable only by the primary 
master.

can you verify that you do not intend secondary servers to automatically 
expire records, independent of hearing IXFR/AXFR updates from the primary 
master, after the primary master applies its own copy of your TIMEOUT RR's?

-- 
Vixie