Re: [nscp] Updating zone *content* in-scope or not?

Lars-Johan Liman <liman@autonomica.se> Thu, 16 September 2010 19:28 UTC

Return-Path: <liman@autonomica.se>
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 225C53A69DA for <nscp@core3.amsl.com>; Thu, 16 Sep 2010 12:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, RDNS_DYNAMIC=0.1]
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 XNiU91NFTGva for <nscp@core3.amsl.com>; Thu, 16 Sep 2010 12:28:07 -0700 (PDT)
Received: from mail-ng.cafax.se (mail-ng.cafax.se [IPv6:2a00:801:11:53::4]) by core3.amsl.com (Postfix) with ESMTP id 868A73A69D8 for <nscp@ietf.org>; Thu, 16 Sep 2010 12:28:07 -0700 (PDT)
Received: from ziptop.autonomica.net (2-1-3-18a.spa.sth.bostream.se [82.182.146.229]) by mail-ng.cafax.se (8.14.4/8.14.4) with ESMTP id o8GJQNtU020333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nscp@ietf.org>; Thu, 16 Sep 2010 21:26:24 +0200 (MEST)
Received: from ziptop.autonomica.net (localhost [IPv6:::1]) by ziptop.autonomica.net (8.14.4/8.14.4) with ESMTP id o8GJSOFO001843 for <nscp@ietf.org>; Thu, 16 Sep 2010 21:28:27 +0200 (CEST)
From: Lars-Johan Liman <liman@autonomica.se>
To: nscp@ietf.org
References: <4C9091C8.1030702@isc.org> <p062408d6c8b692e2c226@[10.20.30.158]> <A5289BAE-189D-4FF0-8AEC-2CCDC06D3B43@sinodun.com> <p062408dbc8b6aaf55b1a@[10.20.30.158]> <F41F5A3D292BA66474A70422@minbar.fac.cs.cmu.edu> <20100916130131.GA29091@nic.fr> <p0624081fc8b7e8b23cc0@[10.20.30.158]>
Date: Thu, 16 Sep 2010 21:28:24 +0200
In-Reply-To: <p0624081fc8b7e8b23cc0@[10.20.30.158]> (Paul Hoffman's message of "Thu\, 16 Sep 2010 08\:35\:57 -0700")
Message-ID: <22r5gtcwtj.fsf@ziptop.autonomica.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [nscp] Updating zone *content* in-scope or not?
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: Thu, 16 Sep 2010 19:28:09 -0000

Hi, Paul!

On Wed, Sep 15, 2010 at 02:57:35PM -0400, Jeffrey Hutzelman <jhutz@cmu.edu>; wrote
>>> IMHO, zone content management certainly should be in scope.

At 3:01 PM +0200 9/16/10, Stephane Bortzmeyer wrote:
>> -1 for a practical reason: we already have several good ways to update
>> zone content and two are standard and use the DNS (RFC 2136 and
>> 5936).

paul.hoffman@vpnc.org:
> Aren't those only applicable when the zone admin is also running a DNS
> server, brings it up to date, and then tells the DNS admin to
> synchronize? And aren't there *many* other deployment scenarios for
> DNS content?

This discussion can continue from here to eternity and back - and
probably will. ;-)

I agree with Stéphane that there are already standardized mechanisms to
handle zone content updates. I may well be that they require the zone
admin to run a DNS server, but you _can_ (and that's an obvious future
to me) send dynamic updates from an application that doesn't work as a
DNS server _to_ the master server, so _some_ of your cases can probably
be dealt with, but not all. *)

I agree with you that there may be scenarios where these mechanisms are
suboptimal or even inappropriate, but there is at list _a_ mechanism (or
two) for that, whereas in the case of sending "commands" to the DNS
server, there is none.

So, my proposal is

a) Let's cut out a limited piece of work for ourselves to start with,
   and make sure we get to the other end of it in forseeable time.

b) When we do so, we should focus on things for which we have _no_
   current alternative, as opposed to things for which we have already
   at least one alternative, imperfect as it may be.

I.e., leave out updating zone content for now - at least zone content
for which the receiving end is authoritative.

				Cheers,
				  /Liman

*) One obvious case that _cannot_ be dealt with using dynamic updates is
"remove this record from the cache". There are most certainly more.

#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.   ! E-mail/SIP/Jabber: liman@autonomica.se
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Autonomica AB, Stockholm  ! http://www.autonomica.se/
#----------------------------------------------------------------------