One document matched: draft-morishita-dnsop-anycast-node-requirements-00.txt
IETF DNSOP Working Group Y. Morishita
Internet-Draft S. Sato
Expires: January 12, 2006 T. Matsuura
JPRS
July 11, 2005
BGP Anycast Node for Authotitative Name Server Requirements
draft-morishita-dnsop-anycast-node-requirements-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
IP anycasting [1] is a technology for sharing an IP address for
Internet services in multiple servers. It is now being deployed for
authoritative name servers, especially root name servers. RFC 3258
[2] describes a set of practices to provide for IP anycasting.
And operators of authoritative name servers can also refer to RFC
2182 [3] and 2870 [4] for general guidance on appropriate practice
Morishita, et al. Expires January 14, 2006 [Page 1]
Internet-Draft Anycast Node Requirements July 2005
for authoritative name servers.
This memo describes details of requirements and preconditions for
making authoritative name servers which are needed in real Internet,
to realize the practices in RFC 2182, 2870 and 3258.
1. Introduction
Applying IP anycasting to DNS, name server operators can increase and
distribute authoritative name servers topologically and
geographically, without violating the DNS protocol [5] [6]. This
improves the robustness against DoS attack and/or name server down.
And this improves the DNS total performance by decreasing RTT for
authoritative name server, and distributing authoritative name
servers' load.
But in IP anycasting environment, IP address does not specify the end
point in the Internet communication, then it means that IP address
does not specify the real communicating peer. That is, when
destination IP address is in under IP anycast mesh, client can not
control which anycast node process the sending datagrams.
Then, for example, if a part of IP anycast nodes are corrupted, it is
hard to determine which nodes are bad, especially the bad nodes which
answer the bad response. It is a risk of the deployment of IP
anycasting.
Of course, DNS is one of an important infrastructure of the Internet,
introducing IP anycasting MUST NOT decrease the total availability
and reliability of DNS.
This memo describes a set of requirements and preconditions for
making IP anycast nodes for authoritative name servers, which are
widely distributed. In this memo, authors focus on BGP anycast.
Because in general, it has more widely distributed locations than IGP
anycast. But the basic point of view can apply to IGP anycast, too.
2. BGP anycast and DNS service
BGP anycast is a part of IP anycasting technology. It uses a shared
IP address and a shared AS number for each BGP anycast nodes, and
their nodes are placed in the Internet. Reachability of each nodes
are served by BGP routing protocol [7].
Each anycast nodes propagate the routing information of shared IP
address and AS number by BGP. Each BGP routers in the Internet
choose 'nearest' node by BGP's best route selection algorithm. That
is, the access for the shared IP address is distributed to each
Morishita, et al. Expires January 14, 2006 [Page 2]
Internet-Draft Anycast Node Requirements July 2005
anycast nodes, it depends on each clients' location.
BGP anycast can control each anycast nodes are configured as 'local
node' or 'global node' by using BGP's routing framework. Concretely,
use of the 'no-export' BGP community [8], the 'local node' operators
can limit distributing the routing information of anycast node except
for directly peering nodes. By using this, the 'local node' can
localize the access for anycast node. On the other hand, the 'global
node' operators apply the normal BGP anycast for its node. In this
memo, authors focus on 'global node' as main target, but authors
believe it can be applied as 'local node' also.
When one of BGP anycast node is down, routing information is
automatically recalculated and the datagrams for anycast node are
automatically detoured to another anycast node. Then, BGP anycast
provides redundancy for Internet service.
And current BGP anycast is hard to apply for TCP-based service. But
almost of DNS service is based on a single UDP packet, then BGP
anycast is being deployed on authoritative name server.
As an important point, BGP anycast MUST need an exclusive IP address
which is a provider independent CIDR block and AS number for making
each anycast nodes.
3. Requirements and preconditions for making BGP anycast nodes
As described before, BGP anycast is one of effective way for making
distributed authoritative name server environment. In recent
authoritative name server, especially large TLD servers, they MUST
serve more data then other name servers, and they require more
frequent updating frequency of data and higher reliability. Then,
when BGP anycast is applied to their servers, the requirements and
preconditions which described by this memo would be more important.
In this section, this memo describes requirements and preconditions
for making BGP anycast node for authoritave name servers in the
following two point of views, the Internet access service, and data
center.
3.1 Choosing the Internet access service
When making BGP anycast nodes distributed in the wide area, it is
important for making network environment with geographical and
networking diversity.
In case of making such network environment, each anycasting nodes
SHOULD have Internet connectivity from different Internet access
Morishita, et al. Expires January 14, 2006 [Page 3]
Internet-Draft Anycast Node Requirements July 2005
service provider (hereafter, called ISP) for ensuring network
diversity.
And as described before, in case of ensuring BGP connectivity. That
is, when chooing the Internet access service, the owner of
authoritative name servers MUST consider the following preconditions
and requirements.
3.1.1 Reliability of the backbone network
When making an important authoritative name server, for example,
serving for root and/or TLD zone, high reliability for ISP's network
itself is needed. For implementing this, it is desirable for ISP
itself to have owned and managed its backbone network.
An ISP which owns and manages the backbone network itself, has
stronger responsibility for network stability then it doesn't. Then
it is expectable that the stability of a network is higher. Of
course, it is not absolute requirement, but it will surely be one of
the important elements.
3.1.2 Connectivity of outside area
In case of authoritative name service, especially root and/or TLD
zone, there are many accesses including outside of its country and
local area. Then, connectibity for them MUST be needed. That is, in
the same reason of Section 3.1.1, it is desirable that an ISP which
owns and manages the outside area connectivity.
3.1.3 Peering
When ensuring highly reliable Internet connectivity, it is an
important element to ensuring the diversity of Internet routes
including many alternative paths. Moreover, providing DNS service to
many ISP networks efficiently, it is desirable for ISP to have many
BGP peers with other ISPs.
3.1.4 Connectivity for provider independent CIDR block and AS number
When making BGP anycast node, a provider independent CIDR block and
an AS number MUST be prepare in advance, and they MUST be used for
DNS service at each anycast nodes. It is also needed for making the
multihomed connectivity.
In this case, ISP MUST support propagating CIDR block and AS number
for anycasting service to the Internet widely, and ISP MUST provide
connectivity for them from the Internet, concretely, ISP MUST provide
transit service.
Morishita, et al. Expires January 14, 2006 [Page 4]
Internet-Draft Anycast Node Requirements July 2005
3.1.5 Connectivity for administration
And as RFC 3258 described, it MUST be needed an Internet connectivity
for anycast node administration which is different for IP anycasting.
3.1.6 Connectivity for IPv6
There is no standard for IPv6 anycasting, but in near future, IP
anycasting for IPv6 would be needed. That is, the anycast node owner
SHOULD ensure IPv6 connectivity.
3.2 Choosing the location
For choosing BGP anycast node location, RFC 2182 and 2870 can be
refered for useful guidance on appropriate practice for authoritative
name servers. By referencing them, when choosing the location for
BGP anycast node, the owner of authoritative name servers MUST
consider the following preconditions and requirements.
3.2.1 Providing higher security level
To realize the high defense performance to physical destruction
and/or the intrusion from the outside, the location MUST provide
higher security level.
3.2.2 Providing higher redundancy of electrical power supply
DNS service requires high continuity and stability, the location MUST
provide higher redundancy of electrical power supply and urgent power
supply equipment for emergency.
3.2.3 Providing higher tolerance against disasters
For the same reason of Section 3.2.2, the location MUST provide
higher tolerance against disasters, for example fire, earthquake and
others.
3.2.4 Providing the diversity of locations
For ensuring torerance and redundancy, the diversity of locations is
needed. Concretely, if a fatal disaster occurred at one location,
the continuity of DNS service MUST be ensured.
4. Cost issue
In technical, BGP anycast nodes can be made in many locations. But
it is not realistic to prepare it over necessity. In general, for
satisfying the preconditions and requirements which is previously
Morishita, et al. Expires January 14, 2006 [Page 5]
Internet-Draft Anycast Node Requirements July 2005
described, BGP anycast node needs high cost, including financial and
human resources.
In the current condition, this cost is mandatory for making BGP
anycast node. Especially, the guaranteed the quality of service
level, for example SLA (Service Level Agreement), makes higher cost
than normal Internet connectivity. This is one of big burden for
operating BGP anycast node. This is one of in the future issue for
deploying IP anycasting.
Furthermore, for administrating remote anycast nodes smoothly, more
human recources are needed, including local and remote technical
staff. When making BGP anycast node, the owner of authoritative name
servers MUST consider about this issue.
5. Measurement issue
For verifying selection is appropriate or not, objective measurement
from another network place is very important. When making BGP
anycast mesh in the wide area, the measurement MUST also be carried
out by the wide area.
In such case, there is a effective guideline defined by ICANN, it is
called as "CNNP test" [9]. This helps for making BGP anycast node.
And as typical notable project, RIPE NCC's DNSMON service [10].
The continuity is an important point for measurement. And operators
SHOULD verify that the continuity of DNS service is ensured by
measurement.
6. Security Considerations
TBD
7. Acknowledgements
The authors gratefully acknowledge the many helpful suggestions of
the members of JPRS Research and Development Department and System
administration Department.
This memo is included the research activities funded by National
Institute of Information and Communications Technology (NICT).
8. References
[1] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
Morishita, et al. Expires January 14, 2006 [Page 6]
Internet-Draft Anycast Node Requirements July 2005
[2] Hardie, T., "Distributing Authoritative Name Servers via Shared
Unicast Addresses", RFC 3258, April 2002.
[3] Elz, R., Bradner, S., and M. Patton, "Selection and Operation
of Secondary DNS Servers", RFC 2182, July 1997.
[4] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name
Server Operational Requirements", RFC 2870, June 2000.
[5] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, November 1987.
[6] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, November 1987.
[7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[8] Chen, E. and J. Stewart, "A Framework for Inter-Domain Route
Aggregation", RFC 2519, February 1999.
[9] "Unsponsored TLD Agreement: Appendix D (.info)", May 2001.
[10] "RIPE-NCC/DNS Server Monitoring", <http://dnsmon.ripe.net/>.
Authors' Addresses
Yasuhiro Orange Morishita
Research and Development Department, Japan Registry Services Co.,Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Email: yasuhiro@jprs.co.jp
Shinta Sato
System Administration Department, Japan Registry Services Co.,Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Email: shinta@jprs.co.jp
Morishita, et al. Expires January 14, 2006 [Page 7]
Internet-Draft Anycast Node Requirements July 2005
Takayasu Matsuura
System Administration Department, Japan Registry Services Co.,Ltd.
Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
Chiyoda-ku, Tokyo 101-0065
Japan
Email: matuura@jprs.co.jp
Morishita, et al. Expires January 14, 2006 [Page 8]
Internet-Draft Anycast Node Requirements July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Morishita, et al. Expires January 14, 2006 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 01:56:39 |