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

Erik Nygren <nygren@gmail.com> Thu, 29 August 2019 12:09 UTC

Return-Path: <nygren@gmail.com>
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 23B0F12010D for <dnsop@ietfa.amsl.com>; Thu, 29 Aug 2019 05:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.755
X-Spam-Level:
X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 rIWwFkx-jB4L for <dnsop@ietfa.amsl.com>; Thu, 29 Aug 2019 05:09:38 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D821200D5 for <dnsop@ietf.org>; Thu, 29 Aug 2019 05:09:38 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id n2so2209386wmk.4 for <dnsop@ietf.org>; Thu, 29 Aug 2019 05:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=8AcNbx9zSkPbvY/wPYWrwdNB1y+baFv7zfHCY0GL43U=; b=WvLf51qHq6PvQbv9GzFrbOuAOPbAb6rGdF3xKPrFEYwV21DvGyDRnNKxkBRbEbU61b zhEbU2ZKK3C6lvOvtp/GApN070Kkm+JD2Eu7OgquWeQA/4tNczNsGF/J3FEZ8w2wk6X3 rSp7stsgXpZ3DLkK661R5xs8kiI1xx0ufW0Aa8+ZL+bPatm+TwuyVTniBjlle8yqCPhq a8vjPjFYq+7dJkQP7Cq0VtR/AWZdsMm67R/1Fdt+eBVluqqVklBEAlglyMpCYwoOokQe NIvW+iism8FFOSW8D1IO/+Be5cDfXSeSt2Z6Y5htgnzbRNw3Qki55axQ/coofb3gGe1g UMyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=8AcNbx9zSkPbvY/wPYWrwdNB1y+baFv7zfHCY0GL43U=; b=M7az1R3WpnWOwJP56WaAjekncOnNuU1zLJJJoHfc3afk78zNxfhse+ZgZKN8GzmG1C NixK52mRisXtO8BXgAtFDXEKFBlpiAuNugSnXq3J7bwYCfpXQ1/jmdNDkkK7w/uqjPsf aKgj8T8mUKz+/qJm7agFS7Ytnjpv4uItporB48KupeejJElveC77KGjRUi9gjh2cpDDx dTMRobnWBtWZw3SOZ5yqhpo1gmmd6g6c4yodgYLD7c2xvmcUJLsp0gI/1rso9pjeb9Zf c5NfJeflpAA1AY7uhadI85eVYX9B21gIIY6G1w0XclZBAOoNVck+thPQ4HI2nu9Bsyfi rWgg==
X-Gm-Message-State: APjAAAUu9hhl4s4ecx5eQkqmpWydD3FmqNknLTSUDtQqQiKRCPLVFfBq +q82GlGQ16Yq4H7INN87wE9Kvxs2QPAf3pBKU4M=
X-Google-Smtp-Source: APXvYqxu6AK/+gebqppl69uuZPbxezGOP9x9It6f4p3ne83ERdustwOfMa3vTWlwAvivw+R8imkJ5QUD78LB4Vyd5n8=
X-Received: by 2002:a1c:a558:: with SMTP id o85mr4760671wme.30.1567080576560; Thu, 29 Aug 2019 05:09:36 -0700 (PDT)
MIME-Version: 1.0
References: <CANFmOtkrB=Z6HNyJ7SFinMAHJEgOB=J0KQnKxYqy_7kPYPbumg@mail.gmail.com> <20190829063910.GB90696@straasha.imrryr.org> <CANFmOt=_DqDNziVQh=5bF7yC-6DwPFPMYTz7kud7EwjsEFdY5Q@mail.gmail.com>
In-Reply-To: <CANFmOt=_DqDNziVQh=5bF7yC-6DwPFPMYTz7kud7EwjsEFdY5Q@mail.gmail.com>
Reply-To: erik@nygren.org
From: Erik Nygren <nygren@gmail.com>
Date: Thu, 29 Aug 2019 08:09:24 -0400
Message-ID: <CAKC-DJiwvZeX43SRoc3nbWjvEdbwAz2ZfTO0eD5dLA-tjjCG3Q@mail.gmail.com>
To: Naveen Kottapalli <naveen.sarma@gmail.com>
Cc: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000019b1dd059140615e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IewHvRPUD589M0sl6RR_-zQ8Ifo>
X-Mailman-Approved-At: Thu, 29 Aug 2019 07:52:31 -0700
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 12:09:41 -0000

The device could also have an IPv6 interface via a tunnel or VPN client.

- Erik




     [Sent from my IPv6 connected T-Mobile 4G LTE mobile device]

On Thu, Aug 29, 2019, 5:44 AM 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
>