Re: [DNSOP] pushing updates to the parent

Mark Andrews <marka@isc.org> Sat, 08 March 2014 05:54 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 521971A01D8 for <dnsop@ietfa.amsl.com>; Fri, 7 Mar 2014 21:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level:
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 lWzQlHj3vdyT for <dnsop@ietfa.amsl.com>; Fri, 7 Mar 2014 21:54:13 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 056661A01B6 for <dnsop@ietf.org>; Fri, 7 Mar 2014 21:54:13 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 899512383C6; Sat, 8 Mar 2014 05:53:54 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 25A3B160049; Sat, 8 Mar 2014 05:54:52 +0000 (UTC)
Received: from rock.dv.isc.org (unknown [149.20.66.86]) by zmx1.isc.org (Postfix) with ESMTPSA id 6A93F16003F; Sat, 8 Mar 2014 05:54:51 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7E50010CFAA9; Sat, 8 Mar 2014 16:53:48 +1100 (EST)
To: Joe Abley <jabley@hopcount.ca>
From: Mark Andrews <marka@isc.org>
References: <20140307100524.2F42810CD58F@rock.dv.isc.org> <3E0DC692-7BA0-4672-BB10-82B854BB69CE@hopcount.ca> <alpine.LSU.2.00.1403071025270.19416@hermes-1.csi.cam.ac.uk> <8C184518-2A56-42B6-BD63-3E50F8126664@hopcount.ca>
In-reply-to: Your message of "Fri, 07 Mar 2014 15:39:37 -0000." <8C184518-2A56-42B6-BD63-3E50F8126664@hopcount.ca>
Date: Sat, 08 Mar 2014 16:53:48 +1100
Message-Id: <20140308055348.7E50010CFAA9@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/M6ys_aBolWq7dQaq4ow_x5KHF-c
Cc: Tony Finch <dot@dotat.at>, dnsop@ietf.org
Subject: Re: [DNSOP] pushing updates to the parent
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: Sat, 08 Mar 2014 05:54:15 -0000

In message <8C184518-2A56-42B6-BD63-3E50F8126664@hopcount.ca>ca>, Joe Abley writes
:
>
> On 7 Mar 2014, at 10:49, Tony Finch <dot@dotat.at> wrote:
>
> > Joe Abley <jabley@hopcount.ca> wrote:
> >
> >> https://xkcd.com/927/
> >
> > So from the standards development point of view, I think what this is
> > saying is that success is more likely to come from building on what
> people
> > are already doing and nudging more of them to do it more similarly.
>
> Sure, maybe.
>
> I think we have to consider our target audience. Part of that is to
> consider the existing menagerie and understanding the shape of the
> expected solutions space.
>
> While we in this group might find comfort in arcane binary protocols
> using UDP port 53, the habits of people who frequent the dyndns zoo seem
> to be far more tilted towards throwing JSON documents around over HTTP.
> It's hard to imagine unifying a pile of RESTish APIs with something that
> looks foreign and different.
>
> I'll +1 Andrew and say that I have my doubts (a) that the underscore
> scaffolding will ever appear in the top-most labels and (b) that anybody
> would use them if they did.
>
> My poorly-informed doubt is hardly a reason not to document the idea. But
> I think it's a stretch to expect anything more than an XKCD-927 result.
>
>
> Joe

Our audience should be the CPE developer with the one "turn on
DNSSEC" button which generates the keys, signs the zone, pushes
keys upstream at the right time.  It has a username/password field
for zones where it is not automatically installing KEY records as
part of the automatic delegation process.

The second audience is the DNSSEC Key management tool developer which
has a policy file which says "roll the key for this zone monthly/yearly"
and just ensures it happens.

nsupdate is how one does it today because the other bits of software
that will use the method have not yet been written because we (the
IETF) haven't provided them with a full standardised solution which
works everywhere.

nsupdate is the proof of concept tool.  It is the fill the gap tool
until the others are written.  It is the fix it tool.

However in all cases we have RRR and non-RRR managed zone and the tools
need to work with all of them.

There are lots of tools today which use nsupdate as the backend to
update the DNS after putting addresses into a IPAM.

We also have nameservers that are being renumbered that need to
push new glue records for themselves to the parent zones.  This
will happen with both signed and unsigned zones and their is no
"scraping" solution that works for this senario.

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