Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale

神明達哉 <jinmei@wide.ad.jp> Fri, 08 September 2017 20:11 UTC

Return-Path: <jinmei.tatuya@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 D4367132811 for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 13:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 nP1IMKFdicAB for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 13:11:29 -0700 (PDT)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 551BA1321E6 for <dnsop@ietf.org>; Fri, 8 Sep 2017 13:11:29 -0700 (PDT)
Received: by mail-qt0-x235.google.com with SMTP id i50so9114757qtf.0 for <dnsop@ietf.org>; Fri, 08 Sep 2017 13:11:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/c0Xx6IPqHumFEfcfs8eWML1KFwp5AJMOWe9WiwctdI=; b=ksZtX+FFmmmHoBNarDxekZcYsMPa5P9ck9yVTWHTOraqW/AG5HayvgZBAxGGKOoVZ3 T3WrUIZxQ6v6WALpIoN7LmipZlE/7B09CiFgAm/Jq3cOeogk2veNHxOLLQjQ2+CbAPEz jfNQr7sVxI43N8PaxNIJDYw1Ekz+5Hgog9SEi/U6kM8d3DhGxBiHBWuuYcN/mYBaiJGj fMQmZU17C2x1AE+W3F+k9ewaQanoQHDyYozeFh3U0fNXI46ZXRBNMXBA3ijZGcdAjJXu 9mR8FLZr9BetHpJ3SrhIejuC9Y++GnyzV9Y+8I5PjlPbsmgaBBIRZPliYaaPy9RQyrxV 0NvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/c0Xx6IPqHumFEfcfs8eWML1KFwp5AJMOWe9WiwctdI=; b=kaec5wS8S8K09taTXJCRO82PEFmau0n9RvKuaaCigZKqYcAYeF1eeV8kx6nBUQxj27 GgQr6w+lxYjOoJZHKiLaRS/zTmMjRNFM705toHZGmdnuXvkmLvv3ngqC0yMT3mJ5en6d WrFr40gNvs2WuhA0a/Vd/fKH8q6ekKMg+RlbYtouJxpG46SfKroyXmQIwdZXS4DbqSv/ cIlrOrUMP9ZvKMfBtDCuwdpRikqNqAtDlrAG/d0lxZtApaJgwipF3KVzgC6GsxM6uBRW inQA7jJueE+cA3eg83ucsv73xXtmEa3jc2oNXmXsxjmJoTk9WGvPJUbbuYp4k/3O0Wiy 1BBQ==
X-Gm-Message-State: AHPjjUhytN1jH2EiiU9T3J7hkkAsVwJi+ghhEX/0sjdx4aoj8/br50nE ERuDWiZKXkHpeYCWMLkhBXYYA55+XHHuPwM=
X-Google-Smtp-Source: AOwi7QDUjmxQ6OnInnj2R+MWoTs46p9AxVHwdAa4PaCnj7BU7qSY65f5miBvtxO9GP/zBx3iV316QfKxSTZsj1/SCEM=
X-Received: by 10.200.49.232 with SMTP id i37mr6108520qte.281.1504901488339; Fri, 08 Sep 2017 13:11:28 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.200.54.104 with HTTP; Fri, 8 Sep 2017 13:11:27 -0700 (PDT)
In-Reply-To: <8826934.gJBl6qSRLR@localhost.localdomain>
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <ybltw0emmvh.fsf@wu.hardakers.net> <CAJE_bqc9zD3Um2oWri7K3L10=MWrUrKpCHpmUGAADKUmFmPYCg@mail.gmail.com> <8826934.gJBl6qSRLR@localhost.localdomain>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Fri, 8 Sep 2017 13:11:27 -0700
X-Google-Sender-Auth: 2KakQipTbgMKBcQfYtmKodczEz8
Message-ID: <CAJE_bqeDdtgsC7pZ8TcxufuimbLBU0t+xJKV1VL+OJui8G9wLw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F0Jd8pBoCIIm9FNv5gXpgdmQEw4>
Subject: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 08 Sep 2017 20:11:31 -0000

At Thu, 07 Sep 2017 13:42:45 -0700,
Paul Vixie <paul@redbarn.org> wrote:

> > If we don't work on a proposal like this, I'd love to see a specific
> > counter proposal that doesn't violate the current protocol
> > specification (i.e., using a cached answer beyond its TTL) and still
> > avoids resolution failure when authoritative servers are forced to be
> > non-responsive due to huge scale DoS attacks.
>
> i think the actual problem statement is broader, and that by solving for this
> narrow version, we would lose the complexity/capability tradeoff -- we'd add
> more state and more signaling at a cost higher than what we would get for it.

I'm not sure specifically what you mean by these, but...

> it's a general reachability problem not specifically ddos problem. reasons for
> not being able to refresh data in a cache include ddos, but also backhoes,
> wire cutters, squirrels, circuit breakers, and bad design/provisioning.

...I agree here.  I'm well aware of the generic nature of the issue,
but I mentioned one specific instance of the problem in my previous
message just because that's the most obvious one.

> i think the right answer will look like a miniature version of IXFR/AXFR and
> NOTIFY, such that a cache can register its intent to become a partial stealth
> secondary server, and by participating, an authority server can both indicate
> its willingness to have this done, and possibly remember what was transmitted
> so as to facilitate subsequent cache invalidation or zone change notification
> messaging. one could even imagine a dns cookie exchange at the outset, to help
> authenticate later messages. sort of a super-lightweight session protocol.

I guess we are also on the same page in a sense here.  One possible
justification for a behavior like draft-tale-dnsop-serve-stale is that
it can be considered a recursive server variant of a secondary
authoritative server that keeps using primary's zone content even if
the auth server is unreachable for a certain period (until, of course,
the entire zone expires).  If this makes some sense, we may be able to
develop a cleaner solution than serve-stale by expanding the
observation.

I'm not necessarily a fan of the specific approach described in
draft-tale-dnsop-serve-stale, but I have to admit it's a practical
workaround (if not a "solution") for a real-world problem happening
today.  I'd be happier if the wg agrees on working on a better
solution, but in that case we should also be pragmatic.  That includes
the recognition that any protocol extension that requires changes to
both recursive and authoritative servers will take quite long to
deploy.  Since the problem is real and current, the solution should
have an intermediate state that might look a mere hack.

--
JINMEI, Tatuya