Additional IPv4 Delegations for AS112
draft-sotomayor-as112-ipv4-cull-00

Abstract

This is a direction to IANA concerning the delegation of certain additional IPv4 zones to the AS112 project.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 05, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Reverse DNS Delegation, Local-Use and Test Addresses
• 3. Impact of Lame DNS Reverse Delegations by Misconfigured AS112 Nodes
• 4. IANA Considerations
• 5. Security Considerations
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Change History
• Author's Address

1. Introduction

This is a direction to IANA concerning the delegation of certain additional IPv4 zones to the AS112 Project [I-D.ietf-dnsop-as112-ops] which operates in an anycast cloud [RFC4786].

2. Reverse DNS Delegation, Local-Use and Test Addresses

Work documenting special use addresses [RFC5735] have appeared containing good candidates for inclusion with the existing delegations to the AS112 Project. These local and special use addresses have now been captured and identified for Domain Name System (DNS [RFC1034] and [RFC1035]) zone administrators to curtail leaking queries in [I-D.ietf-dnsop-default-local-zones].

Additionally, [RFC5737] identifies a short listing of IPv4 address blocks for use in documentation. These too should be considered for delegation to the AS112 Project.

Thus the purpose of this memo is to effectively signal to the AS112 Project [I-D.ietf-dnsop-as112-ops] that it should reflect the efforts of [I-D.ietf-dnsop-default-local-zones] and follow directives and delegations subsequently issued as described in section 6.

It is interesting to note that while the focus has largely been on the use of [RFC1918] addresses, some addresses (such as those first enumerated within [RFC1912]) have as of late also been the subject of [I-D.ietf-dnsop-default-local-zones] .

3. Impact of Lame DNS Reverse Delegations by Misconfigured AS112 Nodes

Although not discussed previously in any related memo before, there exists the issue of AS112 nodes not being current with the published IANA registry or simply missing zones that they should be hosting on behalf of the global DNS system as part of their mandate to participate in the effort.

Lame delegations occur when a DNS server has been identified to not only carry a delegated zone, but to also answer for it authoritatively, yet does neither. The reasons for why this may happen may be varied (though most likely due to a misconfiguration within the DNS server itself), but the point is that lame delegations, even in the reverse zones (such as arpa.) can and do create an impact ultimately to the end-user, along with DNS caches, applications, firewalls, etc.

In the case of AS112 nodes and the zones they hold authority for, if such a node were to be considered lame, then reverse queries to resolve addresses will result in delays created by timeouts. Additionally, these timeouts can be amplified as caching DNS servers no longer hold information about the addresses they may have once cached: They naturally begin seeking to resolve an address by interrogating other DNS servers, ultimately leading to the the root and creating a further load - which is precisely what the AS112 project seeks to prevent.

For the end-user residing on a network that uses addresses which are delegated to a lame AS112 node, the usual result manifests itself in the perception that either the local network is not functioning as usually expected or that the Internet is in some way down.

This in turn may lead to an apparent denial of access to services for the end-user. A domino effect can then be triggered from there, in which case the end-user may believe that a service is unavailable simply because a service administrator is unknowingly depending on a far-off AS112's node to be functioning properly. It would not be long before support personnel would become involved, further committing more resources at the perceived problem.

Finally, the impact to the AS112 Project itself should not be ignored. If too many AS112 nodes are discovered to be lame servers, then it would naturally be in the best interests of the Internet community to remove affected delegations of reverse zones assigned to it as a whole. This in turn lessens the effectiveness of the project and only serves to increase the traffic load to the root servers. On top that, the reputation of the AS112 Project's as providing a service for the common good of the community would be damaged because it would be deemed as unreliable.

4. IANA Considerations

As per the provisions of [RFC3596], this document recommends the IAB to direct IANA to delegate the following IN-ADDR.ARPA reverse DNS zones to the AS112 project [I-D.ietf-dnsop-as112-ops]:

              0.in-addr.arpa (IPv4 "This" Network)
            127.in-addr.arpa (IPv4 Loop-Back Network)
        2.0.192.in-addr.arpa (IPv4 Test Net 1)
     100.51.198.in-addr.arpa (IPv4 Test Net 2)
      113.0.203.in-addr.arpa (IPv4 Test Net 3)
255.255.255.255.in-addr.arpa (IPv4 Broadcast)

AS112 project servers should add these zones to their configuration, and terminate queries efficiently inside their service infrastructure.

This delegation instruction is subject to further direction in the future from the IAB to IANA, as per the provisions of [RFC3596].

5. Security Considerations

The Security Considerations described in [I-D.ietf-dnsop-as112-ops] also apply to local-use IPv4 addresses, and should be considered in the context of the use of these addresses.

Security administrators as well as general support personnel who are involved in the operations of networked devices may also find the information found in the companion document [I-D.ietf-dnsop-as112-under-attack-help-help] quite helpful.

DNS queries may well identify the location of deployment of IPv4 enabled equipment in private contexts, particularly when the reverse queries relate to local-use IPv4 addresses. While operators of the DNS reverse servers should respect the privacy of data relating to individual queries made to these reverse address servers, the unintentional leakage of information beyond its intended scope of use and circulation represents a potential threat to the security of a local private network. This direction to delegate these local-use IPv4 reverse address sub-domains does not substantially change the security risks of information leakage from private environments.

6. Acknowledgements

The author would like to acknowledge the efforts of Mark P. Andrews for preparing the work related to serving certain DNS zones locally and George Michaelson and Geoff Huston for their work [I-D.michaelson-as112-ipv6] in setting the example for a template to be used by the AS112 Project as a direction for the IANA.

The author would also like to thank Joe Abley, Marco d'Itri, Nick Hilliard and Paul Vixie for their feedback.

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Change History

This section to be removed prior to publication.

00

Initial draft, circulated as draft-sotomayor-as112-ipv4-cull-00.

Author's Address