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

"Mark Delany" <m9p@india.emu.st> Sat, 31 August 2019 17:44 UTC

Return-Path: <m9p@india.emu.st>
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 7965E1200F5 for <dnsop@ietfa.amsl.com>; Sat, 31 Aug 2019 10:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emu.st
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 WB8mnaq-rMxn for <dnsop@ietfa.amsl.com>; Sat, 31 Aug 2019 10:44:49 -0700 (PDT)
Received: from f3.bushwire.net (f3.bushwire.net [203.0.120.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDA212001E for <dnsop@ietf.org>; Sat, 31 Aug 2019 10:44:49 -0700 (PDT)
Received: by f3.bushwire.net (Postfix, from userid 1001) id 8565B3B101; Sun, 1 Sep 2019 03:44:45 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/simple; d=emu.st; s=2019; t=1567273485; bh=ukyWAAl+yrL/Qb5RQW4pevrwbv4=; h=Comments:Received:Date:Message-ID:From:Mail-Followup-To:To: Subject:References:MIME-Version:Content-Type:Content-Disposition: In-Reply-To; b=F6w8bk5VEysuC3qAvyvmJdnG4PxqOardhnTSbcUOZPqNB5qoHi59eVVbjl+dcSqzk qt8sFb26SfZoFNzfPOVmx9dIGQKL0k3hCo03pFs8+qD6qKd8orEfvynRbUmwHNy/df kQ0xUkid4YgEaeT9kTk5ZetBFH8/Nz3fxYO0WFZI=O0WFZI=
Comments: QMDA 0.3a
Received: (qmail 72448 invoked by uid 1001); 31 Aug 2019 17:44:45 -0000
Date: Sat, 31 Aug 2019 17:44:45 +0000
Message-ID: <20190831174445.72447.qmail@f3-external.bushwire.net>
From: Mark Delany <m9p@india.emu.st>
Mail-Followup-To: dnsop@ietf.org
To: dnsop@ietf.org
References: <CANFmOtkrB=Z6HNyJ7SFinMAHJEgOB=J0KQnKxYqy_7kPYPbumg@mail.gmail.com> <ybllfv9mjxr.fsf@w7.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <ybllfv9mjxr.fsf@w7.hardakers.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HjRgQamWZTrtY6xB8ZzLiDnC1MM>
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: Sat, 31 Aug 2019 17:44:50 -0000

On 31Aug19, Wes Hardaker allegedly wrote:
> Naveen Kottapalli <naveen.sarma@gmail.com> writes:
> 
> > 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?
> 
> As others have pointed out it's very common.
> 
> As an example, I looked at all the requests arriving to a root server in
> the DITL data for 2019-04-10 and found:

> So you can see that of all the ipv4 clients, 53% were asking for A

Ahh. But are you both talking about the same "clients"?

I assume Naveen is asking about clients as in applications on end-point
devices whereas your data is talking about clients as in recursive resolvers
asking on behalf of applications on end-point devices.

Your data is showing which transports the recursive resolvers prefer not which
transports the end-point devices have available to them. Even if there was a
correlation between the two (which I don't believe there is in general) it
still doesn't tell you whether that end-point device has both transports
available or not - it only shows which they prefer.

I think the answer is two-fold. First there is no standardized or easy way for
an application or a stub library to determine which transports are available
without actually trying them. As a consequence programmers, being a naturally
indolent mob, gravitate to the simplest and easiest thing to do which is to
ask for all addresses then iterate over them until they find one that
works. Using 'getaddrinfo' in perl tends to produce that outcome as does
net.Dial("tcp") in Go.

Second, as others have pointed out, almost all systems these days have at
least a loopback ipv6 address so well-written applications really must ask for
both types just in case ::1 comes back as an answer (or the only answer!).

What would be telling from those stats is how many clients are still only
asking for v4 addresses when they presumably have an interface with a v6
address as that probably indicates legacy code using pre-ipv6 APIs (or poorly
written modern code) which specifically asks for v4-only addresses.

Having said all that, there are still a scary number of IoT-type devices that
are v4-only; webcams and VOIP phones come to mind. But code in those things
are so poorly cobbled together that expecting rational DNS behavior is
probably asking too much.


Mark.