IETF Logo Mail Archive

[dnsext] Extending UPDATE to add/remove zones

Jay Daley <jay@nzrs.net.nz> Wed, 16 October 2013 09:33 UTC

Return-Path: <jay@nzrs.net.nz>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3064511E8178 for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 02:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm-Lm+-UArWE for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 02:33:14 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEAF21F9E01 for <dnsext@ietf.org>; Wed, 16 Oct 2013 02:33:14 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id BD2304B80FA for <dnsext@ietf.org>; Wed, 16 Oct 2013 22:33:12 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz
Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oQ10CcAW1P5 for <dnsext@ietf.org>; Wed, 16 Oct 2013 22:33:04 +1300 (NZDT)
Received: from [192.168.1.230] (121-74-114-181.telstraclear.net [121.74.114.181]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id B740F4B80E5 for <dnsext@ietf.org>; Wed, 16 Oct 2013 22:33:04 +1300 (NZDT)
From: Jay Daley <jay@nzrs.net.nz>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <B677F769-D8AF-4EC8-9C58-1116B840AA49@nzrs.net.nz>
Date: Wed, 16 Oct 2013 22:33:03 +1300
To: "dnsext@ietf.org Group" <dnsext@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [dnsext] Extending UPDATE to add/remove zones
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 09:33:19 -0000

From my previous post on my draft for a new DNS opcode - servezones - I think there is reasonable interest in an in-band mechanism that instructs a nameserver to etiher start or stop serving one or more zones.  The area with less certainty is what that mechanism should be, a new Opcode (but it's only a 4 bit space!) or extending UPDATE.

I'm planing to write a draft that shows how UPDATE could be extended to do this and then we can compare that with my servezones draft and see which is preferred.  To do that I'd like some help in determining the algorithm for how the extended UPDATE is processed. 

Here's my starter for 10.

1.  A new EDNS option code is assigned that changes the behaviour of the UPDATE as follows (alternatively this could be signalled with a ZTYPE different from SOA)

2.  The ZONE section specifies the zones to be added/removed.  There can be any number of zones listed here to add or remove.  For each zone, if the CLASS is ANY then the zone is to be removed, whereas if it is ANY then the zone is to be added.  This use of CLASS corresponds to the way that it is used to determine if an rrset should be added or removed in the current UPDATE message.

3.  The pre-requisite section is ignored.

4.  The Update section can only contain Adds and only when zones are to be added.  If any records are specified here then that means that the zones to be added are masters and these records are all added to those zones before serving begin.   None of these records may be fully qualified so as to ensure that they apply to all the zones listed.  One of these records must be a SOA record with an empty name, which will be replaced with the zone name

5.  If there is data in the Additional section then that signifies that the zones to be added are slaves.   The records here must be NS records that specify the masters for the zones to be added.  There can only be records here or in the Update section but not both as zones cannot be both masters and slaves.

Is that it? Anything need changing?


BTW we could extend this just a little bit more:

6.  If there is a DNSKEY record in the Additional section then this specifies a TSIG key that this server should use for pulling the zone.  The name for the DNSKEY record is the name of the key as used by TSIG.  This DNSKEY is not added into the zone.


Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

v2.23.0 | Report a Bug | By Email