IETF Logo Mail Archive

Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt

Patrik Fältström <paf@frobbit.se> Mon, 08 July 2013 19:32 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E41421F9C55 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2013 12:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 y7dOwmrDYsSs for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2013 12:32:21 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 5334821F9C53 for <dnsop@ietf.org>; Mon, 8 Jul 2013 12:32:21 -0700 (PDT)
Received: from vpn-client-208.netnod.se (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 9C4C923F8D; Mon, 8 Jul 2013 21:32:19 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <CE0080AE.B7C0%bdickson@verisign.com>
Date: Mon, 08 Jul 2013 21:32:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3DDD5D2-D59E-4026-BF99-2820281788B6@frobbit.se>
References: <CE0080AE.B7C0%bdickson@verisign.com>
To: "Dickson, Brian" <bdickson@verisign.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] New Version Notification for draft-kumari-ogud-dnsop-cds-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jul 2013 19:32:23 -0000

On 8 jul 2013, at 20:49, "Dickson, Brian" <bdickson@verisign.com> wrote:

> However, maybe something like a "PNS" (parent NS) in the child, where the
> child is authoritative for the data, could signal {change | validation}
> (depending on the RRR requirements), would do the trick?

Might solve some events, but I do not think it solves the most important situation, that DNS is moved from one DNS provider to another. The old DNS provider can not be asked to enter NS records for the gaining provider... And using NS (in reality, as you look for auth servers) to fetch NS data seems to me be a bit...fishy... ;-) The attack vector against such a situation is very complicated.

   Patrik

v2.23.0 | Report a Bug | By Email