AS112 Nameserver Operations
draft-ietf-dnsop-rfc6304bis-06

[Ballot comment]
I think this draft is a good idea and it makes perfect sense to blackhole traffic like this. 
I was glad to see the security consideration for leaking host information. Thanks for adding in the additional warnings that this data may also be logged per my prior discuss.

[Ballot comment]
Seems like a fine document. A few comments:

1. This document seems like a fine set of operational guidelines that have community consensus. Why isn't it being published as a BCP? Seems like AS112 in general should get its own BCP number and these documents ought to be published under it. Yeah, I know that 6304 was Informational, but we don't need to repeat mistakes, eh?

(Perhaps we need a new designation: Operational Practices and Guidelines.)

2. Logging is mentioned in one of the configuration examples, but it sure would be nice to have a few sentences on it. I could see saying something like, "Keeping a log of entities that are improperly querying would allow for the wagging finger of shame to be shook in front of bad implementers. You probably only want a single log entry per bad actor; they will send you lots of queries, and no need to have huge logs." Etc.

3. "The IANA is directed…" Pushy, aren't we? :-) I generally say, "IANA is requested…" or the like. No, it doesn't really make a difference.

[Ballot discuss]
I think this draft is a good idea and it makes perfect sense to blackhole traffic like this.

I was glad to see the security consideration for leaking host information.  I didn't see anywhere that such queries are logged and think a statement that they are not logged would be helpful (assuming that is the case).  Keeping such data in an aggregated spot would only amplify the concern.  If I missed it, maybe repeating that point in the security considerations section would be helpful.

Thank you.

[Ballot comment]
I have no objection to the publication of this document, but I don't
think it is appropriate to say (as in 3.1.1) what RFC 6304 does.  This
document entirely replaces 6304.

It would be fine (desirable) to have a section somewhere (probably in
App A) that captures the changes from 6304, but this document should
otherwise simply describe AS112 Nameserver Operations so that there is
no need to feel dependent on the old RFC.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dnsop-rfc6304bis-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, as requested by the Internet Draft [I-D.ietf-dnsop-as112-dname], a new IPv4 /24 netblock is to be registered in the IANA IPv4 Special Purpose Address Registry and a new IPv6 /48 netblock is to be registered in the IANA IPv6 Special Purpose Address Registry.

Second, IANA will add the following AAAA resource records for the three Direct Delegation AS112 name servers named under IANA.ORG:

+----------------------+------------------+
| Owner Name          | AAAA RDATA      |
+----------------------+------------------+
| PRISONER.IANA.ORG    | 2620:4f:8000::1  |
|                      |                  |
| BLACKHOLE-1.IANA.ORG | 2620:4f:8000::6  |
|                      |                  |
| BLACKHOLE-2.IANA.ORG | 2620:4f:8000::42 |
+----------------------+------------------+

Third, in the Special Purpose AS Number Registry located at:

http://www.iana.org/assignments/iana-as-numbers-special-registry

the following AS number will be registered:

AS Number 112
Reason for Reservation: Used by the AS112 project; see [ RFC-to-be ]
Reference: [ RFC-to-be ]

NOTE: IANA would ask the authors to consider revising the description
for the requested AS number 112:

Your proposed "Reason for Reservation":

"Used by the AS112 project; see [ RFC-to-be ]"

Change to:

"For sinkholing misdirected DNS queries. Reserved by [RFCXXXX]"

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (AS112 Nameserver Operations) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'AS112 Nameserver Operations'
  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@ietf.org mailing lists by 2014-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 corresponding authoritative servers.  The AS112 project is named
  after the Autonomous System Number (ASN) that was assigned to it.

  RFC6304 described the steps required to install a new AS112 node, and
  offered advice relating to such a node's operation.  This document
  updates that advice to facilitate the addition and removal of zones
  for which query traffic will be sunk at AS112 nodes, using DNAME,
  whilst still supporting direct delegations to AS112 name servers.

  This document obsoletes RFC6304.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc6304bis/ballot/


No IPR declarations have been submitted directly on this I-D.

This is a document shepherd write-up of draft-ietd-dnsop-rfc6304bis-03,
structured according to the requirements of RFC 4858 and following
the corresponding template dated 24 February 2012.

1)
  Intended status of draft-ietf-dnsop-rfc6304bis is Informational,
  consistent with RFC6304 which it aims to replace.

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 corresponding authoritative servers.  The AS112 project is named
  after the Autonomous System Number (ASN) that was assigned to it.

  RFC6304 described the steps required to install a new AS112 node, and
  offered advice relating to such a node's operation.  This document
  updates that advice to facilitate the addition and removal of zones
  for which query traffic will be sunk at AS112 nodes, using DNAME,
  whilst still supporting direct delegations to AS112 name servers.

Working Group Summary:

  Since this document was an update of RFC 6304, the point was
  raised that the Internet had changed some and that there were
  better mechanisms to aid in these configurations. Specially
  around IPv6 transport, and also to allow for using DNAME.  The
  outcome of this discussion was draft-ietf-dnsop-as112-dname-03.

Document Quality:

  The document updates an existing RFC that has gone through the
  IETF RFC editorial process and is reflecting changing best
  practices. Therefore existing implementations exist, and have
  been observed for some time.

Personnel:

  The Document Shepherd is Tim Wicinski.

  The dnsop working group chairs are Tim Wicinski and Suzanne
  Woolf.

  The Area Director is Joel Jaggeli.

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 concerns about the depth or breath
  of the reviews. The document has cycled through the WG several
  times, each with very detailed and useful reviews.

5)
  In the view of the Document shepherd, no 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 IPR disclosure has been made.

9)
  There is solid working group consensus.  The documents were
  presented in several meetings, as well as a long mailing list
  discussion, and the consensus all areas have been covered.

10)
  No appeal has been indicated and there is no extreme discontent.

11)
  Most nits raised are in reference to the subject matter (e.g.
  the use of non-RFC5737 addresses for good reason, since the
  addresses specified are the actual addresses that need to be
  used, not example addresses).

  == Missing Reference: 'THIS DOCUMENT' is mentioned on line 793, but not
    defined

  This is a reference to the document itself for the purposes of
  registration in an IANA registry. This nit will be addressed upon
  the assignment of an RFC number to this document, as part of the
  RFC Editor's review.

  == In section 10, Acknowledgments, the document thanks individuals for
  their assistance in the preparation of the current document, but references
  it as RFC6304. This will need to be adjusted during the editing process.

(12)
  No such formal review is needed.

13)
  All references have been identified as either normative or
  informative.

14)
  There is a reference to a document ietf-dnsop-as112-dname which
  is being submitted to the IESG in a bundle with this document.
  The document shepherd suggests both documents be considered for
  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)
  This document is intended to obsolete RFC6304.

17)
  This document requests that an AAAA RRSet be added to each of
  PRISONER.IANA.ORG, BLACKHOLE-1.IANA.ORG and BLACKHOLE-2.IANA.ORG.
  The request is clear and actionable.

  This document registers one code point in the Special-Purpose
  AS Numbers registry. The registry to be updated is well-described,
  and informal review of the IANA Considerations section by IANA
  staff suggests no problem with this registration.

  This document does not create any new IANA registries.

(18)
  This document does not create any new IANA registries.

(19)
  The document shepherd has performed checks (or, in some cases,
  has delegated checks to others) to confirm that the configuration
  examples provided for BIND9 and Quagga are accurate.

  The document shepherd confirms that based on all tests performed,
  the examples are accurate and usable.