Re: [dnsext] Extending UPDATE to add/remove zones

Jay Daley <jay@nzrs.net.nz> Wed, 16 October 2013 22:31 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 C872811E81D7 for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 15:31:42 -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=[AWL=0.000, 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 6uqRKqWVv0hl for <dnsext@ietfa.amsl.com>; Wed, 16 Oct 2013 15:31:38 -0700 (PDT)
Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8557211E818D for <dnsext@ietf.org>; Wed, 16 Oct 2013 15:31:34 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id C6DE34B7A7B; Thu, 17 Oct 2013 11:31:32 +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 sb3T+yABQGFV; Thu, 17 Oct 2013 11:31:24 +1300 (NZDT)
Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id E0E3C4B7A8B; Thu, 17 Oct 2013 11:31:24 +1300 (NZDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jay Daley <jay@nzrs.net.nz>
In-Reply-To: <000201cecabc$dc64f7b0$952ee710$@rozanak.com>
Date: Thu, 17 Oct 2013 11:31:24 +1300
Content-Transfer-Encoding: quoted-printable
Message-Id: <58918AA6-2721-4CA2-BE72-19B755FD058E@nzrs.net.nz>
References: <B677F769-D8AF-4EC8-9C58-1116B840AA49@nzrs.net.nz> <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> <000201cecabc$dc64f7b0$952ee710$@rozanak.com>
To: Hosnieh Rafiee <ietf@rozanak.com>
X-Mailer: Apple Mail (2.1510)
Cc: dnsext@ietf.org
Subject: Re: [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 22:31:42 -0000

On 17/10/2013, at 11:12 AM, "Hosnieh Rafiee" <ietf@rozanak.com> wrote:

> Sorry I forgot to submit it to the list ...
> 
>> No Hosnieh I'm not falling for that.  If you think there is any
> overlap/conflict/interaction between my proposed work and the cga-tsig draft
> then please >identify it and I will address it.  
> 
>> To be clear, since it appears to me that you might not have understood, the
> only idea I am floating around TSIG is that a DNSKEY record is given to a
>> nameserver with the intention that is should use to authenticate (via TSIG)
> a zone transfer request for a new zone that it is asked to serve as a slave.
> 
> I am attempting to rephrase my question. Correct me if I am wrong... I think
> DNSKEY is for DNSSEC and not for TSIG. TSIG uses shared secret and it is
> added to DNS configuration file (isn't stored in any record in database) .
> dissimilar to a part of DNSSEC it is not public key cryptography. This means
> that you cannot add the shared secret in DNSKEY for authentication. Security
> problem... TSIG might use TKEY which is different than DNSKEY. 

Yes it probably ought to be TKEY since this is what it is specifically designed for and not a DNSKEY but DNSKEY is so much simpler so I was just trying it on ...

> Secondly, I guess addressing TSIG here does not really make sense as you are
> not fully addressing security but you're planning to make the DNS update
> more efficient. So, I suggest that you only think about  making the Update
> more efficient and let other approaches like other RRs TSIG, cga-tsig secure
> your approach. 

You've misunderstood why the TSIG key appears in this message.  I am investigating adding new functionality to UPDATE and part of that new functionality requires the transmission of a TSIG key as data inside the packet, for the receiver to use elsewhere.  This TSIG key is not used in this transaction.

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