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

Jacques Latour <jacques.latour@cira.ca> Thu, 20 November 2014 17:11 UTC

Return-Path: <jacques.latour@cira.ca>
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 6093D1A1AE6 for <dnsop@ietfa.amsl.com>; Thu, 20 Nov 2014 09:11:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.495
X-Spam-Level:
X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rmnCf_5oXeoN for <dnsop@ietfa.amsl.com>; Thu, 20 Nov 2014 09:11:05 -0800 (PST)
Received: from mail02.tor.cira.ca (mail02.tor.cira.ca [192.228.26.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCEFB1A0BE8 for <dnsop@ietf.org>; Thu, 20 Nov 2014 09:11:04 -0800 (PST)
Received: from crp-spam-01.corp.cira.ca (mx1.cira.ca [192.228.22.116]) by mail02.tor.cira.ca (8.13.8/8.13.1) with ESMTP id sAKHB3MF005657 for <dnsop@ietf.org>; Thu, 20 Nov 2014 12:11:03 -0500
X-Virus-Scanned: by SpamTitan at crp-dmz.cira.ca
Received: from EXCH-02.CORP.CIRA.CA ([fe80::3c25:d5f2:72b8:e35c]) by EXCH-01.CORP.CIRA.CA ([fe80::2073:dbc0:bb14:ab50%19]) with mapi id 14.01.0438.000; Thu, 20 Nov 2014 12:11:03 -0500
From: Jacques Latour <jacques.latour@cira.ca>
To: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
Thread-Index: AQHQAebI0WbIOpQVyU+lrfhMZf212ZxkNbwAgACGEwCAAPxxAIAACZyAgAANroCAACRvgIAAJasAgAOXtVA=
Date: Thu, 20 Nov 2014 17:11:03 +0000
Message-ID: <C059877D829F76429F49E0B48705D888D574C2FD@EXCH-02.CORP.CIRA.CA>
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> <FE0CA17E-0702-4A8A-B25D-ADC88AE94E78@icsi.berkeley.edu> <86CC9DD3-6804-4F94-831E-DD408C89EECA@vpnc.org>
In-Reply-To: <86CC9DD3-6804-4F94-831E-DD408C89EECA@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.40.152]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/o0gcWknZXk-JyK5pcaZaGfn6Ie4
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: Thu, 20 Nov 2014 17:11:13 -0000

I think the one big drawback for me is the loss visibility and control for the root operators. As an example, DITL, what value will that have if only subset of queries make it to root servers? Will DNS-OARC have to collect logs from all these loopback authoritative slave recursive?  
-1 for adoption.
 
> -----Original Message-----
> From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman
> Sent: November-17-14 11:05 PM
> To: Nicholas Weaver
> Cc: dnsop
> Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
> 
> On Nov 17, 2014, at 5:50 PM, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> wrote:
> > 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.
> 
> It's fine if you don't want the WG to adopt this draft, but that second sentence is
> clearly wrong. The third paragraph of the introduction says:
> 
>       <t>The primary goal of this design is to provide faster negative
>       responses to stub resolver queries that contain junk queries. This
>       design will probably have little effect on getting faster positive
>       responses to stub resolver for good queries on TLDs, because the data
>       for those zones is usually long-lived and already in the cache of the
>       recursive resolver; thus, getting faster positive responses is a
>       non-goal of this design.</t>
> 
> Lookups to the root for things that don't actually exist in the root happen all the
> time, yes?
> 
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop