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

Paul Vixie <paul@redbarn.org> Tue, 05 March 2019 02:26 UTC

Return-Path: <paul@redbarn.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 CCAF61200ED for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 18:26:12 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 Co_A8vI133_G for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 18:26:10 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1861271FF for <dnsop@ietf.org>; Mon, 4 Mar 2019 18:26:10 -0800 (PST)
Received: from linux-9daj.localnet (unknown [203.178.157.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6FAE4892C6; Tue, 5 Mar 2019 02:26:08 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: Christopher Morrow <morrowc.lists@gmail.com>, Puneet Sood <puneets=40google.com@dmarc.ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, Paul Hoffman <paul.hoffman@icann.org>
Date: Tue, 05 Mar 2019 02:26:05 +0000
Message-ID: <4253851.Zqd2zPpPcC@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com>
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com> <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.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/ljbZiJGBRmxU6_8UfCns-9Ibpp8>
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 02:26:13 -0000

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