Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
Hi, Stephane, Sorry for the delayed response. Please find the in-line answers and welcome your further comments: * the draft gives the impression that it authorizes a new behaviour. But auth. servers have been sending extra data (IP address of a MX target, for instance) for years. #Z.W. Yan: Yup, auth servers have been including extra data for a long time, but only certain sets of information -- things like IP for MX, CNAME followups, etc. They haven't really been sending other answers, not strictly in support of the original query. This is because receivers have not been willing to accept this, *because they cannot trust it*. Basically what we are saying is, now that DNSSEC exists, resolvers can trust data in the additional section, so it is worth sending it again... * the draft says these extra data MUST (RFC2119-MUST) be validated with DNSSEC. Does it mean that the current behaviour of sending extra data for unsigned zones is now illegal? #Z. W. Yan: Not illegal, as explained above, if we want to make well use of this function, we need to guarantee its security. * followup off the previous question] should we instead say that extra data should be sent (and should be accepted by clients) if and only if (DNSSEC-validated _or_ in-bailiwick)? The current behaviors of resolvers (accept extra data if in-bailiwick) does not seem to be mentioned. #Z. W. Yan: The background of the current situation will be added in the next version. * the draft says "an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache". This is very dangerous because people may read it "we now have a sure way to control what ends in the resolver's cache" which is clearly not the case (the resolver may refuse some of the extra data, the TTL of the extra data may mae it expire before the "main" data, etc). #Z. W. Yan: we will revised it as: "an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache from the authoritative point of view". BR, Zhiwei YAN ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-01.txt
Hi, Stephane, Sorry for the delayed response. Please find the in-line answers and welcome your further comments: * the draft gives the impression that it authorizes a new behaviour. But auth. servers have been sending extra data (IP address of a MX target, for instance) for years. #Z.W. Yan: Yup, auth servers have been including extra data for a long time, but only certain sets of information -- things like IP for MX, CNAME followups, etc. They haven't really been sending other answers, not strictly in support of the original query. This is because receivers have not been willing to accept this, *because they cannot trust it*. Basically what we are saying is, now that DNSSEC exists, resolvers can trust data in the additional section, so it is worth sending it again... * the draft says these extra data MUST (RFC2119-MUST) be validated with DNSSEC. Does it mean that the current behaviour of sending extra data for unsigned zones is now illegal? #Z. W. Yan: Not illegal, as explained above, if we want to make well use of this function, we need to guarantee its security. * followup off the previous question] should we instead say that extra data should be sent (and should be accepted by clients) if and only if (DNSSEC-validated _or_ in-bailiwick)? The current behaviors of resolvers (accept extra data if in-bailiwick) does not seem to be mentioned. #Z. W. Yan: The background of the current situation will be added in the next version. * the draft says "an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache". This is very dangerous because people may read it "we now have a sure way to control what ends in the resolver's cache" which is clearly not the case (the resolver may refuse some of the extra data, the TTL of the extra data may mae it expire before the "main" data, etc). #Z. W. Yan: we will revised it as: "an authoritative name server operator can ensure that the recursive server that the client is using has all the answers in its cache from the authoritative point of view". BR, Zhiwei YAN ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
About the DDoS risk, it should not be worried so much because this scheme is controlled/triggered by the recursive server (with a flag as NN bit). In other words, the recursive server can get the piggybacked multiple responses only when it wants and of cource it can disable this model anytime. Another scenario to illustrate this proposal is under the DANE case: A client wants to visit www.example.com. But this domain name supports DANE can the TLSA record is configured under the domain name: _443._tcp.www.example.com. The client has to query the two names seperately. Yes, it is just one more TTL, but why not to do the optimization with a steerable method. Zhiwei Yan___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Good morning, Ralf. At 2016-07-20 13:07:01, "Ralf Weber" wrote: >Moin! > >On 20 Jul 2016, at 5:03, 延志伟 wrote: > >> About the DDoS risk, it should not be worried so much because this >> scheme is controlled/triggered by the recursive server (with a flag as >> NN bit). >> In other words, the recursive server can get the piggybacked multiple >> responses only when it wants and of cource it can disable this model >> anytime. >That's not who DDos work. If attacker would only do what the specs say >we wouldn't have any DDos. But an attacker can just create an UDP packet >with that bits and a spoofed address and fire it off (or get a botnet to >fire it off). I understand your points, but these risks always be there because DNS response is larger than the request, like DNSSEC. How to avoid DNS DDoS is anther problem. >> Another scenario to illustrate this proposal is under the DANE case: >> A client wants to visit www.example.com. >> But this domain name supports DANE can the TLSA record is configured >> under the domain name: _443._tcp.www.example.com. >> The client has to query the two names seperately. >> Yes, it is just one more TTL, but why not to do the optimization with >> a steerable method. >Again if example.com is popular almost all the time this record will be >in the cache already. Anyway, the cache should get the data fist and then it can cache them. :-) >So long >-Ralf Zhiwei Yan___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Hi, Ralf, We understand your worries and these negative effects can be fixed or descended in the next version. But anyway, let's go back to the scenario considered by our draft to illustrate its necessity. I show an example as following (although I think we have described it several times. :-)): In order to visit the www.baidu.com, the user has to query www.baidu.com and many other related domain names (for many related resources such as images, java script, html, flash, video, sound), then a series of queries happen as the attached figure shows. Thank you. Zhiwei Yan At 2016-07-20 20:20:45, "Ralf Weber" wrote: >Moin! > >On 20 Jul 2016, at 7:34, 延志伟 wrote: >> I understand your points, but these risks always be there because DNS >> response is larger than the request, like DNSSEC. >Yes, which is why we have several proposals on how to mitigate the >problem by e.g not giving back ALL qtypes to an ANY question, or rate >limit any or answers in general. There also are tools out there that can >limit based on the answer size, all of that to mitigate or make the >handling of the amplification better. > >> How to avoid DNS DDoS is anther problem. >If you introduce something that makes the answer bigger without >acknowledging that there could be a problem with it or it is another >problem you have not been following what is going on in the Internet >lately. > >Others have acknowledged that and described a way forward to mitigate it >(TCP,TLS,Cookies) which introduce a whole other set of problems (some >introduce additional round trips) which further more diminishes the gain >to effort ratio IMHO. > >> Anyway, the cache should get the data fist and then it can cache them. >> :-) >That is true, but an answer out of the cache is served a lot of times >before it has to be cached again, so you are gaining something for that >tiny fraction of users where the cache is cold or has become cold (not a >problem if you use software that prefetches), but putting all others to >risk. Not a good idea IMHO. > >So long >-Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Hi, Ralf, I understand prefetch by the recursive server and it is the common case. [https://tools.ietf.org/html/draft-liu-dnsop-dns-cache-00] But if recursive server asks: give me the a RR and all the related RRs under your domain. And the authoritative server sends back the requested domain name RR and the related RRs under its domain. It can also improve the efficiency. Zhiwei Yan 在 2016-07-20 20:48:07，"Ralf Weber" 写道： >Moin! > >On 20 Jul 2016, at 14:36, 延志伟 wrote: >> But anyway, let's go back to the scenario considered by our draft to >> illustrate its necessity. >> I show an example as following (although I think we have described it >> several times. :-)): >> In order to visit the www.baidu.com, the user has to query >> www.baidu.com and many other related domain names >> (for many related resources such as images, java script, html, flash, >> video, sound), then a series of queries happen as the attached figure >> shows. >So what. If your recursive resolver is used by many people these records >will be in the cache. There will be no gain. Now of course if your >resolver only serves you that might be the case, but that is not the way >DNS was designed or is operated today. Oh and your example have out of >zone queries (also very common like facebook.com asking for fbcdn.com) >that can not be solved by this anyway. There is no better tool than a >prefetching hot resolver for lots of users to solve this problem. > >So long >-Ralf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
