Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.txt

Mark Andrews <marka@isc.org> Tue, 05 March 2019 03:36 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 28558130EE6 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 19:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 bf6TQxS1FrYB for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 19:36:20 -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 05B0F130ED0 for <dnsop@ietf.org>; Mon, 4 Mar 2019 19:36:20 -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 A75173AB045; Tue, 5 Mar 2019 03:36:18 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7D1A116006D; Tue, 5 Mar 2019 03:35:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B8C0160075; Tue, 5 Mar 2019 03:35:48 +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 1db9rvJhWc3p; Tue, 5 Mar 2019 03:35:48 +0000 (UTC)
Received: from [192.168.0.3] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id F11B916006D; Tue, 5 Mar 2019 03:35:46 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <4253851.Zqd2zPpPcC@linux-9daj>
Date: Tue, 5 Mar 2019 14:35:44 +1100
Cc: IETF DNSOP WG <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, Paul Hoffman <paul.hoffman@icann.org>, Christopher Morrow <morrowc.lists@gmail.com>, Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <92355508-D5AC-46DC-8FF5-C1C4155601D8@isc.org>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com> <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com> <4253851.Zqd2zPpPcC@linux-9daj>
To: Paul Vixie <paul@redbarn.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/R6XdBqVAXjLLR5xg_Sl6oxHyiiA>
Subject: Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-serve-stale-03.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, 05 Mar 2019 03:36:22 -0000


> On 5 Mar 2019, at 1:26 pm, Paul Vixie <paul@redbarn.org> wrote:
> 
> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote:
>> can I ask, what happens when a domain is intentionally down though? For
>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the
>> master/shadow NS go down, hard. All public auth servers eventually (in a
>> day or so) went dark too.
> 
> i already raised that question, very far up-thread. got no answer.
> 
>> If someone is 'ordered' to make a zone dark, there may be reasons for that
>> action, and real penalties if the request is not honored.
>> Is this draft suggesting that the DNS operations folk go against the wishes
>> of the domain owner by keeping a domain alive after the auth servers have
>> become unreachable? How would a recursive resolver know that the auth is
>> down: "By mistake" vs: "By design" ?
> 
> this the essence of the argument against utility for this entire proposal. no 
> data should be served beyond its TTL unless some new leasing protocol is first 
> defined, to obtain permission and to provide a cache invalidation method.
> 
> vixie

And one can to that if we add 2 TTLs to each DNS record. One for total time to
live and one for freshness (old client get this).  It will require EDNS to signal
that multiple TTLs are desired and are present in the response and may require
using the last DNS flag bit to move the OPT record to in front of the question
section to make parsing easier (no trial and error).

Yes, this is radical but it will work and is incrementally deployable.

> _______________________________________________
> 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