Description of problem: In case of an existing IPv6 connectivity, nsupdate and dig are preferring the use of IPv6 sockets. If now on client or server side the IPv6 connectivity is broken, no force or fallback is possible. dig got in 9.3.0 two options (-4 and -6) to force the connectivity. nsupdate didn't get one in 9.3.0 Version-Release number of selected component (if applicable): bind-9.2.4-2 How reproducible: Always Steps to Reproduce: 1. Setup IPv6 connectivity, but break e.g. the tunnel. 2. run dig or nsupdate Actual Results: # dig www.bieringer.de @ns.bieringer.de ; <<>> DiG 9.2.4 <<>> www.bieringer.de @ns.bieringer.de ;; global options: printcmd ;; connection timed out; no servers could be reached cat /tmp/nsupdate.txt | nsupdate ; Communication with server failed: timed out Expected Results: For dig and nsupdate: fallback to other protocol, if given DNS server name has A and AAAA record and no preselection was done (in case of dig, because nsupdate didn't understand any preselection at all). Additional info: For nsupdate, I currently created a workaround with a wrapper to set local <ipv4address> and server <ipv4address> explicitly, which results in IPv4 socket use.
Using bind-9.2.4-4 for FC3 will solve the timeout issue - you can download it from: http://people.redhat.com/~jvdias/bind/FC3 and I've also fixed it in bind-9.3.0 for FC3, available from: http://people.redhat.com/~jvdias/bind/9.3.0/FC3 Please try one of these new versions - they should fix the problem - I cannot duplicate it with them. For bug #140528 , I put a patch into the 'libdns' resolver library to immediately try the next available server address on NETUNREACH / HOSTUNREACH errors, that ISC have accepted for inclusion in the next release of BIND ( ISC bug 13153 ), so the 'dig' or 'nsupdate' utilities, which also use libdns, will no longer time out. With dig you can also use the +time and +tries options to increase the default timeouts. I'm in the process of getting one of these new versions pushed into FC3 updates.