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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 29 August 2019 06:39 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C901201EF for <dnsop@ietfa.amsl.com>; Wed, 28 Aug 2019 23:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL1YTqKbbMcK for <dnsop@ietfa.amsl.com>; Wed, 28 Aug 2019 23:39:12 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629C4120020 for <dnsop@ietf.org>; Wed, 28 Aug 2019 23:39:11 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 74F304C2A0; Thu, 29 Aug 2019 02:39:10 -0400 (EDT)
Date: Thu, 29 Aug 2019 02:39:10 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org
Message-ID: <20190829063910.GB90696@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <CANFmOtkrB=Z6HNyJ7SFinMAHJEgOB=J0KQnKxYqy_7kPYPbumg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CANFmOtkrB=Z6HNyJ7SFinMAHJEgOB=J0KQnKxYqy_7kPYPbumg@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kxqslcPXzTcHVKGlzSJy7ON3P9o>
Subject: Re: [DNSOP] Why would a v4 client send AAAA query?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 06:39:14 -0000

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.