Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Tue, 15 August 2017 12:53 UTC

Return-Path: <vladimir.cunat@nic.cz>
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 BB23D132422 for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 05:53:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 xFEkbwAj8N5W for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 05:53:17 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E8313241E for <dnsop@ietf.org>; Tue, 15 Aug 2017 05:53:17 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1::3e0] (unknown [IPv6:2001:718:1a02:1::3e0]) by mail.nic.cz (Postfix) with ESMTPSA id D231B623B4 for <dnsop@ietf.org>; Tue, 15 Aug 2017 14:53:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502801595; bh=+RQKzBrwJleV5U+eK+FUWGisZUuTewpfqCAp+DyK92c=; h=To:From:Date; b=CI79+Bw9FBMTRU1jPLYqsOVy63RuBKR79mrBYqLHq9KhqTTy62eEzSIaeyirTevLi h9Wnbiupsp80Yo2xX5kuLi7fYBuZ+SvmjNkwhwFjuy8LnM3NNJ/hWYA+En5RbREfJY VAssPbmriYyd4NpO+J8XMJjzlhTgj7f+84evF3bs=
To: dnsop@ietf.org
References: <alpine.DEB.2.20.1708150911470.3655@uplift.swm.pp.se> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <aee0d624-dc18-25d2-1a40-e16b1a6d4a85@fredan.se> <22432372-9229-0092-6a28-f6bd75c3a3a3@posix.co.za>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <92c20e3f-fc47-44c0-ac3e-a2b6814f0649@nic.cz>
Date: Tue, 15 Aug 2017 14:53:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <22432372-9229-0092-6a28-f6bd75c3a3a3@posix.co.za>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/oIZkRaQowfMMX-49eN0xkuCizqE>
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 12:53:20 -0000

Hello, I can't bear to watch this anymore.

On 08/15/2017 02:29 PM, Mark Elkins wrote:
> [...]
> I think the cleanest way would be a new pseudo record (ANYA) as the
> reply would have to be a single complete resource set of all the
> possible answers (A's and AAAA's), all with one covering signature if
> DNSSEC is involved. One would then programmatically know then what was
> available.

Such changes would *not* help, really.  You can ask both A and AAAA in
separate parallel queries easily.  If something like ANYA was asked
instead, you would run into the risk of the server not implementing it
and introducing yet another round trip (in the better not-implemented
cases).

The main question on client side is how long to wait if one answer comes
and the other doesn't, but that does seem better decided by the client
(with separate queries) than by intermediate resolvers (with a single
query).  On resolver side, one could recommend some prefetching
strategies, as mentioned, and I can imagine having some such
recommendations in rfc6555bis (non-mandatory).

--Vladimir