Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

Mark Andrews <marka@isc.org> Tue, 01 March 2016 21:06 UTC

Return-Path: <marka@isc.org>
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 A71241B41A3 for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 13:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 IeHQo6_lUfsu for <dnsop@ietfa.amsl.com>; Tue, 1 Mar 2016 13:06:45 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190571B41A2 for <dnsop@ietf.org>; Tue, 1 Mar 2016 13:06:45 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id C33333493C2; Tue, 1 Mar 2016 21:06:42 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BE9D8160042; Tue, 1 Mar 2016 21:06:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AF4C01600BA; Tue, 1 Mar 2016 21:06:42 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PhozHNzYhUcj; Tue, 1 Mar 2016 21:06:42 +0000 (UTC)
Received: from rock.dv.isc.org (c110-21-49-25.carlnfd1.nsw.optusnet.com.au [110.21.49.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 6C874160042; Tue, 1 Mar 2016 21:06:42 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 64A47438D02A; Wed, 2 Mar 2016 08:06:39 +1100 (EST)
To: Ray Bellis <ray@bellis.me.uk>
From: Mark Andrews <marka@isc.org>
References: <D2F9A5BA.13FE2%edward.lewis@icann.org> <20160229151220.7d7e9643@pallas.home.time-travellers.org> <D2F9BED8.13FF9%edward.lewis@icann.org> <20160229160357.2ef4fd29@pallas.home.time-travellers.org> <CAHw9_iKJwJh0AELts8Vy+K+qtNwo+rtuLa36ukGcty7CxnvOMg@mail.gmail.com> <CAN6NTqzHmADWnm10Y9Ap4UqSSk_h9zeru=vUeRHUdU_w7Nr=vw@mail.gmail.com> <56D5B830.80109@bellis.me.uk>
In-reply-to: Your message of "Tue, 01 Mar 2016 15:41:36 -0000." <56D5B830.80109@bellis.me.uk>
Date: Wed, 02 Mar 2016 08:06:39 +1100
Message-Id: <20160301210639.64A47438D02A@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/JpeWZ8MU7XfbhLpRzCokaBAT3No>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.
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: <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, 01 Mar 2016 21:06:46 -0000

In message <56D5B830.80109@bellis.me.uk>, Ray Bellis writes:
> 
> 
> On 01/03/2016 15:26, =D3lafur Gu=F0mundsson wrote:
> 
> > Thus I consider your document a distraction, we should push the general
> > solution not a special case
> 
> +1
> 
> Ray

ANC can be both good and bad depending upon where it is used in the
DNS.  For the root zone and DLV there is no downside to using ANC
for those zones but the benefits of using ANC will decrease as the
root zone increases in size (the ANC hit ratio will drop).

ANC does not work for zones using OPTOUT.  This is just about all
TLDs and similar zones.

For in-addr.arpa and ip6.arpa it may actually have strong negative
consequences and you can't bring up a machine and have it be useful
for certain classes of work until the NSEC* records have cleared
the cache.  Think bring up a replacement SMTP server.

That then leaves leaf zones.  Here sites will not want ANC for their
own zones internally.  Externally there is only real benefit if you
are under a random prefix DoS attack.

I actually don't see much benefit in deploying this generally.

Mark

> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org