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

Paul Hoffman <> Thu, 16 September 2010 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 834753A6A2C for <>; Thu, 16 Sep 2010 14:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.254
X-Spam-Status: No, score=-101.254 tagged_above=-999 required=5 tests=[AWL=0.792, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gZLcKubVFdrV for <>; Thu, 16 Sep 2010 14:19:26 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id 903533A68AD for <>; Thu, 16 Sep 2010 14:19:26 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id o8GLJkUa071485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Sep 2010 14:19:48 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240837c8b839e8f192@[]>
In-Reply-To: <>
References: <> <p062408d6c8b692e2c226@[]> <> <p062408dbc8b6aaf55b1a@[]> <> <> <p0624081fc8b7e8b23cc0@[]> <>
Date: Thu, 16 Sep 2010 14:19:45 -0700
To: Lars-Johan Liman <>,
From: Paul Hoffman <>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [nscp] Updating zone *content* in-scope or not?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Nameserver control/configuration protocol discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Sep 2010 21:19:27 -0000

At 9:28 PM +0200 9/16/10, Lars-Johan Liman wrote:
>Hi, Paul!
>On Wed, Sep 15, 2010 at 02:57:35PM -0400, Jeffrey Hutzelman <> 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).
>> 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. ;-)

Given that it already has, and eternity is ahead of us, yes.

>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 was not aware of those applications. Can you point to some examples?

>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.

That works for me, although it should probably be written into the charter.

--Paul Hoffman, Director
--VPN Consortium