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 >
- [DNSOP] Why would a v4 client send AAAA query? Naveen Kottapalli
- Re: [DNSOP] Why would a v4 client send AAAA query? william manning
- Re: [DNSOP] Why would a v4 client send AAAA query? Joe Abley
- Re: [DNSOP] Why would a v4 client send AAAA query? Rob Sayre
- Re: [DNSOP] Why would a v4 client send AAAA query? Rob Sayre
- Re: [DNSOP] Why would a v4 client send AAAA query? Joe Abley
- Re: [DNSOP] Why would a v4 client send AAAA query? william manning
- Re: [DNSOP] Why would a v4 client send AAAA query? Naveen Kottapalli
- Re: [DNSOP] Why would a v4 client send AAAA query? Viktor Dukhovni
- Re: [DNSOP] Why would a v4 client send AAAA query? Naveen Kottapalli
- Re: [DNSOP] Why would a v4 client send AAAA query? Mark Andrews
- Re: [DNSOP] Why would a v4 client send AAAA query? Töma Gavrichenkov
- Re: [DNSOP] Why would a v4 client send AAAA query? Mukund Sivaraman
- Re: [DNSOP] Why would a v4 client send AAAA query? Erik Nygren
- Re: [DNSOP] Why would a v4 client send AAAA query? Wes Hardaker
- Re: [DNSOP] Why would a v4 client send AAAA query? Mark Delany