On 18 August 2016 at 01:33, william manning <chinese.apri...@gmail.com> wrote:
> 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. > Pure hyperbole. If a client is given a delegation today, you don't complain because glue is supplied. It's necessary for the obvious next step. We already have other records (e.g. SRV) which is many cases have data which are useless without a followup query. In what way is it like spam to supply those data with the original query? > > 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
