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
