IETF Logo Mail Archive

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Sat, 14 September 2013 13:29 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9837B11E817A for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2013 06:29:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.06
X-Spam-Level:
X-Spam-Status: No, score=-0.06 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 qRvCmZdFgbvR for <ietf@ietfa.amsl.com>; Sat, 14 Sep 2013 06:29:49 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id EEB2D11E817B for <ietf@ietf.org>; Sat, 14 Sep 2013 06:29:48 -0700 (PDT)
Received: (qmail 2070 invoked from network); 14 Sep 2013 13:24:36 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 14 Sep 2013 13:24:36 -0000
Message-ID: <5234644C.505@necom830.hpcl.titech.ac.jp>
Date: Sat, 14 Sep 2013 22:27:40 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Dickson, Brian" <bdickson@verisign.com>
Subject: Re: [DNSOP] Practical issues deploying DNSSEC into the home.
References: <CE577135.D32F%bdickson@verisign.com>
In-Reply-To: <CE577135.D32F%bdickson@verisign.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: Theodore Ts'o <tytso@mit.edu>, "ietf@ietf.org TF" <ietf@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Evan Hunt <each@isc.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>, Paul Wouters <paul@nohats.ca>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2013 13:29:54 -0000

Dickson, Brian wrote:

> In order to subvert or redirect a delegation, the TLD operator (or
> registrar) would need to change the DNS server name/IP, and replace the DS
> record(s).

Only to a victim to be deceived.

> This would be immediately evident to the domain owner, when they query the
> TLD authority (delegation) servers.

Wrong. The domain owners can't know some victims are supplied
faked data.

							Masataka Ohta

v2.30.2 | Report a Bug | By Email | System Status