Re: [DNSOP] New Version Notification for draft-liu-dnsop-dns-cache

abby pan <abbypan@gmail.com> Thu, 31 March 2016 13:42 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 6501A12D171 for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 06:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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] 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 elDmtTaHaL95 for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 06:42:26 -0700 (PDT)
Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (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 6FE7812D0EF for <dnsop@ietf.org>; Thu, 31 Mar 2016 06:42:26 -0700 (PDT)
Received: by mail-oi0-x241.google.com with SMTP id v67so1815047oie.0 for <dnsop@ietf.org>; Thu, 31 Mar 2016 06:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oV3n3uEqVYWlsJIYKDVb3kUigXf0M9YqmycJ33uksBQ=; b=Vr6WPCb5nXIrMpBztRecxkCzA1m03/pTom0sWxwOtevCx8xmsAvK5YmhHGbkbfmAOx Hf0myv/2IT+XH8QNqy1XW6mCl2IqXZHSAGIu/tWRHMh3XrToo1FRlNPMnvoSItFc19Oh 2aPwnrdOLi8b8EP3gxPVsGieyl9XSxLL5qsi8+4Ig0VJBSN4f0kJp6r6mARXbKoWEIFW UxAFzw/QTWYXmQFznRoFFamOp2o/R0KAnk2qM7zmklkkhHhZbDxHAtFEirAS20ok5PnA u+JJO0xNYneCeXniFYN0NlFQoCIG3Ntu9ChLG33mRDnz/Vinfn/fM+vYueMxrtI/I6ki AvvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oV3n3uEqVYWlsJIYKDVb3kUigXf0M9YqmycJ33uksBQ=; b=daaBK+Knnp+CTy6E28jLK7eeMP0vjv00rN+hFjxaMpnVmcSeRU+Z8zYYvlBj4tnYZW PPlImbIChXg6gGF2VM9detb9re9qAkoezk5i9OknjCw6ZlRpchjA/7bzd2nc+SHzmQAU zQCxZZA8rSQ23X2sU7NcU6ZG6F0YET3wBqa0Y5Ef7KNGKtF7vB3NN842+1f6ZLGQCPr0 YhY5lMd5xJy5S2nZsW+Wuypfk15yNho5qvYr0SQSns8hScAP+MdzZjbgM50uO1sIUfEf ZziZ2WSE2keuE1xQK8wPRDi0BlFaOkOrALRzpKIWfL6CzVOA5UUuCEbAFWmPXfV0AOMT ym5Q==
X-Gm-Message-State: AD7BkJLguVQDgprKRA8wLxT0Yx1G1BGfEP7AOc2TzHbs2cVM0Je/DmGN6Ja3MnltzI5h8oUmzt9/JcIRnPDByA==
X-Received: by 10.157.7.130 with SMTP id 2mr7808641oto.84.1459430292610; Thu, 31 Mar 2016 06:18:12 -0700 (PDT)
MIME-Version: 1.0
References: <201603211441020416620@cnnic.cn> <20160325144328.GA19412@nic.fr> <CANLjSvXgBKA1+g5RfrL3w87a3CLsJ39wYaaAb00cwmdOz6Mj0Q@mail.gmail.com> <20160329134729.GA28195@nic.fr>
In-Reply-To: <20160329134729.GA28195@nic.fr>
From: abby pan <abbypan@gmail.com>
Date: Thu, 31 Mar 2016 13:18:02 +0000
Message-ID: <CANLjSvUvMusSPPHw9u=FD7YO0KAZvs9B0UtWboscCMG5VDycdA@mail.gmail.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/alternative; boundary="94eb2c0443082a66f3052f581866"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/t9D1nZ5op84lkX5ZoGvDMea4wJI>
Cc: gengguanggang <gengguanggang@cnnic.cn>, 成 鹏 <max.ldp@alibaba-inc.com>, dnsop <dnsop@ietf.org>, "刘志辉(乘黄)" <chenghuang.lzh@alibaba-inc.com>, panlanlan <panlanlan@cnnic.cn>
Subject: Re: [DNSOP] New Version Notification for draft-liu-dnsop-dns-cache
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 31 Mar 2016 13:42:29 -0000

Stephane Bortzmeyer <bortzmeyer@nic.fr>于2016年3月29日周二 下午9:48写道:

> On Mon, Mar 28, 2016 at 05:38:01AM +0000,
>  abby pan <abbypan@gmail.com> wrote
>  a message of 246 lines which said:
>
> > 1) baofeng recursive ddos attack(2009):
> > http://www.pcworld.com/article/165319/article.html
>
> A more technical reference for this attack is the OARC talk
> <https://www.dns-oarc.net/files/workshop-200911/Ziqian_Liu.pdf>
>
> yes, in ziqian_liu's talk , they "Increase the TTL of baofeng.com related
RRs"  on the cache  to rescue


> > 2) baidu dns hijack(2010):
> >
> http://www.zdnet.com/article/baidu-dns-records-hijacked-by-iranian-cyber-army/
>
> This paper says it was purely social engineering on the registrar. No
> change in the DNS would help.
>

if cache can temporary prolong the ttl of baidu ns, that will help.


> > The selection is automatic, commonly TOP-N domain names.
>
> OK, so if I want my own personal vanity domain name to be well cached,
> I just have to hire a botnet to send many requests for bortzmeyer.org.
>
> Also, it seems you mix "important" with "often
> queried". impots.gouv.fr (the tax service) is important in France, if
> you cannot reach it, you'll not be able to pay and you wil be
> fined. But it does not see a lot of requests, typical people use it
> once a year.
>

yes,  simply online TOP-N is easy to around.

But the "hot" domain we can pre-set, as your example, like "*.gov.cn", “
qq.com",  "baidu.com",  "taobao.com" in china.

We manage the "most important" domain list, not just from dns query count,
but also the service data flow associated with the domain, also from some
company alliance.


> > How long will the SERVFAIL cache last usually depend on ISP network
> > bgp status, especially when recursive send dns query when the ns
> > server is in other ISP.
>
> You mean the name server has to know BGP?
>

I mean if cache server can check the NS BGP status with some addtional
module,  the rtt of dns query will be benefits.

But as Evan Hunt says, that's not "should" , but can be a choice.


>
> > The pre-fetching is something like link-fetching(
> > https://en.wikipedia.org/wiki/Link_prefetching ), shortten the response
> > time.
> > Again, pre-fetching is part of "backup cache" for ddos attack resuce or
> > baidu hijack rescue, etc.
>
> I did not say pre-fetching is bad, I said it does not require any
> change in the DNS server (it can be done from the outside).
>

I did not say that need change in the DNS server's normal task.

but it can be some additonal module to active when encounter ddos or hijack
( outside the normal case ) .


>
> > In "baofeng recursive ddos attack": short domain TTL + ns shutdown +
> > huge amount client fail and retry prolonging the TTL can partly
> > defense the attack.
>
> I did not say increasing the TTL is bad, I said it is a change in the
> protocol and therefore your draft has to declare it updates RFC 1034
> (and 1035).
>

same as above,  it can be some additonal module to active when encounter
ddos or hijack ( outside the normal case ) .

so that's not change in the protocol, not change the normal dns
query/response.

it's actived to  auto defense when huge count to 1s TTL suddenly rise.


>
> > Sometimes recursive receive hijack data (cache-poisoning attack).
> > if there is an security analysis module, users will more benefits.
>
> If it is just asserting the validity of data before returning it to
> the user, what do you need besides the already existing RFC 2181
> (section 5.4.1) and RFC 5452 (specially sections 6 and 9)?
>

again, it is not change the protocol, but some additional module to
validate the data in cache dns operation.

comodo, opendns has give the protect service :
http://www.computerworld.com/article/2872700/6-dns-services-protect-against-malware-and-other-unwanted-content.html

for example, detect hijack phishing ip of xxx.qq.com , help to correct or
block it.
-- 

Best Regards

Pan Lanlan
Tel: +86 186 9834 2356