IETF Logo Mail Archive

Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Tony Finch <dot@dotat.at> Tue, 15 August 2017 19:05 UTC

Return-Path: <dot@dotat.at>
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 AC75D13234C for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 12:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 TsboX3tAlGGl for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 12:05:38 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5791323B3 for <dnsop@ietf.org>; Tue, 15 Aug 2017 12:05:38 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9775422992; Tue, 15 Aug 2017 15:05:37 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 15 Aug 2017 15:05:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=8ed06e6Oc/70b3WNGbMLBCZy852pvfDwgfasMtGthi4=; b=h6AS4rMR K99LvF5nkEAck3H6GB6CC5BMzjO8AOusRIKC5Tmgab1f94FK9NRmipvaPczLZLuD hd3DSlUhH1tHRCkuR7wi9SgKz+QGHMXvxyXqw2MPH3vtVeq9nDsublAJ/rG62w4m gBbsfh1MSug8RCmHqEyo6ZUHjlXb/OF/6r7GMiPZZCsIp+BbZt7jUwmQN5YL0l+D H/utH9/rwOX7P7OCW+qJb8E41DZUvyZiAdw1UKjLJ0R4wgflJ+jwg6KZ9xvXQHxL /0+M+Y4hMrnsdD1pwTF5u31UbT/0h0Xb5gL7vVdVGiaS3ynfuKXPKnxxEwAnwqVJ YmH2MM3fg7FLhQ==
X-ME-Sender: <xms:AUaTWaR6tmc4QwaoDO_myvZCRiiGlRQxXDWM5HoqguNHJRJaLlpACA>
X-Sasl-enc: 0pfiTypiCutptwVOF8IxLzkUECSI+mJwHjgEtxOSqjgS 1502823937
Received: from [192.168.0.19] (82-181-40-178.bb.dnainternet.fi [82.181.40.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 405267E749; Tue, 15 Aug 2017 15:05:37 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Tony Finch <dot@dotat.at>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <59932F2F.9030504@redbarn.org>
Date: Tue, 15 Aug 2017 22:05:35 +0300
Cc: Jared Mauch <jared@puck.nether.net>, dnsop@ietf.org, Mikael Abrahamsson <swmike@swm.pp.se>
Content-Transfer-Encoding: quoted-printable
Message-Id: <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at>
References: <alpine.DEB.2.20.1708150911470.3655@uplift.swm.pp.se> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org>
To: Paul Vixie <paul@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qPBVeGrGYi1vVUd5gAfpxn342Zg>
Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 15 Aug 2017 19:05:41 -0000

> On 15 Aug 2017, at 20:28, Paul Vixie <paul@redbarn.org> wrote:
> 
> we can specify that AAAA be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=AAAA.

It's awkward.

From the stub point of view, how does it know that the server will return additional address records? How does it tell the difference between no support, no records, or an empty cache? To what extent do the additional records actually help clients to avoid double queries?

From the recursive server point of view, should it delay answers so it can fill in the additional section? What if a broken authority doesn't answer to AAAA queries?

DNSSEC can help a bit because there would be a visible proof of nonexistence to disambiguate some cases.

> given identical deployment curves along both the ANYA and additional-data timelines, we will get identical results.

ANYA has the advantage of clear signalling that the server supports it or not, though broken servers or middleboxes might make the negative answer rather slow. But we would need some kind of modelling or experimental evidence to see if it increases the query load by 50% (the worst case) rather than reducing by 50% (the goal).

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at

v2.23.0 | Report a Bug | By Email