One document matched: draft-ietf-dnsop-as112-ops-04.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-ietf-dnsop-as112-ops.xml"?>
<!-- automatically generated by xml2rfc v1.35 on 2010-07-29T12:51:37Z -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!--
--><!-- xml2rfc-processed-entity rfc1034 -->
<!--
--><!-- xml2rfc-processed-entity rfc1876 -->
<!--
--><!-- xml2rfc-processed-entity rfc1918 -->
<!--
--><!-- xml2rfc-processed-entity rfc3330 -->
<!--
--><!-- xml2rfc-processed-entity rfc4271 -->
<!--
--><!-- xml2rfc-processed-entity rfc2870 -->
<!--
--><!-- xml2rfc-processed-entity rfc4786 -->
<!--
--><!-- xml2rfc-processed-entity draft-ietf-dnsop-default-local-zones -->
<!-- xml2rfc-processed-entity draft-ietf-dnsop-as112-under-attack-help-help.front -->
<!-- xml2rfc-processed-entity draft-ietf-dnsop-as112-ops.front -->
]>
<rfc category="info" ipr="trust200902"
docName="draft-ietf-dnsop-as112-ops-04">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc linefile="1:draft-ietf-dnsop-as112-ops.front"?><front>
<title>AS112 Nameserver Operations</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>ICANN</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</email>
</address>
</author>
<author initials='W.' surname="Maton" fullname='William F. Maton Sotomayor'>
<organization abbrev="NRC-CNRC">National Research Council
of Canada</organization>
<address>
<postal>
<street>1200 Montreal Road</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1A 0R6</code>
<country>Canada</country>
</postal>
<phone>+1 613 993 0880</phone>
<email>wmaton@ryouko.imsb.nrc.ca</email>
</address>
</author>
<date month="July" year="2010"/>
<abstract>
<t>Many sites connected to the Internet make use of IPv4 addresses
which are not globally unique. Examples are the addresses
designated in RFC1918 for private use within individual
sites.</t>
<t>Devices in such environments may occasionally originate
reverse DNS queries corresponding to those private-use
addresses. Since the addresses concerned have only local
significance, it is good practice for site administrators to
ensure that they 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.</t>
<t>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
root and IN-ADDR.ARPA authority servers.</t>
<t>This document describes the steps required to install
a new AS112 node, and offers advice relating to such a node's
operation.</t>
</abstract>
</front>
<?rfc linefile="34:draft-ietf-dnsop-as112-ops.xml"?>
<middle>
<section title="Introduction">
<t>Many sites connected to the Internet make use of IPv4
addresses which are not globally unique. Examples are the
addresses designated in <xref target="RFC1918"/> for private
use within individual sites.</t>
<t>Devices in such environments may occasionally originate
<xref target="RFC1034">reverse DNS queries</xref> corresponding
to those private-use addresses. Since the addresses concerned
have only local significance, it is good practice for site
administrators to ensure that they are answered locally
<xref target="I-D.ietf-dnsop-default-local-zones"/>.
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.</t>
<t>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
root and IN-ADDR.ARPA authority servers.</t>
<t>The AS112 project encompasses a loosely-coordinated
collection of independently-operated nameservers. Each
nameserver functions as a single node in an AS112 <xref
target="RFC4786">anycast cloud</xref>, and
is configured to answer authoritatively for a particular
set of nominated zones.</t>
</section>
<section title="AS112 DNS Service">
<section title="Zones" anchor="zones">
<t>AS112 nameservers answer authoritatively for the following
zones, corresponding to <xref target="RFC1918"/> private-use
netblocks:
<list style="symbols">
<t>10.IN-ADDR.ARPA</t>
<t>16.172.IN-ADDR.ARPA, 17.172.IN-ADDR.ARPA, ...,
31.172.IN-ADDR.ARPA</t>
<t>168.192.IN-ADDR.ARPA</t>
</list>
and the following zone, corresponding to the "link local"
netblock 169.254.0.0/16 listed in <xref target="RFC3330"/>:
<list style="symbols">
<t>254.169.IN-ADDR.ARPA</t>
</list>
</t>
<t>To aid identification of AS112 anycast nodes, each
node also answers authoritatively for the zone
HOSTNAME.AS112.NET. See <xref target="dns"/> for the
recomended contents of that zone.</t>
<t>It is possible that other zones corresponding to private-use
infrastructure will be delegated to AS112 servers in the
future. A list of zones for which AS112 servers answer
authoritatively is maintained at <eref
target="http://www.as112.net/"/>.</t>
</section>
<section title="Nameservers" anchor="nameservers">
<t>The zones listed in <xref target="zones"/> are delegated to
the two nameservers BLACKHOLE-1.IANA.ORG (192.175.48.6)
and BLACKHOLE-2.IANA.ORG (192.175.48.42).</t>
<t>Additionally, the server PRISONER.IANA.ORG (192.175.48.1)
is listed in MNAME field of the SOA records of zones
served by AS112 nameservers, and receives mainly dynamic
update queries.</t>
<t>The addresses of all these nameservers are covered by
the single IPv4 prefix 192.175.48.0/24.</t>
</section>
</section>
<section title="Installation of a New Node">
<section title="Useful Background Knowledge">
<t>Installation of an AS112 node is relatively straightforward.
However, experience in the following general areas may
prove useful:
<list style="symbols">
<t>Inter-domain routing with <xref
target="RFC4271">BGP</xref>;</t>
<t>DNS authority server operations;</t>
<t>Anycast distribution of DNS services
(<xref target="ISC-TN-2003-1"/>,
<xref target="RFC4786"/>).</t>
</list>
</t>
</section>
<section title="Topological Location">
<t>AS112 nodes may be located anywhere on the Internet. For
nodes which are intended to provide a public service to
the Internet community (as opposed to private use), it
may well be advantageous to choose a location that is
easily (and cheaply) reachable by multiple providers,
such as an Internet exchange point.</t>
<t>AS112 nodes may advertise their service prefix to BGP
peers for local use (analogous to a conventional peering
relationship between two providers) or for global use
(analogous to a customer relationship with one or more
providers).</t>
<t>It is good operational practice to notify the community
of users which may fall within the reach of a new AS112 node
before it is installed. At an Internet Exchange, local
mailing lists usually exist to facilitate such announcements.
For nodes which are intended to be globally reachable,
coordination with other AS112 operators is highly recommended.
See also <xref target="communications"/>.</t>
</section>
<section title="Operating System and Host Considerations">
<t>The use of a UNIX or UNIX-like operating system (e.g.
FreeBSD, Linux) is recommended for the construction of
AS112 nodes, primarily due to the cumulative experience of
using such platforms for this purpose. Examples in this
document will assume use of such an operating system.</t>
<t>The chosen platform should include support for either
cloned loopback interfaces, or the capability to bind
multiple addresses to a single loopback interface. The
addresses of the nameservers listed in <xref
target="nameservers"/> will be configured on these
interfaces in order that the DNS software can respond to
queries properly.</t>
<t>A host which is configured to act as an AS112 anycast
node should be dedicated to that purpose, and should not be
used to simultaneously provide other services.</t>
<t>System startup scripts should be arranged such that the
various AS112-related components start automatically following
a system reboot. The order in which interfaces are configured
and software components started should be arranged such that
routing software startup follows DNS software startup, and
DNS software startup follows loopback interface configuration.</t>
<t>Wrapper scripts or other arrangements should be employed to
ensure that the anycast service prefix for AS112 is not advertised
while either the anycast addresses are unconfigured, or while
the DNS software is not running.</t>
</section>
<section title="Routing Software">
<t>AS112 nodes signal the availability of AS112 nameservers to
the Internet using <xref target="RFC4271">BGP</xref>: each
AS112 node is a BGP speaker, and announces the prefix
192.175.48.0/24 to the Internet with origin AS 112
(see also <xref target="nameservers"/>).</t>
<t>Suitable choices of free software to allow hosts to
act as BGP speakers include, but are not limited to:
<list style="symbols">
<t><eref target="http://bird.network.cz/">BIRD Internet
Routing Daemon</eref></t>
<t><eref target="http://www.openbgpd.org/">OpenBGPD</eref></t>
<t><eref target="http://www.quagga.net/">The Quagga
Routing Suite</eref></t>
<t><eref target="http://www.zebra.org/">GNU Zebra</eref></t>
</list>
</t>
<t>The examples in this document are based on Quagga.</t>
<t>The "bgpd.conf" file is used by Quagga's bgpd daemon, which
provides BGP protocol support. The router id in this case
is 198.32.149.123; the AS112 node peers with external
peers 198.32.149.1 and 198.32.149.2, which are route
servers at an exchange point. Note the local AS number
112, and the origination of the prefix 192.175.48.0/24.</t>
<figure>
<artwork>
! bgpd.conf
!
hostname as112-bgpd
password <something>
enable password <supersomething>
!
router bgp 112
bgp router-id 198.32.149.123
network 192.175.48.0
neighbor 198.32.149.1 remote-as 2884
neighbor 198.32.149.1 next-hop-self
neighbor 198.32.149.2 remote-as 2884
neighbor 198.32.149.2 next-hop-self
</artwork>
</figure>
<t>The "zebra.conf" file is required to provide integration
between protocol daemons (bgpd, in this case) and the
kernel.</t>
<figure>
<artwork>
! zebra.conf
!
hostname as112
password <something>
enable password <supersomething>
!
interface lo
!
interface eth0
!
</artwork>
</figure>
</section>
<section title="DNS Software" anchor="dns">
<t>Although the queries received by AS112 nodes are
definitively misdirected, it is important that they be
answered in a manner which is accurate and consistent.
For this reason AS112 nodes operate as <xref
target="RFC1034">fully-functional
and standards-compliant DNS authority servers</xref>,
and hence require DNS software.</t>
<t>Suitable choices of free DNS software for AS112 nodes
include, but are not limited to:
<list style="symbols">
<t><eref target="http://www.isc.org/software/BIND/">ISC
BIND9</eref></t>
<t><eref target="http://www.nlnetlabs.nl/nsd/">NLnet Labs'
NSD</eref></t>
</list>
</t>
<t>Examples in this document are based on ISC BIND9.</t>
<t>The following is a sample BIND9 "named.conf" file for a
dedicated AS112 server. Note that the nameserver is
configured to act as an authority-only server (i.e.
recursion is disabled). The nameserver is also configured
to listen on the various AS112 anycast nameserver addresses,
as well as its local addresses.</t>
<figure>
<artwork>
// named.conf
// global options
options {
listen-on {
127.0.0.1; // localhost
198.32.149.252; // local address (globally-unique, unicast)
192.175.48.1; // prisoner.iana.org (anycast)
192.175.48.6; // blackhole-1.iana.org (anycast)
192.175.48.42; // blackhole-2.iana.org (anycast)
};
directory "/var/named";
recursion no; // authority-only server
query-source address *;
};
// log queries, so that when people call us about unexpected
// answers to queries they didn't realise they had sent, we
// have something to talk about. Note that activating this
// has the potential to create high CPU and take enormous
// amounts of disk space.
logging {
channel "querylog" {
file "/var/log/query.log" versions 2 size 500m;
print-time yes;
};
category queries { querylog; };
};
// RFC 1918
zone "10.in-addr.arpa" { type master; file "db.empty"; };
zone "16.172.in-addr.arpa" { type master; file "db.empty"; };
zone "17.172.in-addr.arpa" { type master; file "db.empty"; };
zone "18.172.in-addr.arpa" { type master; file "db.empty"; };
zone "19.172.in-addr.arpa" { type master; file "db.empty"; };
zone "20.172.in-addr.arpa" { type master; file "db.empty"; };
zone "21.172.in-addr.arpa" { type master; file "db.empty"; };
zone "22.172.in-addr.arpa" { type master; file "db.empty"; };
zone "23.172.in-addr.arpa" { type master; file "db.empty"; };
zone "24.172.in-addr.arpa" { type master; file "db.empty"; };
zone "25.172.in-addr.arpa" { type master; file "db.empty"; };
zone "26.172.in-addr.arpa" { type master; file "db.empty"; };
zone "27.172.in-addr.arpa" { type master; file "db.empty"; };
zone "28.172.in-addr.arpa" { type master; file "db.empty"; };
zone "29.172.in-addr.arpa" { type master; file "db.empty"; };
zone "30.172.in-addr.arpa" { type master; file "db.empty"; };
zone "31.172.in-addr.arpa" { type master; file "db.empty"; };
zone "254.169.in-addr.arpa" { type master; file "db.empty"; };
zone "168.192.in-addr.arpa" { type master; file "db.empty"; };
// also answer authoritatively for the HOSTNAME.AS112.NET zone,
// which contains data of operational relevance
zone "hostname.as112.net" { type master;
file "db.hostname.as112.net"; };
</artwork>
</figure>
<t>The "db.empty" file follows, below. This is the source
data used to populate all the zones listed in <xref
target="zones"/>.</t>
<figure>
<artwork>
; db.empty
;
; Empty zone for AS112 server.
;
$TTL 1W
@ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-1.iana.org.
NS blackhole-2.iana.org.
;
; There should be no other resource records included in this zone.
;
; Records which relate to RFC1918-numbered resources within the
; site hosting this AS112 node should not be hosted on this
; nameserver.
</artwork>
</figure>
<t>The "db.hostname.as112.net" file follows, below.
This zone contains various resource records which provide
operational data to users for troubleshooting or measurement
purposes, and should be edited to suit local circumstances.
Note that the response to the query "HOSTNAME.AS112.NET
IN TXT" should fit within a 512 octet DNS/UDP datagram:
i.e. it should be available over UDP transport without
requiring EDNS0 support.</t>
<t>The <xref target="RFC1876">LOC record</xref> included
in the zone apex provides information about the geospacial
location of the node.</t>
<figure>
<artwork>
; db.hostname.as112.net
;
$TTL 1W
@ SOA flo.gigafed.net. dns.ryouko.imsb.nrc.ca. (
1 ; serial number
1W ; refresh
1M ; retry
1W ; expire
1W ) ; negative caching TTL
;
NS blackhole-2.iana.org.
NS blackhole-1.iana.org.
;
TXT "Federal GigaPOP" "Ottawa, Canada"
TXT "See http://www.as112.net/ for more information."
;
LOC 45 25 0.000 N 75 42 0.000 W 80.00m 1m 10000m 10m
</artwork>
</figure>
</section>
<section title="Testing a Newly-Installed Node">
<t>The BIND9 tool "dig" can be used to retrieve the TXT
resource records associated with the domain "HOSTNAME.AS112.NET",
directed at one of the AS112 anycast nameserver addresses.
Continuing the example from above, the response received should
indicate the identity of the AS112 node which responded to the
query. See <xref target="dns"/> for more details about the
resource records associated with "HOSTNAME.AS112.NET".</t>
<figure>
<artwork>
% dig @prisoner.iana.org hostname.as112.net txt +short +norec
"Federal GigaPOP" "Ottawa, Canada"
"See http://www.as112.net/ for more information."
%
</artwork>
</figure>
<t>If the response received indicates a different node is being
used, then there is probably a routing problem to solve. If
there is no response received at all, there might be host
or nameserver problem. Judicious use of tools such as
traceroute, and consultation of BGP looking glasses might
be useful in troubleshooting.</t>
<t>Note that an appropriate set of tests for a new server will
include queries sent from many different places within the
expected service area of the node, using both UDP and TCP
transport, and exercising all three AS112 anycast nameserver
addresses.</t>
</section>
</section>
<section title="Operations">
<section title="Monitoring">
<t>AS112 nodes should be monitored to ensure they are functioning
correctly, just as with any other production service. An AS112
node which stops answering queries correctly can cause failures
and timeouts in unexpected places, and can lead to failures in
dependent systems which can be difficult to troubleshoot.</t>
</section>
<section title="Downtime">
<t>An AS112 node which needs to go off-line (e.g. for planned
maintenance, or as part of the diagnosis of some problem)
should stop advertising the AS112 service prefix to its BGP
peers. This can be done by shutting down the routing software
on the node altogether, or by causing the routing system to
withdraw the route.</t>
<t>Withdrawing the service prefix is important in order to avoid
blackholing query traffic in the event that the DNS software on
the node is not functioning normally.</t>
</section>
<section title="Statistics and Measurement">
<t>Use of the AS112 node should be measured in order to track
long-term trends, identify anomalous conditions and to ensure
that the configuration of the AS112 node is sufficient to handle
the query load.</t>
<t>Examples of free monitoring tools which might be useful to
operators of AS112 nodes include, but are not limited to:
<list style="symbols">
<t><eref target="http://www.linux.it/~md/software/">bindgraph</eref></t>
<t><eref target="http://dns.measurement-factory.com/tools/dnstop/">dnstop</eref></t>
<t><eref target="http://dns.measurement-factory.com/tools/dsc/">DSC</eref></t>
</list>
</t>
</section>
</section>
<section title="Communications" anchor="communications">
<t>It is good operational practice to notify the community
of users which may fall within the reach of a new AS112 node
before it is installed. At Internet Exchanges, local
mailing lists usually exist to facilitate such announcements.</t>
<t>For nodes which are intended to be globally reachable,
coordination with other AS112 operators is especially
recommended. The mailing list <eref
target="mailto:as112-ops@lists.dns-oarc.net"/> is operated
for this purpose.</t>
<t>Information pertinent to AS112 operations is maintained
at <eref target="http://www.as112.net/"/>.</t>
<t>Information about an AS112 node should also be published within
the DNS, within the "HOSTNAME.AS112.NET" zone. See
<xref target="dns"/> for more details.</t>
</section>
<section title="On the Future of AS112 Nodes">
<t>It is recommended practice for the operators of recursive
nameservers to answer queries for zones served by AS112
nodes locally, such that queries never have an opportunity
to reach AS112 servers <xref
target="I-D.ietf-dnsop-default-local-zones"/>. Operational
experience with AS112 nodes does not currently indicate an
observable trend towards compliance with those recommendations,
however.</t>
<t>It is expected that some DNS software vendors will include
default configuration which will implement measures such
as those described in <xref
target="I-D.ietf-dnsop-default-local-zones"/>. If such
software is widely deployed, it is reasonable to assume
that the query load received by AS112 nodes will decrease;
however, it is safe to assume that the query load will not
decrease to zero, and consequently that AS112 nodes will
continue to provide a useful service for the foreseeable
future.</t>
<t>There may be a requirement in the future for AS112 nodes to
answer for their current set of zones over IPv6 transport.
Such a requirement would necessitate the assignment of a
corresponding IPv6 netblock for use as an anycast service
prefix.</t>
<t>There may be a requirement in the future for AS112 nodes
to serve additional zones, or to stop serving particular
zones that are currently served. Such changes would be
widely announced in operational forums, and published
at <eref target="http://www.as112.net/"/>.</t>
</section>
<section title="IANA Considerations">
<t>The AS112 nameservers are all named under the domain
IANA.ORG (see <xref target="nameservers"/>). The IANA is
the organisation responsible for the coordination of many
technical aspects of the Internet's basic infrastructure.
The AS112 project nameservers provide a public service to
the Internet which is sanctioned by and operated in
loose coordination with the IANA.</t>
<t>This document makes no request of the IANA.</t>
</section>
<section title="Security Considerations">
<t>Hosts should never normally send queries to AS112 servers;
queries relating to private-use addresses should be answered
locally within a site. Hosts which send queries to AS112
servers may well leak information relating to private
infrastructure to the public network, which could represent
a security risk. This risk is orthogonal to the presence or
absence of authority servers for these zones in the public
DNS infrastructure, however.</t>
<t>Queries which are answered by AS112 servers are usually
unintentional; it follows that the responses from AS112
servers are usually unexpected. Unexpected inbound traffic
can trigger intrusion detection systems or alerts by
firewalls. Operators of AS112 servers should be prepared
to be contacted by operators of remote infrastructure who
believe their security has been violated. Advice to those
who mistakenly believe that responses from AS112 nodes
constitutes an attack on their infrastructure can be found
in <xref
target="draft-ietf-dnsop-as112-under-attack-help-help"/>.</t>
<t>The deployment of AS112 nodes are very loosely coordinated
compared to other services distributed using anycast. The
malicious compromise of an AS112 node and subversion of the
data served by the node is hence more difficult to detect
due to the lack of central management. Since it is conceivable
that changing the responses to queries received by AS112
nodes might influence the behaviour of the hosts sending
the queries, such a compromise might be used as an attack
vector against private infrastructure.</t>
<t>Operators of AS112 should take appropriate measures to
ensure that AS112 nodes are appropriately protected from
compromise, such as would normally be employed for production
nameserver or network infrastructure. The guidance provided
for root nameservers in <xref target="RFC2870"/> may be
instructive.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"?>
<reference anchor='RFC1034'>
<front>
<title abbrev='Domain Concepts and Facilities'>Domain names - concepts and facilities</title>
<author initials='P.' surname='Mockapetris' fullname='P. Mockapetris'>
<organization>Information Sciences Institute (ISI)</organization></author>
<date year='1987' day='1' month='November' /></front>
<seriesInfo name='STD' value='13' />
<seriesInfo name='RFC' value='1034' />
<format type='TXT' octets='129180' target='http://www.rfc-editor.org/rfc/rfc1034.txt' />
</reference>
<?rfc linefile="597:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml"?>
<reference anchor='RFC1918'>
<front>
<title>Address Allocation for Private Internets</title>
<author initials='Y.' surname='Rekhter' fullname='Yakov Rekhter'>
<organization>Cisco systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country></postal>
<phone>+1 914 528 0090</phone>
<facsimile>+1 408 526 4952</facsimile>
<email>yakov@cisco.com</email></address></author>
<author initials='R.' surname='Moskowitz' fullname='Robert G. Moskowitz'>
<organization>Chrysler Corporation</organization>
<address>
<postal>
<street>25999 Lawrence Ave</street>
<city>Center Line</city>
<region>MI</region>
<code>48015</code>
<country>US</country></postal>
<phone>+1 810 758 8212</phone>
<facsimile>+1 810 758 8173</facsimile>
<email>rgm3@is.chrysler.com</email></address></author>
<author initials='D.' surname='Karrenberg' fullname='Daniel Karrenberg'>
<organization>RIPE Network Coordination Centre</organization>
<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country></postal>
<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>Daniel.Karrenberg@ripe.net</email></address></author>
<author initials='G.' surname='Groot' fullname='Geert Jan de Groot'>
<organization>RIPE Network Coordination Centre</organization>
<address>
<postal>
<street>Kruislaan 409</street>
<city>Amsterdam</city>
<region />
<code>1098 SJ</code>
<country>NL</country></postal>
<phone>+31 20 5925065</phone>
<facsimile>+31 20 5925090</facsimile>
<email>GeertJan.deGroot@ripe.net</email></address></author>
<author initials='E.' surname='Lear' fullname='Eliot Lear'>
<organization>Silicon Graphics, Inc.</organization>
<address>
<postal>
<street>2011 N. Shoreline Blvd.</street>
<street>Mail Stop 15-730</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043-1389</code>
<country>US</country></postal>
<phone>+1 415 960 1980</phone>
<facsimile>+1 415 961 9584</facsimile>
<email>lear@sgi.com</email></address></author>
<date year='1996' month='February' /></front>
<seriesInfo name='BCP' value='5' />
<seriesInfo name='RFC' value='1918' />
<format type='TXT' octets='22270' target='http://www.rfc-editor.org/rfc/rfc1918.txt' />
</reference>
<?rfc linefile="598:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2870.xml"?>
<reference anchor='RFC2870'>
<front>
<title>Root Name Server Operational Requirements</title>
<author initials='R.' surname='Bush' fullname='R. Bush'>
<organization /></author>
<author initials='D.' surname='Karrenberg' fullname='D. Karrenberg'>
<organization /></author>
<author initials='M.' surname='Kosters' fullname='M. Kosters'>
<organization /></author>
<author initials='R.' surname='Plzak' fullname='R. Plzak'>
<organization /></author>
<date year='2000' month='June' />
<abstract>
<t>The primary focus of this document is to provide guidelines for operation of the root name servers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='40' />
<seriesInfo name='RFC' value='2870' />
<format type='TXT' octets='21133' target='http://www.rfc-editor.org/rfc/rfc2870.txt' />
</reference>
<?rfc linefile="599:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml"?>
<reference anchor='RFC4271'>
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'>
<organization /></author>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='S.' surname='Hares' fullname='S. Hares'>
<organization /></author>
<date year='2006' month='January' />
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t><t> The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t><t> BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t><t> This document obsoletes RFC 1771. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4271' />
<format type='TXT' octets='222702' target='http://www.rfc-editor.org/rfc/rfc4271.txt' />
</reference>
<?rfc linefile="600:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.4786.xml"?>
<reference anchor='RFC4786'>
<front>
<title>Operation of Anycast Services</title>
<author initials='J.' surname='Abley' fullname='J. Abley'>
<organization /></author>
<author initials='K.' surname='Lindqvist' fullname='K. Lindqvist'>
<organization /></author>
<date year='2006' month='December' />
<abstract>
<t>As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely.</t><t> Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='126' />
<seriesInfo name='RFC' value='4786' />
<format type='TXT' octets='56818' target='http://www.rfc-editor.org/rfc/rfc4786.txt' />
</reference>
<?rfc linefile="601:draft-ietf-dnsop-as112-ops.xml"?>
</references>
<references title="Informative References">
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.1876.xml"?>
<reference anchor='RFC1876'>
<front>
<title abbrev='Location Information in the DNS'>A Means for Expressing Location Information in the Domain Name System</title>
<author initials='C.' surname='Davis' fullname='Christopher Davis'>
<organization>Kapor Enterprises, Inc.</organization>
<address>
<postal>
<street>238 Main Street</street>
<street>Suite 400</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country></postal>
<phone>+1 617 576 4532</phone>
<email>ckd@kei.com</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Vixie Enterprises</organization>
<address>
<postal>
<street>Star Route Box 159A</street>
<city>Woodside</city>
<region>CA</region>
<code>94062</code>
<country>US</country></postal>
<phone>+1 415 747 0204</phone>
<email>paul@vix.com</email></address></author>
<author initials='T.' surname='Goodwin' fullname='Tim Goodwin'>
<organization>Public IP Exchange Ltd (PIPEX)</organization>
<address>
<postal>
<street>216 The Science Park</street>
<city>Cambridge</city>
<region>England</region>
<code>CB4 4WA</code>
<country>UK</country></postal>
<phone>+44 1223 250250</phone>
<email>tim@pipex.net</email></address></author>
<author initials='I.' surname='Dickinson' fullname='Ian Dickinson'>
<organization>FORE Systems</organization>
<address>
<postal>
<street>2475 The Crescent</street>
<street>Solihull Parkway</street>
<city>Birmingham Business Park</city>
<region>England</region>
<code>B37 7YE</code>
<country>UK</country></postal>
<phone>+44 121 7174444</phone>
<email>idickins@fore.co.uk</email></address></author>
<date year='1996' month='January' />
<abstract>
<t>This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. Such information for a small subset of hosts is currently contained in the flat-file UUCP maps. However, just as the DNS replaced the use of HOSTS.TXT to carry host and network address information, it is possible to replace the UUCP maps as carriers of location information.</t>
<t>This RFC defines the format of a new Resource Record (RR) for the Domain Name System (DNS), and reserves a corresponding DNS type mnemonic (LOC) and numerical code (29).</t>
<t>This RFC assumes that the reader is familiar with the DNS,. The data shown in our examples is for pedagogical use and does not necessarily reflect the real Internet.</t></abstract></front>
<seriesInfo name='RFC' value='1876' />
<format type='TXT' octets='29631' target='http://www.rfc-editor.org/rfc/rfc1876.txt' />
</reference>
<?rfc linefile="605:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.3330.xml"?>
<reference anchor='RFC3330'>
<front>
<title>Special-Use IPv4 Addresses</title>
<author>
<organization>IANA</organization></author>
<date year='2002' month='September' /></front>
<seriesInfo name='RFC' value='3330' />
<format type='TXT' octets='16200' target='http://www.rfc-editor.org/rfc/rfc3330.txt' />
</reference>
<?rfc linefile="606:draft-ietf-dnsop-as112-ops.xml"?>
<?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-default-local-zones"?>
<reference anchor='I-D.ietf-dnsop-default-local-zones'>
<front>
<title>Locally-served DNS Zones</title>
<author initials='M' surname='Andrews' fullname='Mark Andrews'>
<organization />
</author>
<date month='April' day='30' year='2010' />
<abstract><t>Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-default-local-zones-13' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-13.txt' />
</reference>
<?rfc linefile="607:draft-ietf-dnsop-as112-ops.xml"?>
<reference anchor='ISC-TN-2003-1' target="http://www.isc.org/pubs/tn/isc-tn-2003-1.html">
<front>
<title>Hierarchical Anycast for Global Service Distribution</title>
<author initials='J.' surname='Abley' fullname='Joe Abley'>
<organization abbrev="ISC">Internet Systems Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country>
</postal>
<phone>+1 650 423 1317</phone>
<email>jabley@isc.org</email></address>
</author>
</front>
</reference>
<reference anchor="draft-ietf-dnsop-as112-under-attack-help-help">
<?rfc linefile="1:draft-ietf-dnsop-as112-under-attack-help-help.front"?><front>
<title>I'm Being Attacked by PRISONER.IANA.ORG!</title>
<author initials='J.' surname="Abley" fullname='Joe Abley'>
<organization>ICANN</organization>
<address>
<postal>
<street>4676 Admiralty Way, Suite 330</street>
<city>Marina del Rey</city>
<region>CA</region>
<code>90292</code>
<country>US</country>
</postal>
<phone>+1 519 670 9327</phone>
<email>joe.abley@icann.org</email>
</address>
</author>
<author initials='W.' surname="Maton" fullname='William F. Maton Sotomayor'>
<organization abbrev="NRC-CNRC">National Research Council
of Canada</organization>
<address>
<postal>
<street>1200 Montreal Road</street>
<city>Ottawa</city>
<region>ON</region>
<code>K1A 0R6</code>
<country>Canada</country>
</postal>
<phone>+1 613 993 0880</phone>
<email>wmaton@ryouko.imsb.nrc.ca</email>
</address>
</author>
<date month="July" year="2010"/>
<abstract>
<t>Many sites connected to the Internet make use of IPv4 addresses
which are not globally unique. Examples are the addresses
designated in RFC1918 for private use within individual
sites.</t>
<t>Hosts should never normally send DNS reverse mapping queries
for those addresses on the public Internet. However, such
queries are frequently observed. Authoritative servers are
deployed to provide authoritative answers to such queries as
part of a loosely-coordinated effort known as the AS112
project.</t>
<t>Since queries sent to AS112 servers are usually not intentional,
the replies received back from those servers are typically
unexpected. Unexpected inbound traffic can trigger alarms on
intrusion detection systems and firewalls, and operators of
such systems often mistakenly believe that they are being
attacked.</t>
<t>This document provides background information and technical
advice to those firewall operators.</t>
</abstract>
</front>
<?rfc linefile="629:draft-ietf-dnsop-as112-ops.xml"?>
</reference>
</references>
<section title="History">
<t>Widespread use of the private address blocks listed in
<xref target="RFC1918"/> followed that document's publication
in 1996.</t>
<t>The idea of off-loading IN-ADDR.ARPA queries relating to
<xref target="RFC1918"/> addresses from the root nameservers
was first proposed by Bill Manning and John Brown.</t>
<t>The use of anycast for distributing authority service for
<xref target="RFC1918"/> IN-ADDR.ARPA zones was subsequently
proposed at a private meeting of root server operators.</t>
<t>ARIN provided an IPv4 prefix for the anycast service,
and also the autonomous system number 112 for use in
originating that prefix. This assignment gave the project
its name.</t>
<t>In 2002, the first AS112 anycast nodes were deployed.</t>
<t>The use of anycast nameservers in the AS112 project contributed
to the operational experience of anycast DNS services, and can be
seen as a precursor to the anycast distribution of other authority
servers in subsequent years (e.g. various root servers).</t>
</section>
<section title="Acknowledgements">
<t>The authors wish to acknowledge the assistance of Bill
Manning, John Brown, Marco D'Itri, Daniele Arena, Stephane
Bortzmeyer, Frank Habicht, Chris Thompson and Peter Losher in the
preparation of this document.</t>
</section>
<section title="Change History">
<t>This section to be removed prior to publication.</t>
<t>
<list style="hanging">
<t hangText="00">Initial draft, circulated as
draft-jabley-as112-ops-00 and reviewed at the
DNSOP working group meeting at IETF 66.</t>
<t hangText="00">Document adoped by the DNSOP working
group and renamed accordingly.</t>
<t hangText="01">Input from reviewers of DNSOP and
others, some cosmetic tweaks.</t>
<t hangText="02">Version bump as request by DNSOP chairs.
Added missing IANA Considerations section. Updated
author's addresses. Make http://www.as112.net/ URL
consistent.</t>
<t hangText="03">Fix BLACKHOLE-2.IANA.ORG IP address.</t>
<t hangText="04">Bump version number. Refresh references.
Add reference to BIRD. Minor wordsmithing.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:13:08 |