On 28.02.2012 14:26, Alex Rousskov wrote:
On 01/16/2012 10:32 AM, Henrik Nordström wrote:
This implements sending DNS A & AAAA queries in parallel by
creating "slave" idns_query requests. Current implementation
uses the A lookup as "master" and AAAA as "slave" query.
As implemented, the half-baked slave query cannot exist without the
master because it does not have callback information (at least).
However, the error and timeout handling code still thinks that each
query is fully capable of standing on its own:
The disable-A lookup directive (dns_v4_fallback) was removed. There is
always an A lookup now in the pair now.
Over the last few days I've been thinking it might be worth moving to a
model where we have a master object without specific RR type. Just a
data object to hold the query template, callback and statistics info.
And a pointer to a linked list of actual RR lookups being performed.
That way we are not locked down to a specific order of RR lookups like
now, and can extend it trivially to other types like PTR and SRV.
Ideally long-term the dns caches would also take the controller object
and store it as the cached entry. No mapping to an array of addresses.
But that is just speed polishing.
if (q->rcode != 0)
idnsCallback(q, NULL, -q->rcode,
rfc1035ErrorMessage(q->rcode)!
else
idnsCallback(q, NULL, -16, "Timeout");
cbdataFree(q);
Squid dumps core in idnsCallback() when the slave query times out
because q->callback is nil and the callback_data validity check is
useless.
Is this actually happening? in what query events?
There may be other similar leftovers from the good old days where we
did
not have half-baked queries; I have not checked.
One solution would be to change the slave query class type so that it
does not have the currently unset fields (such as callback). This
would
expose bugs like the one above at compile time.
Long term yes I think we should. see above.
Short-term a dummy handler can scream "bug" in the log or something.
Amos