[secdir] secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt

Stephen Hanna <shanna@juniper.net> Wed, 01 June 2011 18:16 UTC

Return-Path: <shanna@juniper.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8C130019; Wed, 1 Jun 2011 11:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtzT3GvZjxUu; Wed, 1 Jun 2011 11:16:07 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9513000B; Wed, 1 Jun 2011 11:15:57 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTeaB3M4VN40gRIuNMaxAOQeXj9LBkRTp@postini.com; Wed, 01 Jun 2011 11:16:02 PDT
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 1 Jun 2011 11:15:18 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 1 Jun 2011 14:15:17 -0400
From: Stephen Hanna <shanna@juniper.net>
To: "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-dnsext-rfc2672bis-dname@tools.ietf.org" <draft-ietf-dnsext-rfc2672bis-dname@tools.ietf.org>
Date: Wed, 1 Jun 2011 14:15:15 -0400
Thread-Topic: secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt
Thread-Index: Acwgh9s80YeQfWrkRySR5CC9/YhwJg==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB57B40575D@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" <ietf@ietf.org>
Subject: [secdir] secdir review of draft-ietf-dnsext-rfc2672bis-dname-22.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 01 Jun 2011 18:16:08 -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 intends to replace RFC 2672, the definition of DNAME
redirection in the DNS. DNAME is a DNS resource record type that
(in layman's terms) indicates that all domain names ending in a
specified suffix should be redirected to domain names where the
suffix is replaced by a specified value. For example, all names
that end with example.com should be remapped to example.net.

The document is quite thorough, apparently because the DNAME RR
has been used for many years and a great deal of real-world
experience has been gained. That's definitely a good thing!

>From a security perspective, this document includes a more
thorough analysis of security considerations than the original
RFC 2672. It also includes a more thorough discussion of DNSSEC
interactions than the earlier document.

I do not see any security issues that are not well covered in
this document. While I don't think this document will close any
major security issues, it includes some helpful guidance. So
I recommend that this document advance to RFC status.

Thanks,

Steve