please help me get over the feeling that this argument is founded on the same logic as that used by folks who "know" I might want, no NEED that extra bit of email in my inbox. As I read it, it sounds like DNS Server Spam being "PUSHED" to the Resolver who may or may not want the data.
Please advise. /Wm On Wed, Aug 17, 2016 at 8:35 AM, Matthew Pounsett <m...@conundrum.com> wrote: > > On 16 August 2016 at 08:57, Tim Wicinski <tjw.i...@gmail.com> wrote: > >> All, >> >> >> In Berlin we had two presentations on different methods of returning >> multiple responses: >> >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ >> >> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ >> >> and a presentation in Buenos Aires: >> >> https://datatracker.ietf.org/doc/draft-vavrusa-dnsop-aaaa-for-free/ >> >> All of these documents are attempting to solve a larger problem in >> different ways. >> The end result is "Return Associated Answer" to the client. >> >> The question is starting to coalesce around these two premises: >> >> - Do we want to Server to PUSH any or all Associated Answers, or >> > > > - Do we want the Client to PULL any or all Associated Answers, or >> > > There are times when the server side of the communication will know what > the client needs next, much the same as following a CNAME chain. This > might include records included automatically, such as returning the A/AAAA > records from the RDATA of a SRV record. It might also include records > added by local policy, whether that's from configuration or learned by > heuristics. In the future that might include things like returning an HTTP > SRV record for the apex (and associated address records) when a 'www' label > is queried for. > > There's a fair bit of overlap between the use cases for push and pull, but > I think more use cases are covered by push than pull. It's possible that > the use cases for pull are a subset of the use cases for push. I haven't > yet thought of any pull use cases that couldn't be covered by push. > > I think there's some flexibility to be gained from implementers having > both tools available, but I think if we were to only pursue one it should > be push. I think the fears of providing a DDoS tool can be assuaged by > requiring the use of things like cookies, or session signalling as a > prerequisite. > > >> >> - Do we want the Status Quo? >> > > The status quo works ... but I believe there are things to be gained by > moving forward. > > _______________________________________________ > 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
