From 444f1341800ba1c3315a8ec47b02bcd108e17080 Mon Sep 17 00:00:00 2001 From: Otto Moerbeek Date: Tue, 10 Jan 2023 14:42:41 +0100 Subject: [PATCH] Better wording of reason to not chain ECS enabled queries Co-authored-by: Remi Gacogne --- pdns/recursordist/pdns_recursor.cc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) 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 -- 2.47.2