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

From: "Z.W. Yan" <[email-masked]>
Date: Mon, 21 Mar 2016 14:41:02 +0800

Hi, Guys,
A new draft about the operation of DNS cache service was just posted.
https://www.ietf.org/internet-drafts/draft-liu-dnsop-dns-cache-00.txt
This is an initial version and needs more details, so we welcome any DNS operator who has interest to join in to make this work more comprehensive.
Thanks.

2016-03-21 

Z.W. Yan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 25 Mar 2016 15:43:28 +0100

On Mon, Mar 21, 2016 at 02:41:02PM +0800,
 Z.W. Yan <[email-masked]> wrote 

> This is an initial version and needs more details, so we welcome any DNS operator who has interest to join in to make this work more comprehensive.

I've read it, noticed that it is not just a documentation of local
practices but it wants to be published as BCP, and:

* it is not clear which problem it is trying to solve.

* the whole idea of a "backup", long-term cache (section 3) is
  questionable and I do not find a rationale for it.

* it seems to recommend (section 4) that there is some manual
  selection of domains that must be cached (instead of the fully
  automatic system of the typical current cache), and, again, there is
  no rationale and no discussion.

* caching SERVFAIL, as recommended (section 4), raises an interesting
  question: for how long? (Unlike NXDOMAIN, SERVFAIL answers do not
  provide an indirect TTL)

* if someone really wants to do "pre-fetching" (section 5), it does
  not require a new RFC or an update of the name servers. Just request
  the names you want, through the resolver/cache.

* prolonging the TTL (section 5) is a violation of the RFC
  protocol. Or a change but, in that case, it is no longer a BCP
  document, it updates RFC 1034 and 1035.

* the selection of the order of answers by "RTT detection" (section
  6)deserves more detail. RTT of what? ICMP echos to the address in
  the data part?

* the recomandation to filter data before returning it to the client
  (section 7) is a violation of infrastructure neutrality and
  certainly cannot be recommended without more explanations.

---

From: Tony Finch <[email-masked]>
Date: Sat, 26 Mar 2016 21:36:04 +0000

> * it is not clear which problem it is trying to solve.

Thanks Stephane. I agree with your observations, with a couple of
amendments...

>   question: for how long? (Unlike NXDOMAIN, SERVFAIL answers do not

This is a feature of the forthcoming BIND 9.11. The default servfail-ttl
is one second. (I don't know if other servers have a similar feature.)

https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=CHANGES;hb=refs/heads/master#l1370

>   the names you want, through the resolver/cache.

There was https://tools.ietf.org/html/draft-wkumari-dnsop-hammer which
seems to have been dropped through lask of interest. I think this is a
terrible shame, but I'm biased because of the first sentence of section 9.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy: Westerly or southwesterly 7 to severe gale 9, perhaps storm 10 later.
Very rough or high, occasionally very high later in northwest. Rain or
showers. Moderate occasionally poor.

---

From: Evan Hunt <[email-masked]>
Date: Sun, 27 Mar 2016 03:03:57 +0000

> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=CHANGES;hb=refs/heads/master#l1370

SERVFAIL caching is permitted by RFC 2308 for up to five minutes.  It's
described as optional there.  I don't think it's a good idea to use the
word "should" in this new draft.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 27 Mar 2016 20:28:04 +0000

So, most implementations do some sort of prefetch thing now, and so the
primary purpose of "hammer" has been achieved. But, I think it is still
worth documenting the behavior. I'm planning on updating and then asking
DNSOP to adopt and then publish this sometime...

W

On Sat, Mar 26, 2016 at 5:36 PM Tony Finch <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Mar 2016 02:21:27 +0530

From the draft:

> 5.  Update of cached data
>
> In order to maintain the data freshness, the cache should be updated
> continually based on the behavior of stub resolvers or the statistics
> of domain names.  For the former case, the data is updated when the
> stub resolver requests the specified domain name.  While for the
> latter case, the recursive server pre-fetches the hot domain names
> before expiration and updates them actively.
		  
FWIW, Shane, Stephen and I have been sorting out the details of
opportunistic whole zone cache refresh, an alpha draft version of which
can be found here:

https://github.com/muks/dnsrefresh/blob/master/draft-muks-dnsop-opportunistic-refresh.xml

As the SOA serial is usually meaningful in the context of zone
transfers, we're still discussing the details of why, what, how, etc. It
should've been ready by this IETF, but hopefully we'd have completed an
initial draft by the next one. Feedback to the idea so far has been
mixed.

		Mukund

---

From: abby pan <[email-masked]>
Date: Mon, 28 Mar 2016 05:38:01 +0000

Thanks a lot for Stephane's comments, we will give more explanations in
next version, :-)

Some backgroud information as follows:

Stephane Bortzmeyer <[email-masked]>于2016年3月25日周五 下午10:44写道：

> We are trying to give some recommendations on DNS cache service practice,
make some operation risk plan which can help to deal with DNS security
issues, make better effort to improve internet stability.
For example:
1) baofeng recursive ddos attack(2009):
http://www.pcworld.com/article/165319/article.html
2) baidu dns hijack(2010):
http://www.zdnet.com/article/baidu-dns-records-hijacked-by-iranian-cyber-army/
3) CN tld ddos attack(2013):
http://www.computerworld.com/article/2484097/internet/major-ddos-attacks--cn-domain--disrupts-internet-in-china.html

>   questionable and I do not find a rationale for it.
When Root/TLD suffering DDoS attack, recursive can use "backup cache" for
some rescue.

>   no rationale and no discussion.
The selection is automatic, commonly TOP-N domain names.
The selected TOP-N domain names are different based on respective online
service log and scale.
discussion :
https://www.ietf.org/archive/id/draft-wang-dnsop-cachesurvey-00.txt

> 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.
For example, Old J-Root appears to still receive “legitimate” queries 13
years after it was removed from root hints. (
https://indico.dns-oarc.net/event/24/session/10/contribution/10/material/slides/0.pdf)

Similarly, some SERVFAIL will last more than 1 month.

> 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.

> In "baofeng recursive ddos attack": short domain TTL + ns shutdown + huge
amount client fail and retry prolonging the TTL can partly defense the
attack.

> That is Name server selection.
something like
http://newsgroups.derkeiler.com/Archive/Comp/comp.protocols.dns.bind/2010-09/msg00071.html

> Sometimes recursive receive hijack data (cache-poisoning attack).
if there is an security analysis module, users will more benefits.

-- 

Best Regards

Pan Lanlan
Tel: +86 186 9834 2356

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Mar 2016 15:47:29 +0200

On Mon, Mar 28, 2016 at 05:38:01AM +0000,
 abby pan <[email-masked]> wrote 

> 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>

> 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.

> 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.

> 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? 

> 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).

> 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).

> 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)?

---

From: abby pan <[email-masked]>
Date: Thu, 31 Mar 2016 13:18:02 +0000

Stephane Bortzmeyer <[email-masked]>于2016年3月29日周二 下午9:48写道：

> yes, in ziqian_liu's talk , they "Increase the TTL of baofeng.com related
RRs"  on the cache  to rescue

> change in the DNS would help.

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

> fined. But it does not see a lot of requests, typical people use it

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.

> 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.

> 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 ) .

> protocol and therefore your draft has to declare it updates RFC 1034

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.

> (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

---

From: joel jaeggli <[email-masked]>
Date: Thu, 31 Mar 2016 11:34:55 -0700

On 3/31/16 6:18 AM, abby pan wrote:
> 
> 
> Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>>于2016
> 年3月29日周二 下午9:48写道：
> 
>      abby pan <[email-masked] <mailto:[email-masked]>> wrote
> yes, in ziqian_liu's talk , they "Increase the TTL of baofeng.com
> <http://baofeng.com> related RRs"  on the cache  to rescue
>  
> 

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.

>     I just have to hire a botnet to send many requests for
>     bortzmeyer.org <http://bortzmeyer.org>.
> 
>     queried". impots.gouv.fr <http://impots.gouv.fr> (the tax service)
>     is important in France, if
> 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.
> 
> 
> but it can be some additonal module to active when encounter ddos or
> hijack ( outside the normal case ) .
>  
> 
> 
> 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
> 
>

---

From: abby pan <[email-masked]>
Date: Thu, 31 Mar 2016 19:10:03 +0000

joel jaeggli <[email-masked]>于2016年4月1日周五 上午2:35写道：

> yeah,  totally aggree with you, we all want the change of ns  RR can
spread fast with short ttl in normal case.

the prolong ttl action is actived on "rescue case" as above:
when cache encounter  "baidu.com" 's new ns record (hijack),  and almost
all *.baidu.com 's query is fail through the "new" ns.
cache can roll back to "old"  ns of baidu.com, and prolong the ttl, to
ensure the success dns query.

normal ns change is not affected.
-- 

Best Regards

Pan Lanlan
Tel: +86 186 9834 2356