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.