Subject: Re: [DNSOP] New Version Notification for draft-huang-dnsop-synchronization-resolver-server-00.txt

From: [email-masked]
Date: Fri, 3 Jul 2015 10:14:50 +0800

Dear Suzanne & Tim,

  I have just submitted a new draft which tries to work out how to 
synchronize the RRs information between resolvers and DNS servers.
The link is as follow and I would like to request a 5-min slot in
the upcoming f2f meeting. Would you please keep it in mind and try to 
give me a chance to present it? 

( 
https://www.ietf.org/internet-drafts/draft-huang-dnsop-synchronization-resolver-server-00.txt
, 5 minutes, Linda Wang)

 Thanks very much:) 

Best Regards,
Linda Wang

[email-masked] 写于 2015-07-03 09:46:46:

> [email-masked] 
> 2015-07-03 09:46
> 
> 收件人
> 
> "Cui Wang" <[email-masked]>, "Sunliang Huang" 
> <[email-masked]>, "Cui Wang" <[email-masked]>, "Wei
> Meng" <[email-masked]>, "Sunliang Huang" 
> <[email-masked]>, "Wei Meng" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> New Version Notification for draft-huang-dnsop-synchronization-
> resolver-server-00.txt
> 
> 
> A new version of I-D, 
draft-huang-dnsop-synchronization-resolver-server-00.txt
> has been successfully submitted by Cui Wang and posted to the
> IETF repository.
> 
> Name:      draft-huang-dnsop-synchronization-resolver-server
> Revision:   00
> Title:      Synchroniztion between resolvers and servers
> Document date:   2015-07-02
> Group:      Individual Submission
> Pages:      14
> URL:            https://www.ietf.org/internet-drafts/draft-huang-
> dnsop-synchronization-resolver-server-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-huang-dnsop-
> synchronization-resolver-server/
> Htmlized:       https://tools.ietf.org/html/draft-huang-dnsop-
> synchronization-resolver-server-00
> 
> 
> Abstract:
>    This document proposes how to synchronize the RRs in the resolvers
>    along with the RRs in the authoritative servers when changes are
>    occurred on the RRs in the authoritative servers.
> 
>  
> 
> 
> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Shane Kerr <[email-masked]>
Date: Fri, 3 Jul 2015 13:43:06 +0000

Linda,

I think this idea has merit and is worth exploring (I had something
like this in mind while brainstorming at the microphone at the recent
DNS-OARC workshop).

I would suggest that it is not necessary to add a special message from
the resolver to the authoritative server to indicate that it has cached
information. We may be able to save a round trip by instead using an
EDNS option in the question message, letting the authoritative server
know that the resolver intends to cache the information and will be
willing to clear the cache if the server asks it to.

I don't think the authority server ever needs to actually send the new
data, only to request that the resolvers remove entries from cache
(including negative entries). The resolver can re-fetch records and
cache them normally at that point.

There are a lot of security considerations here.

On the resolver side, there needs to be a way to insure that only the
authoritative server can clear cache entries. I am not 100% sure, but I
think that if a resolver saves the IP address that it got a given RR
from, and requires either TCP or DNS cookies on the cache clearing
message, that this will be prevented.

On the authoritative side I think there are more concerns.

First, there needs to be a way to prevent both reflection and
amplification attacks. Again, I think TCP or DNS cookies is probably
sufficient for this, and should be a requirement.

Second, how can the authoritative server limit the amount of entries
that it contains? For example, if an attacker has a /48 of IPv6 space,
then how do we prevent that attacker from registering more and more
synchronized resolvers, causing resource exhaustion on the
authoritative server?

A similar attack is possible for servers with lots of owner names
(either by having large zones or lots of small zones). For example, an
attacker who knows a lot of these names can request notification of each
of those names, which will take a lot of state on the server, and also
possibly create a huge number of outbound packets. This can possibly be
avoided by either limiting the total number of notifies registered per
resolver, or perhaps by making the notification per *server* rather
than per RR (the second one will have a cost because it may mean
removing a *lot* of records from a resolver cache). 

Finally, I think the guarantees need to be made explicit. We should not
count on authoritative servers honoring the request for notification,
either due to reboots or administrative preferences or other reasons.

Interesting stuff! :)

Cheers,

--
Shane

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jul 2015 15:59:45 -0400 (EDT)

> cache them normally at that point.

How will this work with resolvers behind NAT?

> message, that this will be prevented.

A local attacker could still flush your cache and (re)attempt to poison
you. In fact, you almost have to mandate DNSSEC for any data to be
allowed to get flushed, or else cache poisoning becomes very easy.

> synchronized resolvers, causing resource exhaustion on the

And since none of this information can be transmitted via chained
resolvers, the authoritatve servers have to keep track of all clients?
Which is a new privacy concern.

I feel unpublishing DNS data should not be faciliated in this way. Use
short TTLs. Or on the client side you can enforce a max-ttl to force
your local resolver to never cash for longer than X amount of time.

There was also other work related to this, something draft-redbutton ?

Paul

---

From: Paul Vixie <[email-masked]>
Date: Mon, 06 Jul 2015 16:30:06 -0700

[email-masked] wrote:
> https://www.ietf.org/internet-drafts/draft-huang-dnsop-synchronization-resolver-server-00.txt,
> 5 minutes, Linda Wang)
>
>  Thanks very much:)  
>
> Best Regards,
> Linda Wang

i have read this draft and i disagree with its problem statement as well
as its proposed approach.

cache invalidation cannot be centralized across tens of millions of
recursive servers. it's too much state load and too much traffic for the
authorities.

ultradns, google, opendns, and others have a cooperative approach to
cache invalidation which reportedly works fine for the large rdns operators.

http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/ (now
expired) provides a scalable method of cache invalidation (has no state
load and adds no traffic).

draft-huang-dnsop-synchronization-resolver-server-00.txt is the wrong
approach to the wrong problem.

-- 
Paul Vixie

---

From: [email-masked]
Date: Wed, 15 Jul 2015 09:20:25 +0800

Dear Shane,

  Sorry for my late reply and thanks a lot for your precious comments:)

  Please see inline.

BRs,
Linda

Shane Kerr <[email-masked]> 写于 2015-07-03 21:43:06:

> Shane Kerr <[email-masked]> 
> 2015-07-03 21:43
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked]
> 
> 主题
> 
> Re: [DNSOP] New Version Notification for draft-huang-dnsop-
> synchronization-resolver-server-00.txt
> 
> Linda,
> 
//Linda：How does the authority server send this request to the resolvers? 

It seems relatively simple if the authority server sends the update 
message 
to the resolvers with just one message exchange, rather than sending a 
request first
removing the entries next, and re-fetch the new records and get the 
response with new records.
> There are a lot of security considerations here.
//Linda: As for security considerations, I am totally agreed with you. But 
I
am not good at expertise about security technology, so about this security 
section 
I need someone to cooperate with. I am very glad if you would like to work 
out this section?
> either due to reboots or administrative preferences or other reasons.
//Linda: In fact, if we can solve the security issues you mentioned above, 

I think it is not a problem to count on authority servers honoring the 
notification:)
So after we confirm the issue proposed in this draft, then we can discuss 
the solutions and the security issues step by step:)

> Interesting stuff! :)
//Linda: Thanks for your agreement.

---

From: [email-masked]
Date: Wed, 15 Jul 2015 09:43:36 +0800

Dear Stephane,

  Thanks a lot for your comments.

  Please see inline.

BRs
Linda

Stephane Bortzmeyer <[email-masked]> 写于 2015-07-04 04:22:43:

> Stephane Bortzmeyer <[email-masked]> 
> 2015-07-04 04:22
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> Re: New Version Notification for  draft-huang-dnsop-synchronization-
> resolver-server-00.txt
> 
> On Fri, Jul 03, 2015 at 10:14:50AM +0800,
>  [email-masked] <[email-masked]> wrote 
>  a message of 143 lines which said:
> 
> I have two serious concerns with this draft. The most important one is
> that I do not see an use case. DNS is and has always been "loosely
> consistent". It was never envisioned that a change in the
> authoritative name servers would be reflected "instantaneously" in
> every resolver. If someone wants faster changes, he can always use
> (reasonable) short TTLs. So, you really should add a section
> explaining what is the use case.
//Linda: Yes, I agree with you. Next version, we plan to add one or two 
use cases to 
highlight the issue proposed in this draft. Then we can continue our 
discussion 
whether the solution is OK.
> 
> The second concern comes from the observation that authoritative name
> servers are fast and very resilient because they don't keep
> state. Asking them to memorize all their clients, in order to notify
> them later of a change in the data, is a sure way to weaken them.
//Linda: If we can confirm this issue is sure to exist. There should be a 
feasible solution to leverage it and then we can work out it.

Thanks a lot:)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 15 Jul 2015 16:14:31 +0200

On Wed, Jul 15, 2015 at 09:43:36AM +0800,
 [email-masked] <[email-masked]> wrote 

>   Thanks a lot for your comments.

By the way, my message was *not* distributed on dnsop, for unknown
reasons (I've pinged the chairs).