can't bring up tunnel through Fedora (36) bind-9.16.27 about iodine HOT 7 CLOSED

Running iodine through a caching resolver on the client seems like it would only cause problems yes.
The simplest workaround is to specify a DNS server for the client to use (instead of falling back to the system default)

from iodine.

from iodine.

OK. The workaround mentioned should still work though - I don't have any hints about the bind setup. Without packet captures (from different viewpoints) comparing the two it is hard to assist.

from iodine.

from iodine.

So, with the cache named.conf shown in the OP, I collected packet traces on all three machines involved:

• server (ns.evl.edu, 81.22.162.10)
• cache (delta-dns, 12.0.0.43)
• client (delta-user, 12.0.0.46)
  using tshark -i eth0 -s 2048 -w /tmp/[server|cache|client].pcap.

I then started iodined on the server: iodined -P foo 192.168.14.1 evl.edu, and then finally started the client: iodine -r -P foo evl.edu.

iodine_with_bind_9.11.zip shows the case where it works fine, the tunnel is established without any issues.

iodine_with_bind_9.16.zip shows when the tunnel fails to be brought up -- there's also a log of the client's command line output included.

The environment is absolutely identical in both cases, with the sole difference of the bind package version (9.11 when it works, 9.16 when it does not work).

The client log also has a time taken right after it fails, and I noticed a bunch of DNS traffic being exchanged between the client and cache, and also the cache and the iodine server, for 5-10 seconds after the client gave up.

Finally, here's a picture of the network map showing the topology of the delta-user client, delta-dns cache, and ns.evl.edu server:

Thanks again for taking a look, any further ideas much appreciated!

from iodine.

@yarrick -- I just completed a bisect on bind, and it seems the issue I'm seeing with the bind-9.16 cache is caused by commit isc-projects/bind9@ae52c21

I don't yet understand how or why, but if I'm using a bind-9 cache to relay iodine traffic, any version that has that commit applied (at least along the 9.16 branch) will cause a failure to bring up the tunnel.

from iodine.

Long story short, the (new?) default in named.conf is qname-minimization relaxed;. Together with the commit I found earlier today via bisect, that setting leads to a bind-9.16 cache failing to allow iodine to bring up a tunnel.

Explicitly setting that option to either qname-minimization strict; or to qname-minimization disabled; will allow iodine to successfully use the cache for relaying/tunnelling once again. The bind-9 docs for qname-minimization suggest that they might switch to strict as the default option instead of relaxed, but I have no idea what time frame that might imply.

Either way, figured I'd update this issue so anyone else googling for the symptoms might find an explanation a bit less painfully than I had to ; )

from iodine.