Ray, On Wednesday, 2012-02-29 10:17:26 +0000, Ray Bellis <[email protected]> wrote: > > On 28 Feb 2012, at 18:40, Paul Vixie wrote: > > if the EDNS option for this just had an array of additional QTYPE, > such that the real QNAME and QCLASS pertained to all of these > additional questions, then i could definitely see value in this. the > response's OPT option would include the list of qtypes which were > found to be non-empty. all of the rrsets would be in the answer > section. > > > Yes, that's pretty much what was in the draft I wrote (but didn't > publish) and discussed with you during the last Prague IETF. > > My rationale likewise was that having constant QNAME and QCLASS but > multiple QTYPEs should eliminate the need for multiple RCODEs. > > However further discussion with other folks revealed issues (ISTR > around DNSSEC?) where it would be possible to get inconsistent RCODEs > for different QTYPEs. > > I've attached a copy of that document. It could be resurrected if > there's sufficient interest.
It looks reasonable to me. I'd support it moving forward. An additional document that would complete the picture would be describing recommended client & resolver behavior. In the case of a stub resolver, this would simply be trying a query to probe for support on the resolver, perhaps keeping this information for a limited period of time. In the case of a recursive resolver, then when a client query is received that: 1. does not contain the EDNS0 option asking for multiple types, and 2. is for a RR type that usually involves a separate query for a related RR type Then the resolver could add on the EDNS0 option when it tries to resolve the name. That way the resolver could group A and AAAA queries, or MX and A queries, or whatever, based on what users usually want. If a subsequent query comes in while this is in process, then the resolver is already busy looking up. In order for this to work most effectively, the resolvers will need to remember which authoritative servers support the EDNS0 option, so they can break down queries with the option sent from clients if the server does not support it. For lowest latency, probably the default should be to assume that authoritative servers do not support the option. Perhaps it makes sense to provide the server with a way to specify how long it makes sense for a stub resolver or recursive resolver to cache information about it (there is a lot of this kind of information, not only this particular EDNS0 option). -- Shane _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
