Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
On Wed, Jul 20, 2016 at 9:40 AM, 延志伟 wrote: > 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 > > > Some thoughts: With CDN's answering based on location, are they using very short TTL's, and thus the cache goes 'cold' quite frequently? And even if users of large pre-fetching resolvers are not helped, what if it helps users of smaller non-pre-fetching resolvers? -- Bob Harold ___ 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
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
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
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Jim, On 20 Jul 2016, at 9:18, Jim Reid wrote: It's a bit of a stretch to call that a suggestion and a far bigger one to claim cookies and/or TCP as a necessary precondition. There's no language like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS for EXTRA queries and responses". Well, not yet anyway. Maybe in the next release. And if DNS over TLS is the answer, the overheads of that handshake would more than cancel out the benefit of optimising away an extra query/response RTT. FWIW, I think it's a Bad Idea and the start of a very slippery slope to make queries or responses to QTYPEs dependent on the underlying transport protocol (modulo AXFR of course). Are layering violations acceptable nowadays? +lots, I see mentions of TCP and/or cookies popping up in more and more drafts and it has to stop. Packet size concerns exist for every usage of DNS, and new features should not pretend they are so special that they deserve special treatment in this regard. Such decisions are operational and they don’t belong in every draft that makes packets slightly bigger. Of course, when it’s obvious we need TCP-like semantics, like in the session draft for dnssd push, that’s fine. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
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
> On 20 Jul 2016, at 08:40, Mark Andrews wrote: > > Nameservers make decisions TODAY about what they will put in a message > based on COOKIES / TCP / UDP and a host of other considerations. True. But that's orthogonal to the point I was making. The draft *might* be heading in the direction of saying something like EXTRA queries are only valid over TCP. We should think very carefully before going down that path if that path eventually emerges. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
In message <36a593c1-1f01-4fe1-bc9a-3279f6460...@rfc1035.com>, Jim Reid writes: > > > On 20 Jul 2016, at 06:19, Mark Andrews wrote: > >=20 > >> 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). > >=20 > > Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS > > was suggests as being a necessary precondition. > > The draft does not say that Mark. It was stated up thread. Additionally aren't these discussion supposed to get consensus of the changes needed rather than the "I-D is cast in stone" especially right at the start of the processes. If this was last call this sort of nit picking would be justified but at this stage of the development process it seems to be unnecessary. > Under Security Considerations, it says: "One could mitigate this by only > serving responses to EXTRA requests over TCP or when using Cookies > [RFC5395], although there is no easy way to signal this to a client other > than through the use of the truncate bit." > > It's a bit of a stretch to call that a suggestion and a far bigger one to > claim cookies and/or TCP as a necessary precondition. There's no language > like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS > for EXTRA queries and responses". Well, not yet anyway. Maybe in the next > release. > > And if DNS over TLS is the answer, the overheads of that handshake would > more than cancel out the benefit of optimising away an extra > query/response RTT. > > FWIW, I think it's a Bad Idea and the start of a very slippery slope to > make queries or responses to QTYPEs dependent on the underlying transport > protocol (modulo AXFR of course). Are layering violations acceptable > nowadays? Nameservers make decisions TODAY about what they will put in a message based on COOKIES / TCP / UDP and a host of other considerations. Personally I don't think EXTRA is needed. A nameserver can predict a lot of the future queries based on the contents of the reply to the initial query. MX -> A / / TLSA of _25._tcp. SRV -> A / / if _tcp then TLSA of _._tcp. Yes, the responses get bigger but bigger isn't the real problem. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
> On 20 Jul 2016, at 06:19, Mark Andrews wrote: > >> 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). > > Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS > was suggests as being a necessary precondition. The draft does not say that Mark. Under Security Considerations, it says: "One could mitigate this by only serving responses to EXTRA requests over TCP or when using Cookies [RFC5395], although there is no easy way to signal this to a client other than through the use of the truncate bit." It's a bit of a stretch to call that a suggestion and a far bigger one to claim cookies and/or TCP as a necessary precondition. There's no language like "clients and servers SHOULD (MUST?) use DNS cookies/TCP/DNSoverTLS for EXTRA queries and responses". Well, not yet anyway. Maybe in the next release. And if DNS over TLS is the answer, the overheads of that handshake would more than cancel out the benefit of optimising away an extra query/response RTT. FWIW, I think it's a Bad Idea and the start of a very slippery slope to make queries or responses to QTYPEs dependent on the underlying transport protocol (modulo AXFR of course). Are layering violations acceptable nowadays? ___ 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
In message <236f5488-42d4-4a89-acab-b55fd2b57...@fl1ger.de>, "Ralf Weber" writes: > 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). Which is why DNS COOKIES with a valid server cookie / TCP / DNS-O-TLS was suggests as being a necessary precondition. > > 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. But the cache can be the other side of the world. The browser vendors aren't willing to go to SRV because they may need to make a second query to the recursive server to get the addresses of the SRV targets. > > So long > -Ralf > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
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). 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. 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
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
Sorry, this sort of response to queries. On Jul 19, 2016 10:14, "Matthew Pounsett" wrote: > > > On 19 July 2016 at 09:46, Ted Lemon wrote: > >> I thought the proposal specifically excluded support for this sort of >> query in any case other than for queries from authoritative servers. >> >> I'm not sure what you mean about "this sort of query".There wouldn't > be any special query sent to recursives. The response from recursives > could include the additional records called for by the EXTRA records cached > when the authoritative was queried. I don't see anything about that being > prohibited in the draft... in fact I see no reason for § 6 if it was > prohibited. There'd be no reason for recursives to ever receive the EXTRA > records themselves. > > > >> On Jul 19, 2016 09:37, "Matthew Pounsett" wrote: >> >>> >>> >>> On 19 July 2016 at 09:19, Ralf Weber wrote: >>> Moin! On 19 Jul 2016, at 9:00, Christopher Morrow wrote: > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: >> >> >> Except that if you have a decent size and hot Cache with refreshing >> these records will be in there anyway. IMHO you gained nothing, but I >> agree with Jim Reid that it would be good to have data on this. > > Nothing except some DNS round trips. > How could that matter though? As said I don't believe we have additional round trips between the recursive and the authoritative server in most of the cases. That is what we need data for though. DNS and applications that use DNS have unbelievable levels of caching. So while this all might apply to you if you run your own resolver just for you, it's not the case in big cache deployments most people use (be it their ISP or some big public resolver). While I tend to agree that the optimization gain between the recursive >>> and authoritative server is probably minimal, the potential gain between >>> the recursive and the stub is huge. Other than the fact that the >>> explanation focuses on the authoritative, I don't see any reason this needs >>> to be limited to recursive->authoritative conversations. Indeed, with the >>> OPT signalling a recursive could obtain the EXTRA records and provide the >>> same optimized answers to stubs. >>> >>> >>> >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
On 19 July 2016 at 09:46, Ted Lemon wrote: > I thought the proposal specifically excluded support for this sort of > query in any case other than for queries from authoritative servers. > > I'm not sure what you mean about "this sort of query".There wouldn't be any special query sent to recursives. The response from recursives could include the additional records called for by the EXTRA records cached when the authoritative was queried. I don't see anything about that being prohibited in the draft... in fact I see no reason for § 6 if it was prohibited. There'd be no reason for recursives to ever receive the EXTRA records themselves. > On Jul 19, 2016 09:37, "Matthew Pounsett" wrote: > >> >> >> On 19 July 2016 at 09:19, Ralf Weber wrote: >> >>> Moin! >>> >>> On 19 Jul 2016, at 9:00, Christopher Morrow wrote: >>> >>> > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: >>> >> >>> >> >>> >> Except that if you have a decent size and hot Cache with refreshing >>> >> these records will be in there anyway. IMHO you gained nothing, but I >>> >> agree with Jim Reid that it would be good to have data on this. >>> > >>> > Nothing except some DNS round trips. >>> > How could that matter though? >>> As said I don't believe we have additional round trips between the >>> recursive and the authoritative server in most of the cases. That is >>> what we need data for though. DNS and applications that use DNS have >>> unbelievable levels of caching. So while this all might apply to you >>> if you run your own resolver just for you, it's not the case in big >>> cache deployments most people use (be it their ISP or some big public >>> resolver). >>> >>> While I tend to agree that the optimization gain between the recursive >> and authoritative server is probably minimal, the potential gain between >> the recursive and the stub is huge. Other than the fact that the >> explanation focuses on the authoritative, I don't see any reason this needs >> to be limited to recursive->authoritative conversations. Indeed, with the >> OPT signalling a recursive could obtain the EXTRA records and provide the >> same optimized answers to stubs. >> >> >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
I thought the proposal specifically excluded support for this sort of query in any case other than for queries from authoritative servers. On Jul 19, 2016 09:37, "Matthew Pounsett" wrote: > > > On 19 July 2016 at 09:19, Ralf Weber wrote: > >> Moin! >> >> On 19 Jul 2016, at 9:00, Christopher Morrow wrote: >> >> > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: >> >> >> >> >> >> Except that if you have a decent size and hot Cache with refreshing >> >> these records will be in there anyway. IMHO you gained nothing, but I >> >> agree with Jim Reid that it would be good to have data on this. >> > >> > Nothing except some DNS round trips. >> > How could that matter though? >> As said I don't believe we have additional round trips between the >> recursive and the authoritative server in most of the cases. That is >> what we need data for though. DNS and applications that use DNS have >> unbelievable levels of caching. So while this all might apply to you >> if you run your own resolver just for you, it's not the case in big >> cache deployments most people use (be it their ISP or some big public >> resolver). >> >> While I tend to agree that the optimization gain between the recursive > and authoritative server is probably minimal, the potential gain between > the recursive and the stub is huge. Other than the fact that the > explanation focuses on the authoritative, I don't see any reason this needs > to be limited to recursive->authoritative conversations. Indeed, with the > OPT signalling a recursive could obtain the EXTRA records and provide the > same optimized answers to stubs. > > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
On 19 July 2016 at 09:19, Ralf Weber wrote: > Moin! > > On 19 Jul 2016, at 9:00, Christopher Morrow wrote: > > > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: > >> > >> > >> Except that if you have a decent size and hot Cache with refreshing > >> these records will be in there anyway. IMHO you gained nothing, but I > >> agree with Jim Reid that it would be good to have data on this. > > > > Nothing except some DNS round trips. > > How could that matter though? > As said I don't believe we have additional round trips between the > recursive and the authoritative server in most of the cases. That is > what we need data for though. DNS and applications that use DNS have > unbelievable levels of caching. So while this all might apply to you > if you run your own resolver just for you, it's not the case in big > cache deployments most people use (be it their ISP or some big public > resolver). > > While I tend to agree that the optimization gain between the recursive and authoritative server is probably minimal, the potential gain between the recursive and the stub is huge. Other than the fact that the explanation focuses on the authoritative, I don't see any reason this needs to be limited to recursive->authoritative conversations. Indeed, with the OPT signalling a recursive could obtain the EXTRA records and provide the same optimized answers to stubs. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Moin! On 19 Jul 2016, at 9:00, Christopher Morrow wrote: > On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: >> >> >> Except that if you have a decent size and hot Cache with refreshing >> these records will be in there anyway. IMHO you gained nothing, but I >> agree with Jim Reid that it would be good to have data on this. > > Nothing except some DNS round trips. > How could that matter though? As said I don't believe we have additional round trips between the recursive and the authoritative server in most of the cases. That is what we need data for though. DNS and applications that use DNS have unbelievable levels of caching. So while this all might apply to you if you run your own resolver just for you, it's not the case in big cache deployments most people use (be it their ISP or some big public resolver). 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
On Jul 19, 2016 8:36 AM, "Ralf Weber" wrote: > > > Except that if you have a decent size and hot Cache with refreshing > these records will be in there anyway. IMHO you gained nothing, but I > agree with Jim Reid that it would be good to have data on this. Nothing except some DNS round trips. How could that matter though? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Moin! On 19 Jul 2016, at 8:18, George Michaelson wrote: > "in reality" is skewing the story. You don't foresee a usecase, but > you do foresee abuse? So deploy cookies or move to TCP, or DTLS or > some other cost space where amplify implies special knowledge, or cost > on the amplifier. Which then introduces a deployment or scaling problem. Granted for Google scaling DNS to TCP is not a problem, but it might be for others. [..] > PS a use case as I understand it, is people (like 8.8.8.8) who see > patterns in otherwise unrelated DNS query and could potentially short > circuit in time, and query chain sequence things which are utterly > predictable. You ask for A? we know in 2 ms you will ask for , or > DS/DNSKEY of the parent or... because.. well because we have the query > dynamics in the space, and we know what we see. So lets put things > into answers and start converting clients to understand this, and we > drop query load significantly and speed up DNS closure. This feels > like optimizations we'd expect in other protocols. Except that if you have a decent size and hot Cache with refreshing these records will be in there anyway. IMHO you gained nothing, but I agree with Jim Reid that it would be good to have data on this. 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
"in reality" is skewing the story. You don't foresee a usecase, but you do foresee abuse? So deploy cookies or move to TCP, or DTLS or some other cost space where amplify implies special knowledge, or cost on the amplifier. I'm not sure I understand the use-case either btw, but this rebuttal smells like the classic 'FUD it out of existence' IETF approach. Warren is smart. I'm sure he thought of this. -G PS a use case as I understand it, is people (like 8.8.8.8) who see patterns in otherwise unrelated DNS query and could potentially short circuit in time, and query chain sequence things which are utterly predictable. You ask for A? we know in 2 ms you will ask for , or DS/DNSKEY of the parent or... because.. well because we have the query dynamics in the space, and we know what we see. So lets put things into answers and start converting clients to understand this, and we drop query load significantly and speed up DNS closure. This feels like optimizations we'd expect in other protocols. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
Moin! You were not alone, though I hummed for different reasons. I think it is bad to blow up responses with stuff that might be helpful, but in reality only will be helpful to people running amplification attacks. 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
Paul Wouters wrote: > The reason I hummed against this idea is that I think it is better to > teach validators to not strip dnssec signed additional data, and just > supply the data there. > > The current document as explained today seemed to limit itself already > to in baliwick or subzone data. Hi, I couldn't make it to IETF 96, but consider this a virtual hum against this idea also. > That seems a much simpler solution to the proposed problem. If I'm not mistaken, there's also no specification work required, either. (Besides, perhaps, specifying a RR that configures the behavior in the nameserver.) Nameservers are allowed to add “useful” RRs to the additional section, using local data. -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
The reason I hummed against this idea is that I think it is better to teach validators to not strip dnssec signed additional data, and just supply the data there. The current document as explained today seemed to limit itself already to in baliwick or subzone data. That seems a much simpler solution to the proposed problem. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
