retry UDP queries after an hard error

JINMEI Tatuya / 神明達哉 jinmei at isl.rdc.toshiba.co.jp
Sat Aug 10 02:35:32 UTC 2002


When an attempt of sending a UDP query fails, the BIND9 named always
waits for the next timeout event to retry, regardless of the error
type.  However, the waiting period is meaningless for some type of
"hard" errors, e.g., "no route to host".

So, doesn't it make sense to immediately retry the next server for
such cases?  It seems to me that this can be done by modifying
lib/dns/resolver.c:resquery_senddone() (of BIND 9.2.1).

This change will particularly help the following situation:

  In some OSes (including all the latest *BSDs), IPv6 is enabled by
  default, and auto-configured BIND 9 tries IPv6 transport by default
  on such OSes (even in the case of listen-on-v6 {none;}).  Thus, when
  the BIND 9 named finds AAAA and A glue RRs, it may try the AAAA ones
  even though the attempt is quite likely to fail.  In the worst case,
  this will introduce the delay of (2 * number_of_AAAA_glues) + alpha
  seconds.  But, in this environment, it is expected the server does
  not have an IPv6 route to reach to the IPv6 servers.  UDP send on
  *BSDs will return an "no route to host" error in such a case.  So,
  with the change the named will switch to an A glue (relatively)
  immediately, and thus the delay can be minimized even in the worst
  case.

Related thoughts:

- in theory, this is not specific to IPv6 vs IPv4.  The "worst case"
  can happen among multiple A glues.
- the "worst case" won't be repeated much, because the unreachable
  AAAA glues will be less prioritized once tried.
- for some OSes (e.g. Solaris) UDP send to non-reachable destinations
  cannot catch a hard error.  We cannot help those systems even with
  the change.
- we can of course turn off IPv6 completely, by
  "./configure --disable-ipv6".
  
Anyway, I'd like to know others' opinions on this.  Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp


More information about the bind-workers mailing list