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

Paul Wouters <paul@nohats.ca> Tue, 05 March 2019 14:25 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 0619E13109F for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 06:25:13 -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 LJJdRyj8_M04 for <dnsop@ietfa.amsl.com>; Tue, 5 Mar 2019 06:25:10 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::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 ABFD8131025 for <dnsop@ietf.org>; Tue, 5 Mar 2019 06:25:09 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44DK0y1pXYzCn2; Tue, 5 Mar 2019 15:25:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1551795906; bh=YUzyfgh4GK1kucOkX9McXcmpKEvnY1PeS71OiSrf0Jw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Y7skR14+4pOa43ptbgV9mkr9sRJuS9DtT/2PRt7CAuuVhsrUeqyxnSnV0baiw3Gz3 MS40lLYD2xvBal8NQ7mRuBlJcZHVbFRRqzYxtCkTBbniY3uNdvJaX9HbyZw2gzhU9z yvtOMxgxihqEppJu/RM9EB+1ZNn7geRN5VMPv0qo=
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 zZHtiN7Bntyt; Tue, 5 Mar 2019 15:25:04 +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; Tue, 5 Mar 2019 15:25:03 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E6DF939A5BC; Tue, 5 Mar 2019 09:25:02 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E6DF939A5BC
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E0ABF4116029; Tue, 5 Mar 2019 09:25:02 -0500 (EST)
Date: Tue, 5 Mar 2019 09:25:02 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Christopher Morrow <morrowc.lists@gmail.com>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <CAL9jLabYgYco9JjBmo9g6DHjJ4Z3SsnqpDu=_WMWeo3mSNj-gA@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1903050912170.6450@bofh.nohats.ca>
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> <92355508-D5AC-46DC-8FF5-C1C4155601D8@isc.org> <alpine.LRH.2.21.1903042240330.32161@bofh.nohats.ca> <CAL9jLabYgYco9JjBmo9g6DHjJ4Z3SsnqpDu=_WMWeo3mSNj-gA@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-2XSkFl4aegyRPOiKvumtFFgBro>
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 14:25:13 -0000

On Mon, 4 Mar 2019, Christopher Morrow wrote:

>               "If the recursive server is unable to contact the
>                 authoritative servers for a query "
>
>       So make the DNS server reachable, but return ServFail or NXDOMAIN. If
>       the owner doesn't cooperate and there is legal standing, talk to the
>       parent to do this for the delegation.
> 
> 
> this wasn't, near as I could tell, an option for the ccTLD in question.
> They lost their IP access, and were 'required' to disable their dns zone, their master was down hard from the internet's perspective,
> keeping anything else up wasn't really an option.

We should not base our DNS domains on scenarios where a DNS administrator
loses access to all their IP addresses and therefor could not operate
the DNS as required.

> i think it prolongs the data being available in a bunch of the cases I can imagine/have-seen.
> I think there's at least one case where it's likely grave harm could have come to the dns operator. :(

Grave harm beyond being already completely disconnected from the
internet? I think that kind of harm is not something we can address
in protocol design.

> I think what the draft does is attempt to guess at WHY a thing is changed, without an real data to back up the reasoning. this will mean the decision is wrong
> more than a small percent of the time.

You will have to provide a few scenarions that we can actually evaluate
to back that statement. To me, if your presence has been basically cut
from the internet, then this is no longer an internet protocol issue.

>       The DNS resolvers who want to accomodate their governments need to
>       manually override their resolvers anyway with new (forged) data. This
>       draft does not change that.
>
>       If the owner itself wants to bring the domain down, they just need to
>       make its auth servers reachable.
> 
> 
> sometimes that's not possible :( and the expectation is that 'when the right ttl sets expire all of our records disappear as you requested"

If your servers are connected to the internet, that remains the case.
The case we seem to talk about is only when all authoritative servers
are down. If you get non-technical pressure to bring things down without
getting TTL extensions, explain to those cutting you of that they can
get a shorter disconnect time by letting you run a modified DNS
configuration on your servers?

>       If the DNS hoster wants to bring it down, they just need to modify the
>       data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records.
> 
> 
> this is also not always possible :(

Sorry, again you have to substantiate your answer here. Make up an
imaginary story to illustrate this if you cannot use a real example.

>
>       I don't think the "4 years" is a realistic problem case.
> 
> is the '4 years' here in reference to the .eg problem?

I have no idea what the ".eg problem" is.

> in my example the '4 yrs' was: "when the incident happened" not "please keep my dns alive for 4 yrs without talking to me"

Ahh.

>       I can see how people want to get a few hours or a few days of usage
>       beyond the TTL to accomodate for errors. Although, it is likely that
>       moving up the error this way will also delay the error from being
>       detected before the extra time has expired, and we are just moving
>       the goal post with no effective gain. But in the case of a DDOS
>       attack, the draft's feature is surely useful.
> 
> 
> seems unlikely to be useful... even in the case of dos...really.
> (to me anyway)

If I need a few hours up to a few days to try and work around a DDOS
attack by adding capacity or some external provider to help me deal
with the DDOS, then buying those few hours are what is keeping a domain
online during such an attack. So while that might not apply to you, it
is an actual real use case.

Paul