References: <57c19c52-7015-a7eb-1174-bac371b3b871@redhat.com> Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 X-RT-Interface: Web X-Mailer: MIME-tools 5.508 (Entity 5.508) Content-Disposition: inline In-Reply-To: <57c19c52-7015-a7eb-1174-bac371b3b871@redhat.com> MIME-Version: 1.0 RT-Send-CC: Content-Length: 1677 Hi Petr, Thank you for reporting this issue and preparing a patch. Your fix is correct, but I took a closer look at the relevant code anyway to check whether this is indeed the optimal solution. In bin/dig/dighost.c, clone_lookup() is only called from requeue_lookup(). There are currently seven call sites for the latter; five of these modify origin for the new lookup immediately after the call to requeue_lookup(), which leaves us with two: - TCP retry in connect_timeout() (the one you reported), where not reassigning the origin from the previous lookup is a bug, - queueing a follow-up lookup when +nssearch is used, where not reassigning the origin from the previous lookup is also a bug: if the user does something like "dig isc +domain=org +nssearch", SOA queries will be sent for "isc" instead of "isc.org". clone_lookup() is also used in three other source files: - bin/dig/dig.c: five calls, all used for cloning a default lookup whose origin is always NULL, so origin reassignment in clone_lookup() does not really matter here, - bin/dig/host.c: two calls, both immediately followed by assigning NULL to origin, - bin/dig/nslookup.c: one call, immediately followed by assigning NULL to origin. Given the above, I prepared a different fix which causes clone_lookup() to reassign origin from the previous lookup, so that explicit reassignments ("n->origin = query->lookup->origin;") can be removed. Any caller that wants to tweak origin after calling clone_lookup() or requeue_lookup() already does that anyway. I will shortly submit my fix for review. Thank you again for bringing this issue to our attention.