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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 05 March 2019 04:52 UTC

Return-Path: <christopher.morrow@gmail.com>
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 AFAA8130F30 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 20:52:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6O7k13lhmWNx for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 20:52:17 -0800 (PST)
Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2725512D4E7 for <dnsop@ietf.org>; Mon, 4 Mar 2019 20:52:17 -0800 (PST)
Received: by mail-it1-x129.google.com with SMTP id 188so2490770itb.0 for <dnsop@ietf.org>; Mon, 04 Mar 2019 20:52:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DwC3+9+gEliLzsWDD6BDzpeOgK8/PbXSOmJO/UrAECo=; b=V64H/vG4aDb5a8YuGq7gxBlR3udQlVrmCqY/xSWVAyRopTaMBATnUsG/er+w2UKVCc sOeMEJFCyagU11ZBf1URGtFk7ceblVEWPAwTlqYJdqyVI5akSR3TEBVI4xjMjjO0XTM0 TyM/LF67tZeCuu8EAotgxh4iU+mHYg77uHPvTbKJ63GwlPPRFUElECk1M/o4X44doWFs EZpjp/xEvuYITISIXRkk4dengX7/OPqeLWvilEqMv7Rz+lUENBNm7xoZZG/x7MnvPBMy lbIc3eoAx1n8IH1K3a16Pbdw7eemhBFc9mQKN091hNEvjKkZgHbcJ9ngSLMz1D0pw6IS jgYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DwC3+9+gEliLzsWDD6BDzpeOgK8/PbXSOmJO/UrAECo=; b=lqSQ8lQuLAlLmf8e8eLLGibJigStsJvDA8K01MG7xf7LIpLy4QQuqcvpN2xV6jFVa2 BNFj+JqfQBZrj+sZpbQ9bZUaD5SrBW7bDxU1/r188hmbKWeTYNc1SwX6mVtBrdEz5orI 7gOeAG2onwmCXg7xri4l+SFyEOkl3cXpgRyN5PClTMqu+qenHsbnGtxNEOegMSUhgDC2 oS2vg0m5cwEJHMMB2HcIjxSAsEbA1A8/mPmHLGefFrHUlDHpYI5alSlnb4SrWsMtBSgd 92f1fYCX8VIRXljIYD3U1ivzQjCAIF8Ha0i+TjseTuxMqZFLPOSYG2iMw8ZVPvRT3yhJ 7A4A==
X-Gm-Message-State: APjAAAV8I3k4tuVwTTwRUBUikNOi3j17MzU2m9d3prmSt6TfPoBO0faY 3njUEpeOpKbaUUiKl9xD4DAUuRYAj4g/60S/Kjk=
X-Google-Smtp-Source: APXvYqx6KG5/unwc0H0Auf7KwN9BN8pwiDLnhQrME3inMjiJfRILuq1YtGreXCU5Be5ZmteacwqiBwWnpOijySh0J0w=
X-Received: by 2002:a02:745:: with SMTP id f66mr130016jaf.137.1551761536027; Mon, 04 Mar 2019 20:52:16 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <alpine.LRH.2.21.1903042240330.32161@bofh.nohats.ca>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Mon, 4 Mar 2019 23:52:04 -0500
Message-ID: <CAL9jLabYgYco9JjBmo9g6DHjJ4Z3SsnqpDu=_WMWeo3mSNj-gA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002195d7058351a3f2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ERkazgRQhK97U8Vcsy5D33iLinI>
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 04:52:20 -0000

On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters <paul@nohats.ca> wrote:

> On Tue, 5 Mar 2019, Mark Andrews 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.
>
>         "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.

I don't know how long it takes to get ICANN to 'do something creative' for
the root zone, but I'm guessing this isn't always feasible in normal
timelines (hours to a day or so).


> I don't think this draft stops a domain from being brought down
> intentionally.
>
>
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. :(

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.


> >> 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" ?
>
> 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 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 :(


>
> I don't think the "4 years" is a realistic problem case.
>
>
is the '4 years' here in reference to the .eg problem?
in my example the '4 yrs' was: "when the incident happened" not "please
keep my dns alive for 4 yrs without talking to me"


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

-chris