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

Lanlan Pan <abbypan@gmail.com> Sat, 09 September 2017 02:05 UTC

Return-Path: <abbypan@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 6FB801241FC for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 19:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 t3T12OuQSdw6 for <dnsop@ietfa.amsl.com>; Fri, 8 Sep 2017 19:05:10 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 05EFC132195 for <dnsop@ietf.org>; Fri, 8 Sep 2017 19:05:10 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id f199so12802548wme.0 for <dnsop@ietf.org>; Fri, 08 Sep 2017 19:05:09 -0700 (PDT)
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=IyAOaIh3RZnt082PAj/OOShr1Ca1x6sWasB+iKMz0mA=; b=fuL0y/m3rsz19LUKVYyx3VBCij6hKcViPA0Wsr4uY9vCpn1m8sHlr16ujCSwfvWMUM uuG5O6yu45VBY+ZagFpmeoskGPvuzdNu8a2qL1gFi4jKCqtjmRw5/lBlq2N5xI7TFYaK RBBvUxvkLHShwOYVCd1F6f7VWNFNAahuJzPbllNgHvDMt+/R1o5f1Y+NkEgyiAOSBMfW woxq/7GbclWbNPAxS0972seZf5H6Vh+wFw3euzOr1CYt/a2Z7//BWXrkPZAcgtx+3yZ4 0ImrSoHna1gWVx9SMxLrXD5H1sXa5qvRY37ZJONFR55xMVOFQ7XyWejoiKT3xfqZrXaG XBxQ==
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=IyAOaIh3RZnt082PAj/OOShr1Ca1x6sWasB+iKMz0mA=; b=hXhhvM/FXkUWcngV9faFFTMfAa4gLDhU/yWXM5OCGkd+BIqKhr0kdGM5XpADhZsr3i QlXKDrejWWzsNd3fEtLRoooUl3ZxaQ7TFQH/vrW1qnk4BKZmtK7sC6BWfQ7i015G3c39 rnBFERUIRXUblLybLC1vTrE5WDv4JG1PTWJDtLT/KZyc9Ha5nmPc+v+hStq5XWBbph37 5N7CqsiA/jwQLVM4XVINKfJYNEMnqzG5xOUAD7Ce6LkJX8RH+7+jKuN7hEfv/qc2ozEb VzkBj3l95Q4XRYD3qfZQOkRMtirksxLeWMxMRuiuR7PPlPvhivbYXFvpyJX1xZQ/x3sN JMpg==
X-Gm-Message-State: AHPjjUj9Jg2EMLRaZPVx+cknqFLH7E3qtnwMs4byyb9IScgI/j+Mu9xB AC2zNqqkt5JPOuF2vdWk4P+pjQ2BKQ==
X-Google-Smtp-Source: ADKCNb7iZp0STVLAAoW+GNeO5cpgyGUoI9OrqvqDvMYZ5OetDuCEd8lQeD+hYAQjU5PfsTC4WBWF4JHri1FxpgnXess=
X-Received: by 10.80.152.43 with SMTP id g40mr3615389edb.300.1504922708563; Fri, 08 Sep 2017 19:05:08 -0700 (PDT)
MIME-Version: 1.0
References: <CADyWQ+FHDHcmq-mr0BCHS5A8yvaOQmhTjve1_DmZN6vAc=BKyA@mail.gmail.com> <20170907154234.3z2zbju2sciiy7wr@nic.fr> <59b25fe5.a516c80a.c19c8.40e0SMTPIN_ADDED_BROKEN@mx.google.com>
In-Reply-To: <59b25fe5.a516c80a.c19c8.40e0SMTPIN_ADDED_BROKEN@mx.google.com>
From: Lanlan Pan <abbypan@gmail.com>
Date: Sat, 09 Sep 2017 02:04:57 +0000
Message-ID: <CANLjSvVePwqDgf6JBG=me85wLydcbS7+EOeuzQ5=2nEBpdy4RQ@mail.gmail.com>
To: =?UTF-8?B?RGF2ZXkgU29uZyjlrovmnpflgaUp?= <ljsong@biigroup.cn>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, tjw ietf <tjw.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="f403045c1884755f270558b81fc2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FWntMPSfg0UYkoZ0yCs1c1CWIYU>
Subject: Re: [DNSOP] =?utf-8?b?562U5aSNOiBETlNPUCBDYWxsIGZvciBBZG9wdGlvbiAt?= =?utf-8?q?_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: Sat, 09 Sep 2017 02:05:12 -0000

Davey Song(宋林健) <ljsong@biigroup.cn>于2017年9月8日周五 下午5:16写道:

> I just notice it asks for "Standards Track" document. If it aims to
> introduce a special use of resolver to achieve some features for their
> users' benefit, I think informational document may be more appropriate ? I
> guess, like what RFC7706 does.
>

+1,  I support the adoption of this document if it is informational.

recursive can choose to support this "cache operation improvement feature"
or not, but not update 1034/1035's TTL definition.

recursive may use stale data/extend the TTL for some special scenario, for
example:

==not ddos attack==
1)  some domains' A TTL are set to 1s, and they will not change it, because
they think that will help new RR spreads faster...
recursives offen have to extend the TTL = 90s or 600s or 3600s.

2)  network temporary failure on resolution path ( recursive ->
authoritative ) , SERVFAIL / TIMEOUT, offen short time
trigger some "use stale bread" callback function to deal with the
SRRVFAIL/TIMEOUT failure,  the data is snapshot from online hot cache
LRU/cache aging heuristic.

==ddos attack==
3)  recursive encounter ddos attack
trigger "proxy top-N important domain's dns response" on the ddos
firewall,  the top-N important domain's data is generated from the whole
latest-M days query log.

4) important SLD authoritative encounter ddos attack
SLD authoritative wants recursives trigger above 2) solution on its hot
domains, for its most visited service.
SLD authoritative wants recursives have some knowledge about its subdomain
wildcards, to avoid not-visited subdomain wildcard failure.


> Davey
>
> > -----邮件原件-----
> > 发件人: DNSOP [mailto:dnsop-bounces@ietf.org] 代表 Stephane Bortzmeyer
> > 发送时间: 2017年9月7日 23:43
> > 收件人: tjw ietf
> > 抄送: dnsop
> > 主题: Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
> >
> > On Tue, Sep 05, 2017 at 03:25:39PM -0400,  tjw ietf <tjw.ietf@gmail.com>
> > wrote  a message of 77 lines which said:
> >
> > > This starts a formal Call for Adoption for
> > > draft-tale-dnsop-serve-stale
> > >
> > > The draft is available here:
> > > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/
> >
> > I'm not enthousiastic. We should focus on making the DNS infrastructure
> more
> > reliable, not on adding something to a pile of already fragile protocols.
> >
> > There is also an opportunity that it masks failures and prevents people
> from
> > properly assigning blame: "example.com works if I use Something Public
> DNS
> > but not if I use my ISP's resolver, therefore my ISP is broken".
> >
> > Also, the current draft does not make crystal-clear that stale data MUST
> NOT
> > be served unless no authoritative name server replies.
> >
> > If it is adopted, I think that requesting some way to convey the fact it
> is stale to
> > the client (Davey Song's message) is necessary.
> >
> > Regarding the draft, I'm surprised by the paragraph starting with "Paul
> Vixie
> > has suggested", paragraph which seems to completely ignore RFC 8020.
> >
> > _______________________________________________
> > 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
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan