This is a document shepherd write-up of draft-ietd-dnsop-as112-dname-04,
structured according to the requirements of RFC 4858 and following
the corresponding template dated 24 February 2012.
1)
Requested status is Informational.
This document describes an approach for mitigating a key deficiency
in the existing ("Direct Delegation") model of AS112 deployment
that makes use of DNAME, namely the difficulty in adding or
dropping particular zones from the AS112 infrastructure.
The use of DNAME for this purpose is novel, and while some
experiments (as described in this document) have indicated
widespread support across the Internet for DNAME and have confirmed
that the approach is functionally feasible, DNAME has not been
previously used for AS112 in the wild. Note that the document
does not propose immediate refactoring of the direct delegation
approach for existing zones sunk in the AS112 infrastructure.
Given the experimental aspects of this approach the document
shepherd and the authors are not opposed to Experimental status.
However, the document shepherd feels that Informational is
preferred given plausible indications that the dependent mechanism
(i.e. DNAME) are well-defined, well-deployed and suitable for
the purpose.
2)
Technical Summary:
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.
Working Group Summary:
There were no notable outcomes from the WG process or in the
working-group last call. The dnsop working group chair observed
strong consensus on the text and the approach described by the
text following presentations and discussion on the mailing list
and in multiple in-person meetings.
Document Quality:
The document describes the use of protocols that are already
defined and implemented to augment AS112 infrastructure. The
approach was validated by experiment, and an abridged summary
of that experiment and its results are included in the document.
The Acknowledgements section of the diagram does not omit to
mention any significant reviewer.
The working group review included input from participants with
significant DNS protocol and operations expertise, and in the
opinion of this document shepherd and the working group chairs
no additional expert consultation is required.
Personnel:
The document shepherd is Tim Wicinski.
The dnsop working group chairs are Tim Wicinski and Suzanne
Woolf.
The responsible area director is Joel Jaeggli.
3)
The document shepherd reviewed this document for clarity, potential
for ambiguity or self-contradiction, technical accuracy and
operational impact.
It is the document shepherd's opinion that this document is ready
to forward to the IESG.
4)
The document shepherd has no such concern.
5)
In the opinion of the document shepherd, no further or wider review
is necessary.
6)
The document shepherd has no such concern and has identified no
such issue.
7)
No IPR disclosures have been made for this document.
The authors have indicated that no IPR disclosures are intended
to be made.
The document shepherd has identified no reasons for an IPR
disclosure to be made.
8)
No such IPR disclosure has been made.
9)
The document shepherd and dnsop working group chairs have identified
strong working group consensus for this document to proceed.
The document has been discussed at some length on the dnsop mailing
list and has also been presented in multiple face-to-face meetings.
10)
The document shepherd and working group chairs are aware of no
such threat or discontent.
11)
No I-D nits have been identified by the document shepherd.
12)
No such formal review is required for this document.
13)
All references have been identified as either normative or
informative.
14)
This document contains a normative reference to
draft-ietf-dnsop-rfc6304bis which is being submitted to the IESG
in a bundle with this document. The document shepherd suggests
that both documents be considered by the IESG together, since
they reference each other. Following direction from the IESG to
proceed, both documents would most naturally proceed through the
publication process together.
15)
There are no downward normative references.
16)
Publication of this document will not change the status of any
existing RFC.
17)
The document shepherd has been informed by the authors that the
IANA Considerations section has already been informally reviewed
by IANA staff, and that changes informally suggested have been
implemented.
All number resource assignments and directions relating to the
delegation of a zone from the ARPA TLD have been confirmed (again,
informally) to be clear and actionable.
No new registries are requested by this document.
The use of a name under the ARPA TLD requires IAB approval, per
RFC 3172. This document includes an IAB Considerations section
that is sufficient to request and document the IAB's review, in
the opinion of the document shepherd.
18)
No new registries are requested by this document.
19)
This document contains no such section.