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
- [DNSOP] opportunistic refresh and Happy Eyeballs Mikael Abrahamsson
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Mikael Abrahamsson
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Jared Mauch
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Ted Lemon
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… fredrik danerklint
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Mark Elkins
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Vladimír Čunát
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Hoffman
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… 神明達哉
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Tony Finch
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Jared Mauch
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Viktor Dukhovni
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Bob Halley
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Mark Andrews
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Paul Vixie
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Warren Kumari
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Warren Kumari
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Mukund Sivaraman
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Ralf Weber
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Warren Kumari
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Petr Špaček
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Brian Wellington
- Re: [DNSOP] opportunistic refresh and Happy Eyeba… Vladimír Čunát