A and AAAA DNS query process in getaddrinfo()?

[JINMEI Tatuya / 神明達哉]

At Fri, 10 Aug 2007 13:45:46 +0800,
blue <susan.lan at zyxel.com.tw> wrote:

> Although DNS resolver may lead to some delay or misbehavior of the upper 
> application, I think that would be caller's resposibility to decide 
> which result it would like to use. I am not so sure about the check in 
> KAME implementation, in getaddrinfo.c:

(snip)

> Why the check for avilable IPv4/IPv6 address, addrconfig(), only applies 
> when the hints' family type is AF_UNSPEC? I think if delaying the upper 
> application is a concern, the check should be applied no matter what 
> family type it is.

I thought the v6fix document provided sufficient background to answer
these questions, but in case it didn't I'm going to rephrase the
points:

- ideally, we'd not want to introduce the special behavior; as you
  indicated above, the ideal behavior for getaddrinfo() called with
  AF_UNSPEC would be to return all possible IPv4 and IPv6 addresses
  via A and AAAA queries.
- unfortunately, however, a dual stack application running on
  IPv4-only node could suffer from various problems due to misbehaving
  DNS servers if the underlying resolver sends out AAAA queries.  Note
  that the most typical behavior for such dual stack applications is
  to call getaddrinfo() with AF_UNSPEC.
- the specific behavior of the KAME-snap version of getaddrinfo() is a
  workaround to mitigate the problem in the conflicting situation, yet
  still being compliant to the API specification.
- since this is a workaround, we'd not want to do the same ugly hack
  for the less common case of getaddrinfo() called with AF_INET6.
  Also, in this case the node without an effective IPv6 address would
  not be able to make any IPv6 communication regardless of the
  getaddrinfo() results or how long it takes, and the application
  doesn't have any alternative network protocol unlike the case of
  AF_UNSPEC, so introducing the same hack doesn't actually help the
  application.
- so, comparison between the AF_UNSPEC case and the AF_INET6/AF_INET
  case in terms of superficial consistency doesn't really make sense.

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