Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

Nicholas Weaver <nweaver@icsi.berkeley.edu> Tue, 18 November 2014 01:50 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112A1AD047 for <dnsop@ietfa.amsl.com>; Mon, 17 Nov 2014 17:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
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 YlNciaswHICG for <dnsop@ietfa.amsl.com>; Mon, 17 Nov 2014 17:50:13 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4625F1AD033 for <dnsop@ietf.org>; Mon, 17 Nov 2014 17:50:13 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 32F1D2C4076 for <dnsop@ietf.org>; Mon, 17 Nov 2014 17:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fghIUNL1wrga; Mon, 17 Nov 2014 17:50:12 -0800 (PST)
Received: from [10.0.1.17] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 57B5E2C4068; Mon, 17 Nov 2014 17:50:12 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9EC6282E-75AF-4A23-A915-D26FC677638C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b1
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <546A873F.8060402@dougbarton.us>
Date: Mon, 17 Nov 2014 17:50:07 -0800
Message-Id: <FE0CA17E-0702-4A8A-B25D-ADC88AE94E78@icsi.berkeley.edu>
References: <54691B0A.6060508@gmail.com> <54692F7A.6030803@dougbarton.us> <20141117071250.GA55492@isc.org> <546A73B6.2060005@dougbarton.us> <20141117225045.GA35924@isc.org> <546A873F.8060402@dougbarton.us>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/DgE1ehSqxYnym8kWKpasmQbQiqo
Cc: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 18 Nov 2014 01:50:15 -0000

Trying to be polite here, but this seems just silly, and the only thing really should be "Don't Bother".


Root latency frankly speaking does not matter.  Lookups to the root themselves should be rare, and the responses have very long TTLs (48 hours!).  So this is clearly optimizing something that needs no optimization.

Lets say your resolver is behind an insanely high latency link with 10s RTTs to everywhere else on the Internet.

The additional latency for lookups to the root will be in the absolute noise compared with the latency for the lookups to the TLDs, or for the TCP RTT latency on all connection setup, or anything else like that.  So why waste the effort optimizing the one thing which doesn't matter?



A far better approach if you actually want to improve resolver performance on high latency links would be to prefetch on expiration: if an element is fetched out of the cache at least X times, when you expire it from the cache immediately trigger a new fetch for that name.

This would have a much better performance benefit than a root zone mirror.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc