Re: [DNSOP] unsolicited HTTPSSVC responses

2020-06-01 Thread fujiwara
> From: Petr Špaček > On 27. 05. 20 1:05, Paul Vixie wrote: >> than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not >> well defined and is broadly unimplemented. various other multiple-questions >> proposals have been made but nothing gets traction. > > I would much rathe

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-27 Thread Ray Bellis
On 27/05/2020 17:40, Eric Orth wrote: > Maybe a better solution, but considering that the issue I'm dealing with > is when the stub is unwilling to send additional queries or queries for > new types out of concerns of middlebox ossificiation (especially from > older home routers) on additional q

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-27 Thread Eric Orth
On Wed, May 27, 2020 at 2:34 AM Petr Špaček wrote: > On 27. 05. 20 1:05, Paul Vixie wrote: > > so, this way lies madness, and the solution we see most often is a > host-level > > cache of DNS results. the old INN (usenet net news) server had one of > these, > > and all modern browsers have one. m

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-27 Thread Ray Bellis
On 27/05/2020 07:33, Petr Špaček wrote: > I would much rather spent time on > https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 > > That would bring benefit to broader set of clients and has advantage > that server does not send back data nobody asked for (thus wasting > resource

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-26 Thread Petr Špaček
On 27. 05. 20 1:05, Paul Vixie wrote: > so, this way lies madness, and the solution we see most often is a host-level > cache of DNS results. the old INN (usenet net news) server had one of these, > and all modern browsers have one. many of us simply run a validating > iterative > caching recur

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-26 Thread Paul Vixie
On Tuesday, 26 May 2020 23:56:30 UTC Ben Schwartz wrote: > On Tue, May 26, 2020 at 7:06 PM Paul Vixie wrote: > ... > > > and the responder knows > > the additional data (that is, it should not make extra queries to find it > > just > > for additional data reasons.) > > The current text does not

Re: [DNSOP] unsolicited HTTPSSVC responses

2020-05-26 Thread Paul Vixie
On Tuesday, 26 May 2020 19:43:27 UTC Eric Orth wrote: > One of my colleagues recently brought up the idea of suggesting recursives > add additional HTTPSSVC records into responses for A/ queries as a way > to make HTTPSSVC more available for cases where a stub is hesitant to make > additional q