Dear Shane, Sorry for my late reply and thanks a lot for your precious comments:)
Please see inline. BRs, Linda Shane Kerr <sh...@time-travellers.org> 写于 2015-07-03 21:43:06: > Shane Kerr <sh...@time-travellers.org> > 2015-07-03 21:43 > > 收件人 > > wang.c...@zte.com.cn, > > 抄送 > > suzworldw...@gmail.com, tjw.i...@gmail.com, > huang.sunli...@zte.com.cn, meng.w...@zte.com.cn, dnsop@ietf.org > > 主题 > > Re: [DNSOP] New Version Notification for draft-huang-dnsop- > synchronization-resolver-server-00.txt > > 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. //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? > > 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. //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. > > Cheers, > > -- > Shane > > On Fri, 3 Jul 2015 10:14:50 +0800 > wang.c...@zte.com.cn wrote: > > > 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 > > > > > > internet-dra...@ietf.org 写于 2015-07-03 09:46:46: > > > > > internet-dra...@ietf.org > > > 2015-07-03 09:46 > > > > > > 收件人 > > > > > > "Cui Wang" <wang.c...@zte.com.cn>, "Sunliang Huang" > > > <huang.sunli...@zte.com.cn>, "Cui Wang" <wang.c...@zte.com.cn>, "Wei > > > Meng" <meng.w...@zte.com.cn>, "Sunliang Huang" > > > <huang.sunli...@zte.com.cn>, "Wei Meng" <meng.w...@zte.com.cn>, > > > > > > 抄送 > > > > > > 主题 > > > > > > 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 > > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
