Last Call Review of draft-ietf-dnsext-rfc2672bis-dname-
review-ietf-dnsext-rfc2672bis-dname-secdir-lc-hanna-2011-06-03-00

Request Review of draft-ietf-dnsext-rfc2672bis-dname
Requested rev. no specific revision (document currently at 26)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-06-09
Requested 2011-05-27
Authors Scott Rose, Wouter Wijngaards
Draft last updated 2011-06-03
Completed reviews Secdir Last Call review of -?? by Steve Hanna
Secdir Telechat review of -?? by Steve Hanna
Tsvdir Last Call review of -?? by Joseph Touch
Assignment Reviewer Steve Hanna
State Completed
Review review-ietf-dnsext-rfc2672bis-dname-secdir-lc-hanna-2011-06-03
Review completed: 2011-06-03

Review
review-ietf-dnsext-rfc2672bis-dname-secdir-lc-hanna-2011-06-03

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