IETF Logo Mail Archive

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

Tim Wicinski <tim.wicinski@teamaol.com> Fri, 12 July 2013 12:27 UTC

Return-Path: <tim.wicinski@teamaol.com>
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 746D921F9C89 for <dnsop@ietfa.amsl.com>; Fri, 12 Jul 2013 05:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 yYXTktBmKgGA for <dnsop@ietfa.amsl.com>; Fri, 12 Jul 2013 05:27:23 -0700 (PDT)
Received: from omr-m07.mx.aol.com (omr-m07.mx.aol.com [64.12.143.81]) by ietfa.amsl.com (Postfix) with ESMTP id 65BC521F9C88 for <dnsop@ietf.org>; Fri, 12 Jul 2013 05:27:23 -0700 (PDT)
Received: from aoldtcmei32.ad.aol.aoltw.net (aoldtcmei32.office.aol.com [10.180.121.111]) by omr-m07.mx.aol.com (Outbound Mail Relay) with ESMTP id 04F4970036476; Fri, 12 Jul 2013 08:27:22 -0400 (EDT)
Received: from still.local (172.17.8.193) by aoldtcmei32.ad.aol.aoltw.net (10.180.121.111) with Microsoft SMTP Server id 14.3.123.3; Fri, 12 Jul 2013 08:27:21 -0400
Message-ID: <51DFF628.7010608@teamaol.com>
Date: Fri, 12 Jul 2013 08:27:20 -0400
From: Tim Wicinski <tim.wicinski@teamaol.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Thunderbird/23.0
MIME-Version: 1.0
To: Warren Kumari <warren@kumari.net>, Patrik Fältst röm <paf@frobbit.se>
References: <CE0080AE.B7C0%bdickson@verisign.com> <C3DDD5D2-D59E-4026-BF99-2820281788B6@frobbit.se> <998B82B2-4CF1-471F-A791-96D6F6D9DE93@kumari.net>
In-Reply-To: <998B82B2-4CF1-471F-A791-96D6F6D9DE93@kumari.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [172.17.8.193]
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, "Dickson, Brian" <bdickson@verisign.com>
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: Fri, 12 Jul 2013 12:27:28 -0000

On 7/12/13 8:19 AM, Warren Kumari wrote:
> On Jul 8, 2013, at 3:32 PM, Patrik Fältström <paf@frobbit.se> wrote:
>
>> 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.
> And is *precisely* why this document / technique is not trying to "solve" it.

This is why this is a good idea to me.

v2.23.0 | Report a Bug | By Email