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" <m...@conundrum.com> wrote: > > > On 19 July 2016 at 09:19, Ralf Weber <d...@fl1ger.de> wrote: > >> Moin! >> >> On 19 Jul 2016, at 9:00, Christopher Morrow wrote: >> >> > On Jul 19, 2016 8:36 AM, "Ralf Weber" <d...@fl1ger.de> 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
