IETF DNSOP Working Group S. Lee
Internet-Draft C. Park
Intended status: Informational W. Kim
Expires: June 7, 2007 NIDA
December 4, 2006
A Model of IPv4/IPv6 Dual Stack Anycast DNS Service
draft-lee-anycastdns-service-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 June 7, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This memo shows an example of how to provide and implement IPv4/IPv6
dual stack anycast DNS services, which are based on the experience of
IPv4/IPv6 anycast DNS implementation. In order to provide a
reference model to DNS operators who have a plan to deploy IPv4/IPv6
anycast DNS services onto their own DNS servers in the future, this
memo mainly specifies a way to configure IPv6-related functions
without IPv4-related matters.
Lee, et al. Expires June 7, 2007 [Page 1]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Anycast DNS . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. IPv6 Anycast Address Issue . . . . . . . . . . . . . . . . 4
2.2. IPv6 Anycast Prefix Assignment . . . . . . . . . . . . . . 4
3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Internal Routing . . . . . . . . . . . . . . . . . . . . . 6
3.2. External Routing . . . . . . . . . . . . . . . . . . . . . 6
4. Managements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. BGP Routing Management . . . . . . . . . . . . . . . . . . 7
4.2. Remote System Management . . . . . . . . . . . . . . . . . 7
4.3. DNS Zone-transfer Management . . . . . . . . . . . . . . . 7
4.4. DNS Daemon Management . . . . . . . . . . . . . . . . . . 7
5. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Lee, et al. Expires June 7, 2007 [Page 2]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
1. Introduction
DNS service is one of the most important Internet infrastructure, and
anycast [1] based DNS service [2] has been discussed within DNS
operation relevant areas for providing stable DNS services to the
users.
In general, anycast-base DNS service has various advantages, such as
effective dealing with DDoS attack, overcoming a limitation of
authoritative name server's physical numbers and improvement of
service stability and performance through a distribution of DNS
traffic; all of these are described at more length in other anycast-
related documents.
Because of these merits, the several DNS nodes(e.g., Root DNS, TLD
DNS and sub-level authoritative DNS) have been expanded with using
ancyast-based DNS architecture, and also, kr DNS has been deploying
and providing a IPv4 anycast DNS commercial services since July 2005.
In case of IPv6 anycast, due to outstanding two regulations [3], it
was substantially impossible to deploy at the real IPv6 Internet
environment. However, as the related rules were removed, as
described in [4], IPv6 anycast-based DNS service could be applicable
to name servers on real IPv6 Internet. NIDA(National Internet
Development Agency of Korea) has implemented IPv4/IPv6 anycast-based
kr DNS service on this above background since July 2006.
The implementation of IPv4/IPv6 anycast DNS service has capability of
redundant service architecture, traffic load-balancing among DNS
servers. Futhermore, it supports overall DNS service improvement,
such as robustness, redundancy and resiliency of DNS Services.
2. IPv6 Anycast DNS
IPv6 anycast-based DNS, which would be selected as an authoritative
name server located in the nearest path on the routing environment,
can be divided into two parts, one is BGP routing-based anycast
service and the other is IGP routing-based anycast service. This
memo specifies the implementation of IPv6 anycast DNS service which
uses a BGP-based routing.
This section describes an IPv6 anycast address issue and IPv6 anycast
prefix assignment for IPv6 anycast DNS service.
Lee, et al. Expires June 7, 2007 [Page 3]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
2.1. IPv6 Anycast Address Issue
In order to deploy an IPv6 anycast address to the name server served
in the IPv6 environment, there were two restrictions as follows [3].
o An anycast address must not be used as the source address of an
IPv6 packet.
o An anycast address must not be assigned to an IPv6 host, that is,
it may be assigned to an IPv6 router only.
Because of these restrictions, it was impossible to apply an IPv6
anycast to DNS service in the IPv6 Internet environment until now.
However, the above restrictions were removed by RFC4291[4].
Therefore, an anycast address can be used as the source address of an
IPv6 packet and an anycast address can be assigned to an IPv6 host,
that is, it may be assigned to an IPv6 router also.
This means that it is possible to apply an IPv6 anycast-based DNS
service to name server, and NIDA has been providing IPv4/IPv6 anycast
DNS service following the new specification.
2.2. IPv6 Anycast Prefix Assignment
IPv6 anycast address just uses a global IPv6 unicast address, that
is, it is taken from the unicast address spaces (of any scope) and is
not syntactically distinguishable from unicast address (RFC4291[4]),
for service of TLD anycast DNS server. IPv6 anycast node should
advertise an address block(prefix) which has no problem with global
routing. IPv6 anycast prefix assigned to TLD DNS is decided by RIR's
address allocation policy. In general, a determination of BGP
filtering block size is also based on this policy. In case of kr
DNS, it was assigned /32 IPv6 address block by APNIC's IPv6 address
allocation policy [5]. Other RIRs(e.g., RIPE-NCC and ARIN) have /48
allocation policy for that.
About this IPv6 address block(prefix) assignment(or allocation)
policy issue, it is necessary to discuss among RIRs or in IETF in the
future.
3. Topology
The architecture was considered to have stability and scalability for
providing IPv4/IPv6 anycast DNS service. This will be divided into
two parts.
Lee, et al. Expires June 7, 2007 [Page 4]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
First, an active/standby system was implemented by using IGP protocol
internally.
Second, a BGP routing based anycast system was implemented by BGP
protocol externally.
Figure 1 shows an configuration of this service architecture.
In aspect of external routing, that has redundant architecture by
usage of BGP4+ between Router_1 and Router_A and between Router_2 and
Router_B. In aspect of internal routing, the traffic route was
duplicated for stability of DNS service. Router_A and Router_B have
been configured by cross-connections to DNS servers through Switch_A
and Switch_B, and divided IPv6 networks into two parts to enable DNS
traffics to be distributed by DNS server. This architecture is
configured with consideration of scalability of routers and servers,
and it would be easy to expand the numbers of routers and servers
according to increasing of throughput in the future.
IPv6 Internet IPv6 Internet
| |
| |
+----------+ +----------+
| Router_1 | ASN X | Router_2 |
+----------+ +----------+
______|________________________________|______
| Anycast site |
+----------+ +----------+
| Router_A | ASN XX | Router_B |
+----------+ +----------+
| | | |
| | _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| |
| |_|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
| | | |
| | | |
+----------+ +----------+
| Switch_A | IGP | Switch_B |
+----------+ +----------+
| | | |
| | _ _ _ _ _ _ _ _ _ _ _ __ _ _ _| |
| |_|_ _ _ _ _ _ _ _ _ _ _ __ _ _ _ |
| | | |
Subenet1--| |--Subnet2 Subenet1--| |--Subnet2
+----------+ +----------+
| DNS_A | | DNS_S |
+----------+ +----------+
Figure 1 : DNS anycast mirror site topology
Lee, et al. Expires June 7, 2007 [Page 5]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
3.1. Internal Routing
Internal IPv6 network is connected with two subnets(subnet1, subnet2)
between DNSs(DNS_A, DNS_S) with IGP routing process running and
routers(Router_A, Router_B). IPv6 anycast prefix can be dynamically
delivered to IGP routing table of routers(Router_A, Router_B) through
the message of IGP routing protocol in this area. Also, as IGP
routing is configured on DNS, it is important to configure and
reflect the anycast address prefix to the routing table. The IPv6
address of physical interface is assigned with unique local IPv6
addresses(FC00::/7) (RFC4193 [6]) for IGP routing among equipments.
But, these addresses should never be advertised by IGP protocol
toward external Internet.
3.2. External Routing
The anycast address(/32 prefix) on IGP routing table is dynamically
delivered to routing table of Router_A and Router_B. As Router_A and
Router_B advertise IPv6 anycast address to external routers(Router_1,
Router_2), these routers are just configured to export only an
anycast prefix to the external site(ASN X).
If certain failures occur, such as DNS daemon down, failure of DNS
interface or removing of IPv6 anycast prefix on routing table of IGP
routing protocol, the IPv6 anycast prefix should be automatically
removed on BGP routing table of Router_A and Router_B. In this case,
IPv6 anycast prefix is never advertised to peering site(ASN X). In
consequence, this means that a status of anycast DNS service should
be immediately reflected to upper-side nodes and then DNS query
traffics are forwarded to the next closest DNS site instead of
forwarding to anycast DNS site with failure.
It is possible to provide DNS service, which is served by the closest
DNS server in aspect of clients, through the implementation of BGP
routing-based anycast. It shows that anycast DNS locally handles DNS
query traffics through a routing based distribution mechanism and
makes preparation against DNS service failures by DDoS attack.
4. Managements
When anycast DNS is added on remote site to provide more effective
service rather than generic DNS service, there are several general
guidelines to consider.
This section lists recommendations for stable operation and
maintenance from remote site.
Lee, et al. Expires June 7, 2007 [Page 6]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
4.1. BGP Routing Management
To manage and check the BGP routing status, the well-known monitoring
tools, such as BGP looking glass and BGPlay [7], supporting IPv6
protocol can be used for monitoring the global routing status and
seeing how things will shape up.
4.2. Remote System Management
For monitoring the remote system, The console server based on TCP/IP
protocol can be used, and a back-up access network based on PSTN is
also be able to be used for preparation against console server's
failure.
4.3. DNS Zone-transfer Management
In case of anycast DNS service, anycast IP address is recommended not
to be used as a source address for zone-transfer, because zone-
transfer works based on TCP connection with unicast address.
Therefore, management IP address is recommended to download zone
files from the master server.
4.4. DNS Daemon Management
Whenever a DNS service daemon is failed on anycast DNS, It requires
that DNS damon status checking program spontaneously works to avoid a
incoming DNS query packet by using a mechanism that reflects that
failure status on the routing table.
5. Considerations
Confirmation of the network status of IPv6 peering site(ASN X): The
BGP peering site's service line status between anycast DNS site(ASN
XX) and BGP-peering site(ASN X), and the overall status of BGP
peering site internetworked with upper-side transit-ISPs or IX should
be checked before the installation of anycast DNS site.
BGP filtering: The BGP filtering and packet access rules on the
upper-side network of anycast site(ASN XX) should be checked in
advance.
BGP security configuration: As setting up the BGP configuration, the
authentication algorithm, such as MD5(Message Digest Algorithm 5) is
recommend to be configured on BGP peering session, and then prepared
the various malicious attacks.
Lee, et al. Expires June 7, 2007 [Page 7]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
6. References
[1] Partridge, C., "Host Anycasting Service", RFC 1546,
November 1993.
[2] Hardie, T., "Distributing Authoritative Name Servers via Shared
Unicast Addresses", RFC 3258, April 2002.
[3] Hinden, R., "Internet Protocol Version 6 (IPv6) Addressing
Architecture", RFC 3513, April 2003.
[4] Hinden, R., "IP Version 6 Addressing Architecture", RFC 4291,
February 2006.
[5] "APNIC Policy document, IPv6 Address Allocation and Assignment
Policy", May 2005.
[6] Hinden, R., "Unique Local IPv6 Unicast Addresses", RFC 4193,
October 2005.
[7] "BGPlay RIPE NCC Site, http://www.ris.ripe.net/bgplay".
Authors' Addresses
Seunghoon Lee
National Internet Development Agency of Korea
(KTF Bldg, 3F) 1321-11, Secho-2Dong
Secho-Gu
Seoul 137-857
Republic of Korea
Email: sehlee@nida.or.kr
Chanki Park
National Internet Development Agency of Korea
(KTF Bldg, 3F) 1321-11, Secho-2Dong
Secho-Gu
Seoul 137-857
Republic of Korea
Email: ckp@nida.or.kr
Lee, et al. Expires June 7, 2007 [Page 8]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
Weon Kim
National Internet Development Agency of Korea
(KTF Bldg, 3F) 1321-11, Secho-2Dong
Secho-Gu
Seoul 137-857
Republic of Korea
Email: wkim@nida.or.kr
Lee, et al. Expires June 7, 2007 [Page 9]
Internet-Draft IPv4/IPv6 Anycast DNS Service December 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lee, et al. Expires June 7, 2007 [Page 10]