I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document: draft-ietf-dnsop-as112-dname-04 Reviewer: David L. Black Review Date: August 18, 2014 IESG Telechat Date: August 21, 2014 Summary: Ready with issues This is a relatively clear draft on the use of DNAME to black-hole reverse DNS queries to private-use IP addresses that should never be queried outside the local environment in which they are used. Based on the development of this draft in the dnsop WG, I trust that it has received good attention from DNS server operators. I found a couple of minor issues, and note that the likely increased load on the AS112 servers due to the new black-hole mechanism being easier to use - that's both an operational consideration and a security consideration. Minor issues: + Section 4 Continuity of AS112 Operations 2nd paragraph - this text is unclear: Once it has become empirically and quantitatively clear that the EMPTY.AS112.ARPA zone is well-hosted to the extent that it is thought that the existing, unmodified AS112 servers host 10.IN-ADDR.ARPA, Was the following intended?: Once it has become empirically and quantitatively clear that the EMPTY.AS112.ARPA zone is well-hosted to the extent that it is thought that use of this zone can replace the existing, unmodified AS112 servers that host 10.IN-ADDR.ARPA, + Section 9 Security Considerations This DNAME mechanism makes it easier to use AS112 DNS servers, so more use of them is likely. That may increase the opportunity for denial of service attacks on the AS112 DNS servers and the services they provide via overload (deliberate or unintentional). Nits/editorial comments: + Section 1: Introduction End of 4th paragraph: testing AS112 nameservers remotely to see whether they are configured to answer authoritatively for a particular zone is similarly challenging since AS112 nodes are distributed using anycast [RFC4786]. Insert "queries to" between "since" and "AS112 nodes". 1st line in 5th paragraph: "flexibl" -> "flexible" The notion of "sinking queries" could use some explanation - I suggest adding a sentence to describe the authoritative answer that "sinks" a query; that should mention the use of both DNAME and synthesized CNAME responses described in Section 6. + Section 8 IANA Considerations It might be helpful to repeat the fact that no request is being made to IANA to retire the existing AS112 servers, with a pointer to Section 4. + Section 8.1 IANA Considerations: Address Assignment. The next to last paragraph in this section (begins with "Once assigned,") is instructions to the RFC Editor - it would be helpful to tag that paragraph with "RFC Editor Note:" + Section 8.3. IANA Considerations: Delegation of AS112.ARPA The table should be followed by an "RFC Editor Note:" requesting that the " Nameservers:" and " DS-RDATA:" entries in the table be updated after IANA has performed the actions in Section 8.2. --- Selected RFC 5706 Appendix A discussion + Operations (A.1) Deployment (A.1.1), and migration (A.1.3) to this DNAME mechanism are discussed in Sections 3, 4 and 6. Requirements on the new BLACKHOLE.AS112.ARPA service (A.1.4) are discussed in Section 2. Installation and initial setup (A.1.2) are covered in the related draft-ietf-dnsop-rfc6304bis-04. Because it is easier to use, this DNAME mechanism is likely to increase traffic to the existing AS112 servers, possibly requiring additional and/or more powerful servers. It would be helpful to mention this operational consideration (A.1.5). Testing for correct operation (A.1.6) is covered in the related draft-ietf-dnsop-rfc6304bis-04. Configuration for use of DNAME redirection (A.1.9) is discussed in Section 3.2. + Management (A.2) DNS server management is not discussed in this draft or the related draft-ietf-dnsop-rfc6304bis-04. This should be ok, as adding use of this mechanism is unlikely to significantly change the management of DNS resolvers and servers. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------