In one of the experiments we are conducting we stuff the response with other QTYPE data and this seems to not interfere with resolver behaviour (unless we trigger it). So #3 doesn’t seem to be a common case (we could look in the fringes for this behaviour).
Towards the resolver’s clients, all extraneous data gets cleaned out of the response, which is quite sane behaviour in the current DNS. Have not tested what the resolver does with the data (keep it in cache, something in between #1 and #2, or discard it altogether, as in #2). Joao > On 23 Mar 2016, at 19:17, Ólafur Guðmundsson <ola...@cloudflare.com> wrote: > > > On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews <ma...@isc.org > <mailto:ma...@isc.org>> wrote: > > In message <20160322220345.29993...@pallas.home.time-travellers.org > <mailto:20160322220345.29993...@pallas.home.time-travellers.org>>, Shane Kerr > writes: > > Maybe we just need a new RTYPE. It would be awesome if CloudFlare > > killed ANY and then gave us ANYA ("any address"). ;) > > You would then need to do ANYA, A and AAAA queries or you have to > have signaling to indicate if the server supports ANYA with fallback > to A and AAAA on no support. Now for named you go from NOTIMP -> > NOERROR/NXDOMAIN introducing a meta type but for other servers you > start at NOERROR/NXDOMAIN so explicit signaling of support for a > meta type is needed. > > > There are two ways to approach the address distribution problem, > a) from the client side > b) from the server side > our proposal is strictly in camp b) i.e. just servers put this out. > > The OPEN question is what will resolvers do > #1 Accept but RRsets > #2 Discard non QTYPE covered set > #3 discard the answer > > If it is #3 then this is a horrible idea, > if is #2 then there is no loss and resolvers will improve over time. > if it is #1 then it is a win without any resolver changes. > > Tony, > Same questions apply if AAAA set is put in the additional section. > > Andrew, > We need data to determine if this is feasible. > > > Olafur > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
