|Subject:||[PATCH] dig: search origin is lost in dig +tcp retry|
|Date:||Wed, 12 Jul 2017 19:42:59 +0200|
|From:||"Petr Menšík" <email@example.com>|
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 bugIt 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
Message body is not shown because sender requested not to inline it.