Good thing refuse-any is just a draft then isn't it. Now any v. Concurrent queries. To ensure the resolver gets all the RRs, wouldn't you have to query for all defined RR types? Perhaps you want ALL instead of ANY?
/Wm On Thursday, 25 August 2016, Tony Finch <d...@dotat.at> wrote: > Edward Lewis <edward.le...@icann.org <javascript:;>> wrote: > > > The question I keep asking myself is: How is this different from a > > client just hitting a server with all anticipated questions at one time? > > Me too :-) > > I can see an advantage to improving the case where the client can't > predict all the questions in advance, e.g. when the subsequent questions > depend on a SRV target or an SPF include: directive. > > A big problem with additional data at the moment is a client doesn't know > whether an absence of data (no AAAA records) means the data doesn't exist, > so it still has to make followup queries to double check. A DNSSEC proof > of nonexistence could help. > > > Why not just ask for qtype ANY all the time, for data sets owned by the > > same domain name. > > Doesn't work reliably through caches, or with draft-ietf-dnsop-refuse-any > :-) > Also, ANY doesn't actually improve latency compared to concurrent queries. > > Tony. > -- > f.anthony.n.finch <d...@dotat.at <javascript:;>> http://dotat.at/ - I > xn--zr8h punycode > Southeast Biscay: Variable 2 or 3, becoming northwesterly 4 or 5 for a > time. > Slight or moderate. Occasional showers. Good. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <javascript:;> > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
