Subject: Last Call comments on draft-ietf-dnsop-as112-dname-04

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Oct 2014 10:31:31 -0700

Thanks for the additional opportunity to comment on this draft.

I believe that the abstract does not cover the change in scope of
the AS112 service made by introducing this new mechanism.  ​The original
scope of the AS112 service was for reverse lookups that had no globally
unique mapping (RFC 1918,  link-local, etc.).  That's the scope that the
abstract mostly covers.

This mechanism, however, changes the scope of the service to
providing an NXDOMAIN to *any domain name DNAME'd to it*  (Forward tree,
 reverse tree, anywhere, really).  As the document puts it later:

   This approach has the advantage that query traffic for
   arbitrary parts of the namespace can be directed to AS112 servers
   without those servers having to be reconfigured every time a zone is
   added or removed.

There is additional language which notes that the base intent is
still related to zone of local significance:

"Since additional zones of definitively local significance are known
to exist, this presents a problem.
" from the abstract.  The context
in the abstract, though, is this:

    In addition, due to the wide deployment of private-use
   addresses and the continuing growth of the Internet, the volume of
   such queries is large and growing.  The AS112 project aims to provide
   a distributed sink for such queries in order to reduce the load on
   the IN-ADDR.ARPA authoritative servers.

That implies a scope (private-use addresses), but the mechanism
is essentially unscoped.
I think the abstract should be changed to
highlight this, since this is likely the major change others will see
from this deployment. A set of examples of the non-reverse zones
of local significance would also be useful.

Given this change in scope, I also think the draft needs some additional
language in both the security considerations section and section 6.

The security considerations section currently has only this:

   This document presents no known additional security concerns to the
   Internet.

   For security considerations relating to AS112 service in general, see
   [RFC6304bis].

This assumes that the reader is familiar with cache poisoning attacks
and the scope of such attacks enabled by the use of DNAME in the absence
of DNSSEC. While I understand the point that cache poisoning (and
even cache poisoning with DNAME) is already possible, given that this
document is setting up a broadly scoped public infrastructure that could
be used in such attacks, I believe it should either enumerate them
or point to a document that does.

Similarly, I believe the scope of section 6 needs to be broader. It
currently
covers the set of potential responses when DNAME is not supported by
a standard resolver. Sadly, there are deployments of systems which, politely
put, "augment" the results when resolution returns an NXDOMAIN. The
behaviour of these systems can be highly problematic and, depending
on the deployment, could be seriously so in this case.
​While these systems
could be characterized as "stupid DNS tricks" they are common enough,
and without warning them that a naive inference from the NXDOMAIN is
likely to be wrong, we may see some serious confusion.

Thanks for your attention,

Ted Hardie

T​
he IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'AS112 Redirection using
DNAME' <draft-ietf-dnsop-as112-dname-04.txt> as Informational RFC The IESG
plans to make a decision in the next few weeks, and solicits final comments
on this action. Please send substantive comments to the ietf at ietf.org
mailing lists by 2014-10-08. Exceptionally, comments may be sent to iesg at
ietf.org instead. In either case, please retain the beginning of the
Subject line to allow automated sorting. Subsequent to the IETF Last call
on this document. questions arose as to wether the implications of using
dname and therefore allowing zones other than those described by the draft
and previously served by the as112 project to be served by as112 project
nameservers was fully considered. We have requested an additional last call
to address this question. The mechanism specified in 3.2 can be employed in
practice by the managers of a zone without coordination with as112 server
operators. This facilitates the deployment of additional zones for the
purposes of authoritative negative answers.
http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname-04#section-3.2
Abstract Many sites connected to the Internet make use of IPv4 addresses
that are not globally unique. Examples are the addresses designated in RFC
1918 for private use within individual sites. Devices in such environments
may occasionally originate Domain Name System (DNS) queries (so-called
"reverse lookups") corresponding to those private-use addresses. Since the
addresses concerned have only local significance, it is good practice for
site administrators to ensure that such queries are answered locally.
However, it is not uncommon for such queries to follow the normal
delegation path in the public DNS instead of being answered within the
site. It is not possible for public DNS servers to give useful answers to
such queries. In addition, due to the wide deployment of private-use
addresses and the continuing growth of the Internet, the volume of such
queries is large and growing. The AS112 project aims to provide a
distributed sink for such queries in order to reduce the load on the
IN-ADDR.ARPA authoritative servers. The AS112 project is named after the
Autonomous System Number (ASN) that was assigned to it. The AS112 project
does not accommodate the addition and removal of DNS zones elegantly. Since
additional zones of definitively local significance are known to exist,
this presents a problem. This document describes modifications to the
deployment and use of AS112 infrastructure that will allow zones to be
added and dropped much more easily. The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ IESG
discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname/ballot/ No IPR
declarations have been submitted directly on this I-D.