On Wednesday, 2012-02-29 10:17:26 +0000,
Ray Bellis <Ray.Bellis@nomi...> 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
> 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
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).