A and AAAA DNS query process in getaddrinfo()?

[Ian Smith]

On Fri, 10 Aug 2007, blue wrote:

 > JINMEI Tatuya / ???? wrote:
 > 
 > >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
 > >
 > >  
 > >
 > Dear Jinmei:
 > 
 > Thanks for your detailed explanation, and I have a deeper insight into 
 > the problem that IPv4/IPv6 dual stack may introduce to current applications.
 > 
 > Best regards,
 > 
 > Yi-Wen

Perhaps in some ways relevant to this discussion is a new (Aug 1)
article by Geoff Huston, mentioning AAAA / A query order issues:

 http://www.circleid.com/posts/transition_to_ipv6_address/

Cheers, Ian