IETF Logo Mail Archive

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

Jim Reid <jim@rfc1035.com> Tue, 08 July 2014 15:29 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3B1A007E for <dnsop@ietfa.amsl.com>; Tue, 8 Jul 2014 08:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMg0iwejKSP1 for <dnsop@ietfa.amsl.com>; Tue, 8 Jul 2014 08:29:57 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEE11A009E for <dnsop@ietf.org>; Tue, 8 Jul 2014 08:29:57 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id B7FCE2420616; Tue, 8 Jul 2014 15:29:55 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <alpine.LSU.2.00.1407081608590.13901@hermes-1.csi.cam.ac.uk>
Date: Tue, 08 Jul 2014 16:29:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BCB7737-BC45-43A1-9E1B-D2306BE24BA9@rfc1035.com>
References: <20140703211746.18462.44333.idtracker@ietfa.amsl.com> <1C377AE9-2B16-4FCB-9612-48AB0E6EB2B3@vpnc.org> <etPan.53b82396.4353d0cd.38df@walrus.hopcount.ca> <EB6D8EA8-A3AD-4740-A202-4ACA656B6A17@fl1ger.de> <alpine.LSU.2.00.1407081608590.13901@hermes-1.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/iJSFdxJeV6j480kMwyLuQSYELqw
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 08 Jul 2014 15:29:58 -0000

On 8 Jul 2014, at 16:14, Tony Finch <dot@dotat.at> wrote:

> simply slaving the root zone doesn't give you any good way to detect or recover from a corrupted zone transfer.

If that's a credible threat/risk, there are ways to mitigate it. Perhaps v2 of this draft could discuss these.

FWIW in playing with DNS for 20-odd years, I've never come across an actual example of zone transfer corruption, either in the protocol or the underlying TCP transport. That doesn't mean it can't happen of course. The risks are close to zero IMO. Which doesn't necessarily mean they should be ignored.

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