I am using 3.99.3/i386.

I have a problem with a dns timeout:

scotty$ dig @TLD1.ULTRADNS.NET. netbsd.org ns 

; <<>> DiG 9.3.0 <<>> @TLD1.ULTRADNS.NET. netbsd.org ns
;; global options:  printcmd
;; connection timed out; no servers could be reached
scotty$

"dig @TLD2.ULTRADNS.NET. netbsd.org ns" is working fine.

One difference is that TLD1 has a AAAA address, TLD2 does not.

The host "scotty" is IPv6 enabled:
ip6mode=autohost

But is has temporarily no IPv6 access (no global IPv6 address, just a
link local).

This is what happens on the wire:

IP 145.100.55.147.58246 > 145.100.55.146.53:  32231+ AAAA? TLD1.ULTRADNS.NET.
IP 145.100.55.146.53 > 145.100.55.147.58246:  32231 1/8/5 AAAA 2001:502:d399::1 
IP 145.100.55.147.58245 > 145.100.55.146.53:  32232+ A? TLD1.ULTRADNS.NET.
IP 145.100.55.146.53 > 145.100.55.147.58245:  32232 1/8/5 A 204.74.112.1

This is what route monitoring shows:

scotty# route -n monitor
got message of size 104 on Wed Apr 27 12:18:00 2005
RTM_MISS: Lookup failed on this address: len 104, pid: 0, seq 0, errno 0, flags:<DONE>
locks:  inits: 
sockaddrs: <DST>
 2001:502:d399::1
got message of size 104 on Wed Apr 27 12:18:05 2005
RTM_MISS: Lookup failed on this address: len 104, pid: 0, seq 0, errno 0, flags:<DONE>
locks:  inits: 
sockaddrs: <DST>
 2001:502:d399::1
got message of size 104 on Wed Apr 27 12:18:10 2005
RTM_MISS: Lookup failed on this address: len 104, pid: 0, seq 0, errno 0, flags:<DONE>
locks:  inits: 
sockaddrs: <DST>
 2001:502:d399::1


When ktrussing dig, this is what happens:

 10640 dig      recvfrom(0x6, 0x8192000, 0x10000, 0, 0xbb1eeff8, 0xbb1eefbc) = 330
       "}\M-h\M^A\M^@\0\^A\0\^A\0\b\0\^E\^DTLD1\bULTRADNS\^CNET\0\0\^A\0\^A"
 10640 dig      close(0x6)                         = 0
 10640 dig      break(0x81a6000)                   = 0
 10640 dig      break(0x818f000)                   = 0
 10640 dig      __sysctl(0xbb1ffe00, 0x2, 0xbdbc4d54, 0xbb1ffdfc, 0, 0) = 0
 10640 dig      socket(0x18, 0x2, 0x11)            = 6
 10640 dig      fcntl(0x6, 0, 0x14)                = 20
 10640 dig      close(0x6)                         = 0
 10640 dig      fcntl(0x14, 0x3, 0)                = 2
 10640 dig      fcntl(0x14, 0x4, 0x6)              = 0
 10640 dig      setsockopt(0x14, 0xffff, 0x400, 0xbb1ffe50, 0x4) = 0
 10640 dig      setsockopt(0x14, 0x29, 0x13, 0xbb1ffe50, 0x4) = 0
 10640 dig      setsockopt(0x14, 0x29, 0x2a, 0xbb1ffe50, 0x4) = 0
 10640 dig      bind(0x14, 0x814bb00, 0x1c)        = 0
 10640 dig      recvmsg(0x14, 0xbb1ffe48, 0)       Err#35 EAGAIN
 10640 dig      write(0x5, 0xbb1ffe20, 0x8)        = 8
       "\^T\0\0\0\M-}\M^?\M^?\M^?"
 10640 dig      select                             = 1
 10640 dig      gettimeofday(0xbb1ffe70, 0)        = 0
 10640 dig      sendmsg(0x14, 0xbb1ffe48, 0)       Err#65 EHOSTUNREACH
 10640 dig      read(0x3, 0xbadffe30, 0x8)         = 8
       "\^T\0\0\0\M-}\M^?\M^?\M^?"
 10640 dig      read(0x3, 0xbadffe30, 0x8)         Err#35 EAGAIN
 10640 dig      select(0x15, 0xbadfff98, 0xbadfff78, 0, 0) JUSTRETURN
 10640 dig      clock_gettime(0, 0xbb3ffbbc)       = 0
 10640 dig      gettimeofday(0xbaffff10, 0)        = 0
 10640 dig      gettimeofday(0xbb1fff60, 0)        = 0
 10640 dig      gettimeofday(0xbb1ffe10, 0)        = 0
 10640 dig      gettimeofday(0xbb1ffe90, 0)        = 0
 10640 dig      sendmsg(0x14, 0xbb1ffe68, 0)       Err#65 EHOSTUNREACH
 10640 dig      gettimeofday(0xbaffff10, 0)        = 0
 10640 dig      timer_settime(0x3, 0x1, 0xbafffe38, 0) = 0
 10640 dig      sa_yield()                         JUSTRETURN
 10640 dig      clock_gettime(0, 0xbb3ffbbc)       = 0
 10640 dig      gettimeofday(0xbaffff10, 0)        = 0
 10640 dig      gettimeofday(0xbb1fff60, 0)        = 0
 10640 dig      gettimeofday(0xbb1ffe10, 0)        = 0
 10640 dig      gettimeofday(0xbb1ffe90, 0)        = 0
 10640 dig      sendmsg(0x14, 0xbb1ffe68, 0)       Err#65 EHOSTUNREACH
 10640 dig      gettimeofday(0xbaffff10, 0)        = 0
 10640 dig      timer_settime(0x3, 0x1, 0xbafffe38, 0) = 0

So, it looks like dig is trying to query over IPv6. This fails because there
is no IPv6 connectivity at the moment. Is this expected behaviour? Should
it try IPv6 when it has no global IPv6 address and no IPv6 route?

	rvdp