Re: [nscp] Welcome (and proposed charter)

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 15 September 2010 18:57 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: nscp@core3.amsl.com
Delivered-To: nscp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6523A69B4 for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 11:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level:
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACupVdkcWE5z for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 11:57:12 -0700 (PDT)
Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id CE0AA3A6914 for <nscp@ietf.org>; Wed, 15 Sep 2010 11:57:11 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8FIvZ0V023639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Sep 2010 14:57:35 -0400 (EDT)
Date: Wed, 15 Sep 2010 14:57:35 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: jad <jad@sinodun.com>, Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <F41F5A3D292BA66474A70422@minbar.fac.cs.cmu.edu>
In-Reply-To: <20899_1284570202_o8FH3Loi023191_1F675FEC-C6FE-480D-A598-44BCBFCD46C0@sinodun.com>
References: <4C9091C8.1030702@isc.org> <p062408d6c8b692e2c226@[10.20.30.158]> <A5289BAE-189D-4FF0-8AEC-2CCDC06D3B43@sinodun.com> <p062408dbc8b6aaf55b1a@[10.20.30.158]> <20899_1284570202_o8FH3Loi023191_1F675FEC-C6FE-480D-A598-44BCBFCD46C0@sinodun.com>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.198
Cc: nscp@ietf.org, jhutz@cmu.edu
Subject: Re: [nscp] Welcome (and proposed charter)
X-BeenThere: nscp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Nameserver control/configuration protocol discussion list <nscp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nscp>
List-Post: <mailto:nscp@ietf.org>
List-Help: <mailto:nscp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2010 18:57:12 -0000

--On Wednesday, September 15, 2010 06:03:12 PM +0100 jad <jad@sinodun.com> 
wrote:

>
> On Sep 15, 2010, at 5:57 PM, Paul Hoffman wrote:
>
>> At 5:53 PM +0100 9/15/10, jad wrote:
>>> On Sep 15, 2010, at 4:30 PM, Paul Hoffman wrote:
>>>
>>>> At 11:28 AM +0200 9/15/10, Jelte Jansen wrote:
>>>>> Objective
>>>>> - ---------
>>>>>
>>>>> Specify an interoperable mechanism to monitor, control and configure
>>>>> common functionality of DNS nameservers.
>>>>
>>>> Probably the most common functionality is updating zone files. Is this
>>>> in scope, out of scope, or not determined yet? There is clamoring for
>>>> secure updating that is easier to configure and than SIG0 and its
>>>> friends, and almost no one cares if this is done in the DNS protocol,
>>>> so this WG might or might not be the right place for that.
>>>
>>> Our thinking at the time was that nscp would need some limited
>>> mechanism to create new zones. You need at least an SOA and filename
>>> after all. However, there are many ways that the zone data could be
>>> inserted into the zone. Dynamic updates,. AXFR, checkout from
>>> subversion, database.....
>>>
>>> So I do think that the bulk creation/insertion of zone data is out of
>>> scope. However, configuration of the nameserver so that it knows how to
>>> get that data is in scope.
>>
>> If you think it is out of scope, the charter needs to day that.
>>
>> OTOH, why not allow it using the same mechanism that is being used for
>> the rest of the control? That is, don't prevent "Dynamic updates,. AXFR,
>> checkout from subversion, database.....", but specify how to do it the
>> same way as the rest of the control?
>
> Sure, I wouldn't prevent nscp from updating zones. But I don't think nscp
> would be the best way or my first choice. So maybe saying "out of scope"
> is a bit strong.

In fact, I think it very much should be in scope.  Loading generated 
records from a zone file is a non-starter if you're also going to allow 
dynamic updates to that zone, and loading updates via DDNS, while possible 
is extremely annoying.  To make loading generated zone data work well, I 
need to keep metadata alongside each record indicating where it came from, 
so I can distinguish changes made by DDNS clients from situations where the 
zone simply doesn't match the current version of the generated data.  Today 
I do that by keeping a specially-formatted TXT record alongside each "real" 
record, so they can be updated at the same time (as part of the same 
(atomic) DDNS update).  I'd much rather do zone content management outside 
the DNS protocol, with the server not only keeping my record-origin 
metadata but also providing me with information about when a record was 
last updated and by what client, which doesn't appear in the DNS.

IMHO, zone content management certainly should be in scope.

-- Jeff