[secdir] Secdir review of draft-ietf-dnsop-rfc6304bis-04

Brian Weis <bew@cisco.com> Fri, 08 August 2014 02:04 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F2CBC1A03F7; Thu, 7 Aug 2014 19:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Es6iUs-UOKkO; Thu, 7 Aug 2014 19:04:46 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708FF1A03FF; Thu, 7 Aug 2014 19:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1407463486; x=1408673086; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=duDq+YENeWZXZ/GAIF4++mCH4INg265ZRdDHIoIS2s8=; b=KWBP3QguFUreP+dUbCBjPjhrlMPVnu4DGfB/zB83qZ8eG78+rgi2Q1Nn /GeIY7oZo2O+8M/9YIWJh4P+6K6CnBezefWkWVbd+BEQFkgVJ9dg9GU8W sfWoJJkorMq7zilYJGB1mVYlHiJKXO6jYf7FU4R7KQ51PsCGclV+YKrT7 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlMFACgv5FOtJV2b/2dsb2JhbABagw2vIAEBAQIBBQFuAaUugRcWd4REP4E+AYhUxBcXhXyIeFiDNoEcBYsWkQWHJI1Mg3cdgTM
X-IronPort-AV: E=Sophos;i="5.01,821,1400025600"; d="scan'208";a="345752328"
Received: from rcdn-core-4.cisco.com ([]) by rcdn-iport-1.cisco.com with ESMTP; 08 Aug 2014 02:04:46 +0000
Received: from [] ([]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7824icn004489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Aug 2014 02:04:45 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 07 Aug 2014 19:04:44 -0700
Message-Id: <FCB6067F-C087-4429-A12F-14B3D661412E@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/w9Qb-H7Xah1iD9t7W4lhgMiE5J0
Cc: draft-ietf-dnsop-rfc6304bis.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-dnsop-rfc6304bis-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 02:04:48 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document replaces RFC 6304, which describes AS112 Nameserver operations. AS112 nameservers are responsible for answering DNS reverse lookup to private-use queries that somehow leaked out of private network into the Internet. RFC 6304 described the operations for these DNS name servers handling these queries. The main contribution of the present document is support for a new DNAME redirection zone defined in draft-ietf-dnsop-as112-dname-03, including adding it to the sample BIND9 configurations. It also updates the BIND9 configurations to support IPv6, and includes a number of new IANA actions.

Although I have a limited DNS background, the advice in this document appears to be conservative such that attacks on or using AS112 name servers are mitigated as much as possible in the absence of DNSSEC. 

The security considerations section ends with a statement that DNSSEC is unlikely to be effective for AS112 name servers and I believe the rationale is accurate. Any entity wishing to provide an AS112 name server to provide a service of replying to private-use queries is encouraged to do so. Because AS112 name servers are announced via anycast, all AS112 name servers would be required to use a single public key. This indicates that the corresponding private key would need to be widely available, which rather defeats its purpose.