From: Otto Moerbeek Date: Tue, 10 Jan 2023 13:42:41 +0000 (+0100) Subject: Better wording of reason to not chain ECS enabled queries X-Git-Tag: dnsdist-1.8.0-rc1~112^2~1 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=444f1341800ba1c3315a8ec47b02bcd108e17080;p=thirdparty%2Fpdns.git Better wording of reason to not chain ECS enabled queries Co-authored-by: Remi Gacogne --- diff --git a/pdns/recursordist/pdns_recursor.cc b/pdns/recursordist/pdns_recursor.cc index 93c414dba0..07ab20aea2 100644 --- a/pdns/recursordist/pdns_recursor.cc +++ b/pdns/recursordist/pdns_recursor.cc @@ -267,9 +267,9 @@ LWResult::Result asendto(const char* data, size_t len, int flags, pident->remote = toaddr; pident->type = qtype; - // We might want to put the ecs netmask into the PacketID key, but we take the easy way: - // Avoid processing a chain with queries having different ECS data by lwres:asyncresolve() as it - // assumes the mask received corresponds to the mask sent out, so do not chain ecs queries. + // We cannot merge ECS-enabled queries based on the ECS source only, as the scope + // of the response might be narrower, so instead we do not chain ECS-enabled queries + // at all. if (!ecs) { // See if there is an existing outstanding request we can chain on to, using partial equivalence // function looking for the same query (qname and qtype) to the same host, but with a different