Skip to main content

Telechat Review of draft-ietf-dnsop-as112-dname-04
review-ietf-dnsop-as112-dname-04-opsdir-telechat-black-2014-08-25-00

Request Review of draft-ietf-dnsop-as112-dname
Requested revision No specific revision (document currently at 06)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2014-08-19
Requested 2014-08-05
Authors Joe Abley , Brian Dickson , Warren "Ace" Kumari , George G. Michaelson
Draft last updated 2014-08-25
Completed reviews Genart Last Call review of -04 by Roni Even (diff)
Opsdir Telechat review of -04 by David L. Black (diff)
Opsdir Telechat review of -04 by Scott O. Bradner (diff)
Secdir Last Call review of -04 by Klaas Wierenga (diff)
Assignment Reviewer David L. Black
State Completed
Review review-ietf-dnsop-as112-dname-04-opsdir-telechat-black-2014-08-25
Reviewed revision 04 (document currently at 06)
Result Has Issues
Completed 2014-08-25
review-ietf-dnsop-as112-dname-04-opsdir-telechat-black-2014-08-25-00
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
----------------------------------------------------