Re: [Resolverless-dns] Paper on Resolver-less DNS

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 04 September 2019 21:56 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A98E120077 for <resolverless-dns@ietfa.amsl.com>; Wed, 4 Sep 2019 14:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 cGvFqutUmwhr for <resolverless-dns@ietfa.amsl.com>; Wed, 4 Sep 2019 14:56:50 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64D3120043 for <resolverless-dns@ietf.org>; Wed, 4 Sep 2019 14:56:49 -0700 (PDT)
Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id D38AD29D547 for <resolverless-dns@ietf.org>; Wed, 4 Sep 2019 17:56:48 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <c00d6128-781e-4ad9-bee2-83d6e7e863ac@informatik.uni-hamburg.de>
Date: Wed, 04 Sep 2019 17:56:47 -0400
Content-Transfer-Encoding: 7bit
Reply-To: resolverless-dns@ietf.org
Message-Id: <F4A6ABCA-2C6B-4D3A-986B-B043BEA09EFB@dukhovni.org>
References: <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> <ADC6E119-0EED-4990-A975-F594C9282872@dukhovni.org> <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de> <20190830053023.GE90696@straasha.imrryr.org> <f81ec73d-879e-0427-e11b-0973e01034c3@informatik.uni-hamburg.de> <20190902213241.GI70599@straasha.imrryr.org> <88cef6e4-73bd-7324-8509-a1acbd77750e@informatik.uni-hamburg.de> <CA+nkc8CLO7TwB1zFstjSCGNBvWUaBX1E2uvBQOkSMEAmFxP3yA@mail.gmail.com> <726fa997-8b7c-495e-623a-ccb299e36c1f@informatik.uni-hamburg.de> <20190904145018.GO70599@straasha.imrryr.org> <c00d6128-781e-4ad9-bee2-83d6e7e863ac@informatik.uni-hamburg.de>
To: resolverless-dns@ietf.org
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/9VYt7Pq01EZDk8tjOEsrPun-rd0>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 21:56:53 -0000

> On Sep 4, 2019, at 5:23 PM, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
> 
> Research work indicates that about 5% of DNS transactions take longer
> than 100ms [1]. Furthermore, it is known that an additional delay of
> 100ms of the website load time reduces the conversion rate by about 7%
> [2]. These facts highlight that achieving a fast website load time
> really matters and that additional DNS lookups can significantly delay
> the website load time. In my view, the performance gains of
> resolver-less DNS are really worth it.

You lose me at "conversion rate", and other exploitative metrics.

If most of the benefit (to users, not advertisers) can be obtained
while limiting the scope to the current page only, consider specifying
such a narrow scope.

If the bandwidth savings only result in users seeing more ads per
page, then I'd rather have the latency.

-- 
	Viktor.