Re: [DNSOP] Why would a v4 client send AAAA query?

Firstly most machines these days have at least one dual stack interface if not many even if the uplink is IPv4 only. Until the address is resolved they don’t know if the AAAA is usable (reachable) or not. 

-- 
Mark Andrews

> On 29 Aug 2019, at 19:43, Naveen Kottapalli <naveen.sarma@gmail.com> wrote:
> 
> My query was about the behavior we observed on a gateway where a pure v4 subscriber (not dual-stack) has sent both A and AAAA query for the same domain simultaneously.  Just wanted to know why would a pure v4 subscriber which cannot use the resolved AAAA domain addresses is trying to resolve the v6 addresses of the domain.
> 
> Yours,
> Naveen.
> 
> 
>> On Thu, 29 Aug 2019 at 12:09, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>> On Wed, Aug 28, 2019 at 05:53:26AM +0530, Naveen Kottapalli wrote:
>> 
>> > Can one of you tell why would a v4 client send AAAA query or a by client
>> > send a A query when the resolved address cannot be used?
>> 
>> One answer I did not see, but seems to me to be the most likely,
>> is that the library interface used by the application to learn the
>> peer's addresses asks for and returns all the v4 and v6 addresses,
>> and then the application tries each address in turn, until one
>> succeeds, the library is address-family agnostic.
>> 
>> Often the address resolution is many layers down below the actual
>> application code, e.g. in an HTTP request library that uses a
>> connection pool, that, as needed, establishes connections in a
>> generic way, by using getaddrinfo(3) with AF_UNSPEC as the address
>> family.  The library code many layers down below the application
>> code making an HTTP request, has no prior knowledge that on this
>> particular system IPv6 may not be available.  It just tries the
>> returned addresses in order until one works.
>> 
>> My system has IPv6, but only via a GRE tunnel to Hurricane Electric
>> (many thanks to HE for the pretty good free service) and IPv6
>> performance is consequently not nearly as good as IPv4.  So I've
>> configured my (FreeBSD) system to prefer IPv4:
>> 
>>     $ cat /etc/ip6addrctl.conf
>>     # Prefer IPv4
>>     ::ffff:0.0.0.0/96                100     4
>>     ...
>> 
>>     $ grep -i addrctl /etc/rc.conf
>>     ip6addrctl_enable="YES"
>>     ip6addrctl_policy="AUTO"
>> 
>> With that, getaddrinfo(3) returns the IPv4 addresses first, and I
>> only use IPv6 when none of the IPv4 addresses work, or the application
>> chooses to also use the IPv6 addresses (e.g. the DANE survey code
>> checks the validity of the certificate chain at every address of
>> each MX host).
>> 
>> For example (python):
>> 
>>     from socket import getaddrinfo, SOCK_STREAM
>>     for ai in getaddrinfo('www.ietf.org', 'https', type=SOCK_STREAM):
>>         print(ai)
>> 
>> outputs:
>> 
>>     (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('104.20.1.85', 443))
>>     (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('104.20.0.85', 443))
>>     (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('2606:4700:10::6814:55', 443, 0, 0))
>>     (<AddressFamily.AF_INET6: 28>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('2606:4700:10::6814:155', 443, 0, 0))
>> 
>> If I use python's HTTP client code to fetch content from:
>> 
>>     https://www.ietf.org/...
>> 
>> code similar to the above will look up both the IPv4 and IPv6
>> addresses, and then, if all goes well, use just the first one to
>> make an IPv4 TCP connection to www.ietf.org (port 443), perform a
>> TLS handshake, ... 
>> 
>> So the AAAA lookup is only used for IPv6-only sites, but that's the
>> cost of all the layering and abstraction of address order preference,
>> .....  An efficient implementation of getaddrinfo() can do the A and
>> AAAA lookups concurrently.
>> 
>> -- 
>>         Viktor.
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop