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

Christopher Morrow <morrowc.lists@gmail.com> Tue, 05 March 2019 02:21 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 7DAB5128CF2 for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 18:21:57 -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 hcMZrxpX2_lV for <dnsop@ietfa.amsl.com>; Mon, 4 Mar 2019 18:21:55 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 C4F2B1200ED for <dnsop@ietf.org>; Mon, 4 Mar 2019 18:21:54 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id k21so5715546ior.13 for <dnsop@ietf.org>; Mon, 04 Mar 2019 18:21:54 -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=PyreBejAsU4zMz2R76crldJUv4/ZVUPLU1Wm9UQWXKQ=; b=l4wLOEbyt3TjtgVHKGTbyL3laqQlJlEUqofM9KQ4OvPiK0wQH39ZVgngwgbsvsyfSY 5ggJXpT6QfWfjtNOd8WTrmrbiRYDkS3Wm1bu9nFPBFvTlApB4gtzaGdbVWSGXjpLV3t9 2XTcEuLLqyYXZUZALaq4+kgY95IvsaaHckMIx29iIMV2DaiDgt87B1RAsT60VCDZcXgj wesYT5pPbVlV19gUWo/zc/aub9/ZsC0m3jFwzTOLa5wmgqvlMBbs0kZqGQllaveYpLKa P6a3kGHQBcxLbGsqEFM87jOo1OCLa/zju03sFx1CPNhhxGRt+wb31veIyc4eTT6v8e7O Vh1g==
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=PyreBejAsU4zMz2R76crldJUv4/ZVUPLU1Wm9UQWXKQ=; b=NWzVlPwMnem08PK34YGvdPrn9EbYyiVwUk/ZAv2SEeo38afOsyh86t/4cliGKbbyoO zpPGjYifhgnxT1DeYZBh0qytZ+suTlnxM9USbGPVa3CUdg/Bhfkg1Q0zVo3nXcVhQ1TL 7rz5OGkeNDVHq4dAb6pcdnRQD1HodtEHickOFqG213Fgc9W49nNrEDlWpNhsF45473NY U2TuYCJW+sCnciZBABmmdfLBlMjDepfp9P01piea5ICKIFFQr+MRa1jgHbwv3Q+lJ7K2 f0+KDlVFNb0bXwWQ1RvHaHHfOIgmRq4YJYJd3i64noKFIFr56G7GQZnQgi26MDhQ8m0C t/Qw==
X-Gm-Message-State: APjAAAWZ780J7GJYI8rVXow66jtcJjys826+/N+5v2cXJPXc+Ki7fJx7 PPLoxO/y1Rt9FbN2uK+h9bRMds3cwGJSNyqF+dg=
X-Google-Smtp-Source: APXvYqwP+/60z4uGg09uLQlVT5UGzJCP+bQck6RIqbylcKpC/7c0s/knewPHTx4wpSdtRQvqqrwgjygvcDk9H4mcHzc=
X-Received: by 2002:a5e:a611:: with SMTP id q17mr10959837ioi.17.1551752513686; Mon, 04 Mar 2019 18:21:53 -0800 (PST)
MIME-Version: 1.0
References: <155094804613.28045.8648150477440044197@ietfa.amsl.com> <CA+nkc8DvZr84E46vna91iBsJ2uSVsda1cCzyTNx9C_J85uKW1w@mail.gmail.com> <23673.27866.35423.674591@gro.dd.org> <FD2C124D-BD1E-41AE-B4AB-007E451A32D6@icann.org> <53DB1048-2B9C-43CA-A6FD-C423DE0254B3@icann.org> <CADyWQ+FOQdEDSAbVtysDkELuJdp_-igKh3WAY-UJQZPxRWtYrg@mail.gmail.com> <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com>
In-Reply-To: <CA+9_gVscCzr0S8A0Z23q0V1B+BZeLtDoZRSKyEJDPZ3P=KT-tw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Mon, 04 Mar 2019 21:21:42 -0500
Message-ID: <CAL9jLaYo5JH6vf+djEn0O=YGhLV2AkytMg_eKQmWn=Pma5yBFQ@mail.gmail.com>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Paul Hoffman <paul.hoffman@icann.org>, IETF DNSOP WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005b912305834f891d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YNU10MKCa_qpW5CqHOHSZzktKmg>
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:21:57 -0000

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

-chris


On Mon, Mar 4, 2019 at 6:25 PM Puneet Sood <puneets=
40google.com@dmarc.ietf.org> wrote:

> Tim, Paul,
>
> Thanks for the feedback. Working on clarifying the recommendations.
>
> -Puneet
>
> On Sun, Mar 3, 2019 at 8:34 PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
>
>> "Proposal: Put all recommendations in Section 4, and talk about them
>> (instead of introducing them) in the other sections. That way, a lazy
>> developer who only reads Section 4 will know all the recommendations."
>>
>> I totally agree here.  It also makes it easier if the document passed
>> WGLC and moves along the standards process train.
>>
>
>> Tim
>>
>>
>> On Fri, Mar 1, 2019 at 2:51 PM Paul Hoffman <paul.hoffman@icann.org>
>> wrote:
>>
>>> Following up on my previous message:
>>>
>>> The document is actively confusing about recommendations.
>>>
>>> - Section 4 has the actual update to the RFC 1035, and that update
>>> contains MAY and SHOULD statements.
>>>
>>> - Section 5 is called "Example Method" but also contains recommendations.
>>>
>>> - Section 6, "Implementation Caveats" also has recommendations. A
>>> subsection, "6.1. Implementation Considerations" has more recommendations.
>>>
>>> Proposal: Put all recommendations in Section 4, and talk about them
>>> (instead of introducing them) in the other sections. That way, a lazy
>>> developer who only reads Section 4 will know all the recommendations.
>>>
>>> --Paul Hoffman
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>