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

joel jaeggli <joelja@bogus.com> Thu, 31 March 2016 18:35 UTC

Return-Path: <joelja@bogus.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 463D612D68E for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 11:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 pbdAYvsVLreo for <dnsop@ietfa.amsl.com>; Thu, 31 Mar 2016 11:35:22 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE7812D6D5 for <dnsop@ietf.org>; Thu, 31 Mar 2016 11:35:22 -0700 (PDT)
Received: from mb-2.local ([216.9.108.44]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id u2VIZ0l4044497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 31 Mar 2016 18:35:02 GMT (envelope-from joelja@bogus.com)
To: abby pan <abbypan@gmail.com>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
References: <201603211441020416620@cnnic.cn> <20160325144328.GA19412@nic.fr> <CANLjSvXgBKA1+g5RfrL3w87a3CLsJ39wYaaAb00cwmdOz6Mj0Q@mail.gmail.com> <20160329134729.GA28195@nic.fr> <CANLjSvUvMusSPPHw9u=FD7YO0KAZvs9B0UtWboscCMG5VDycdA@mail.gmail.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <f152e300-ab31-49c0-2103-e300d2a5cfe5@bogus.com>
Date: Thu, 31 Mar 2016 11:34:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CANLjSvUvMusSPPHw9u=FD7YO0KAZvs9B0UtWboscCMG5VDycdA@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="E9EFqp19K7PGoWvd1BkGKknvwj3qtanN2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/vP0k5G3f0p0LS4o5mO_ptswTu_U>
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 18:35:25 -0000

On 3/31/16 6:18 AM, abby pan wrote:
> 
> 
> Stephane Bortzmeyer <bortzmeyer@nic.fr <mailto:bortzmeyer@nic.fr>>于2016
> 年3月29日周二 下午9:48写道:
> 
>     On Mon, Mar 28, 2016 at 05:38:01AM +0000,
>      abby pan <abbypan@gmail.com <mailto: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
> <http://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.

It actually can't really unless you're proposing that a recursive
resolver refuse to honor the ns/soa after ttl expiration. that makes it
rather hard to change providers, transfer zones or replace nameservers.
which are of course reasons why you would have a lower ttl on such
records anyway.

if you're suggesting that large content providers zones are sufficiently
ossified that they never change or are re/delegated well, that isn't true.

> 
>     > 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 <http://bortzmeyer.org>.
> 
>     Also, it seems you mix "important" with "often
>     queried". impots.gouv.fr <http://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
> <http://gov.cn>", “qq.com <http://qq.com>",  "baidu.com
> <http://baidu.com>",  "taobao.com <http://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 <http://xxx.qq.com>
> , help to correct or block it.
> -- 
> 
> Best Regards
> 
> Pan Lanlan
> Tel: +86 186 9834 2356
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>