Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03

Dave Lawrence <tale@dd.org> Mon, 25 March 2019 23:29 UTC

Return-Path: <tale@dd.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 7555C120151 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 16:29:02 -0700 (PDT)
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, SPF_PASS=-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 UcOs4WC1P2l4 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 16:29:00 -0700 (PDT)
Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269BC12014C for <dnsop@ietf.org>; Mon, 25 Mar 2019 16:28:59 -0700 (PDT)
Received: by gro.dd.org (Postfix, from userid 102) id D0FF38ED0A; Mon, 25 Mar 2019 19:28:57 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <23705.25657.838079.44692@gro.dd.org>
Date: Mon, 25 Mar 2019 19:28:57 -0400
From: Dave Lawrence <tale@dd.org>
To: IETF DNSOP WG <dnsop@ietf.org>
In-Reply-To: <e75aa69c-e02b-72a1-6375-660151afbdd2@bellis.me.uk>
References: <CAJE_bqdugE3oMqyHres4hwhs4-NpO8yW2FwGDrk2WDAtbweBiQ@mail.gmail.com> <23682.53436.400539.805166@gro.dd.org> <8ffa4b04-324a-36c8-a9ff-e0cda726a54c@NLnetLabs.nl> <841f8174-c7d5-c702-e6be-ccb9a7c2c048@redbarn.org> <fe4aecac-aa46-e269-bc77-5250b383685a@bellis.me.uk> <CA+9_gVsfrJVtqqsniJ_f4NKkbtz5J4Q=eHxvxX9Ud86u5=j9Hw@mail.gmail.com> <e75aa69c-e02b-72a1-6375-660151afbdd2@bellis.me.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/flkbKGmsYZuVuh0KSqzMgk-R23g>
Subject: Re: [DNSOP] comments on draft-ietf-dnsop-serve-stale-03
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: Mon, 25 Mar 2019 23:29:03 -0000

Ray Bellis writes:
> Serve stael must not become a vector whereby malware can keep its C&C 
> systems artificially alive even if the parent has removed the C&C domain 
> name.

I wholeheartedly agree with this ideal, and am very open to
considering text improvements.

The document already has guidance on this point, but it is admittedly
in a considerations section and not in standards action, and is a
weaker "SHOULD" versus "MUST" right now.

Would the WG prefer that a line like this be put into the Standards
Action section?

  When no authorities for a name are able to be reached, the resolver
  MUST attempt to refresh the delegation.

I like the basic idea but am a little stuck on the wording because of
the endless loop it implies.  This is probably why it appears as
"SHOULD" already (but I honestly don't remember, so there's that).

It seems to me that the risk is very low, even as currently written in
the draft.  Not only do I have a lot of confidence in the implementers
of the most widely used resolvers in the world, as they're right here
participating too and have in the past shown good conscientiousness in
this area, but the practical attack is still hard to make meaningful.
If "the parent has removed the C&C domain name" as you said,
serve-stale shouldn't even kick in.  NxDomain, problem solved.

Various other scenarios come to mind, even with obstinate parents that
won't remove the delegation and the zone's NSs have gone dark, but
those scenarios have other possible remedies.  And fast flux using
long TTL NS RRsets are an issue no matter whether serve-stale is in
play or not.

So text regarding refreshing delegations could be given even more
words to describe backoff intervals and such, but to what end?  What's
the scenario?  And wouldn't it be handled better by reviving
resimprove to talk about the generalized problem?

(To be clear, I'm quite okay with politely being shown that I'm wrong
and there is a vector by which serve-stale becomes uniquely
interesting, and would certainly endeavour to make sure it is addressed.)