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 revision | 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 | |
I-D 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 Dr. Joseph D. Touch |
|
Assignment | Reviewer | Steve Hanna |
State | Completed | |
Request | Last Call review on draft-ietf-dnsext-rfc2672bis-dname by Security Area Directorate Assigned | |
Completed | 2011-06-03 |
review-ietf-dnsext-rfc2672bis-dname-secdir-lc-hanna-2011-06-03-00
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