Re: [DNSOP] opportunistic refresh and Happy Eyeballs

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 15 August 2017 11:40 UTC

Return-Path: <swmike@swm.pp.se>
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 A10D413218F for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 04:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 D0hKBDi3GNE1 for <dnsop@ietfa.amsl.com>; Tue, 15 Aug 2017 04:40:03 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 ED86F13208E for <dnsop@ietf.org>; Tue, 15 Aug 2017 04:40:02 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id BF02EAF; Tue, 15 Aug 2017 13:40:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502797200; bh=YpReYK7L56PzbZJ2PMoGbUKVoIDdXH7QyhnZwD1Mkic=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=u4PfTq+9WghFw4rFd9oHwGOucAIpev4Udd7dEL4ZmX2Mn7ajjFUiD3+LJ5kg022g+ K1D+7PwnnZN5tc9rqJsRz1zEl8ST6MfbC/aKzn+ahtUxXCtnkmWAF4krk5fqew2Ug8 nA09UCuXpiRwtA5x1OrQDa1jy/Maqh/RTbuG6kio=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC76784; Tue, 15 Aug 2017 13:40:00 +0200 (CEST)
Date: Tue, 15 Aug 2017 13:40:00 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ted Lemon <mellon@fugue.com>
cc: dnsop@ietf.org
In-Reply-To: <D65BFC40-FF9F-4B81-B185-906C12BC0C59@fugue.com>
Message-ID: <alpine.DEB.2.20.1708151334370.3655@uplift.swm.pp.se>
References: <alpine.DEB.2.20.1708150911470.3655@uplift.swm.pp.se> <D65BFC40-FF9F-4B81-B185-906C12BC0C59@fugue.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Vsz-CZCzacfcbQOByGfgJi9X8yg>
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 11:40:05 -0000

On Tue, 15 Aug 2017, Ted Lemon wrote:

> If it's a commonly-used name, isn't this a one-time event, though?  The 
> happy eyeballs client asks for A and AAAA, gets A because it was in the 
> cache, but AAAA also winds up in the cache, and then because it's a 
> commonly used name, neither record ever goes stale again.

That was the assumtion by a lot of people who aren't DNS experts 
(including me). Mark Andrews brought up that this might be a more frequent 
issue that people think.

Also there is the issue that as the TTL becomes 0 and the RR is now no 
longer in cache, next question will trigger a lookup and if the 
authoritative nameserver is 400ms RTT away, then during these 400ms a lot 
of clients might only use IPv4 with current RFC6555bis proposal.

So there are two things here I see:

1. Opportunistically refresh RRs before they expire. I've been told some 
resolvers do this already.

2. Tie together A and AAAA so that if one is asked for, make sure there is 
an up-to-date of the second one as well, at least make sure it doesn't 
expire even if it's infrequently used. I guess this means take into 
account A questions when deciding whether to refresh that AAAA you might 
have?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se