Content-Transfer-Encoding: 8bit
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: iso-8859-2
Content-Length: 1685

Hi,

It came out, under specific firewall filtering, dig behaviour will be
different in +tcp and +notcp mode. It was reported to me on RHEL 6 bind
9.8.2. It is present still in the latest devel beta 9.11.2b1.

Easiest way to reproduce it is to use iptables to drop incoming
acknowledges.

# iptables -I INPUT -p udp --sport domain -j DROP
# iptables -I INPUT -p tcp --sport domain --tcp-flags ACK,SYN ACK -j DROP

If I use command:

$ dig -d +retry=4 +tcp +domain=example foo

or with "search example" in resolv.conf with
$ dig -d +retry=4 +tcp +search +showsearch foo

The first connection will query foo expanded by domain example.
After it timeouts, it will try a new connection. New connection is
created without the search list however, so only bare name is used on
following retries. UDP searches are not modified, because they do not
use requeue_lookup call (logs "making new TCP request").

It will send queries to foo.example at first. Queries to foo. start to
appear on the new connection.

You can observe used origin before each query. It is also visible in
wireshark on captured data.

It behaves well in UDP mode, no matter how many retries, it will still
use full foo.example. name. In TCP mode, it stops using example. soon.

It was reported to me because behavior was inconsistent in bug
https://bugzilla.redhat.com/show_bug.cgi?id=1449814
It turned out firewall was involved in private messages.

Proposed fix is included. I am not sure if it is intentional to skip
lookup->origin in clone_lookup. It might be useful to copy it from
original lookup when servers is true. But the most simple fix is included.

Regards,
Petr
--
Petr Menšík,
Software Engineer
Red Hat