IPv6 Anycast-based DNS Service Model Seunghoon Lee, Jaechul Suh, Kwanho Song

Korea Network Information Center National Internet Development Agency of Korea

Seoul, Republic of Korea

Abstract— This paper shows an example of how to provide and implement IPv4/IPv6 dual stack anycast DNS services, which is based on experience of IPv4/IPv6 anycast DNS implementation. In order to provide a reference model to DNS operators who have a plan to deploy an IPv4/IPv6 anycast DNS services onto their own DNS servers in the future. This paper mainly specifies a way to configure IPv6-related functions without IPv4-related matters.

Keywords- DNS; IPv6; Anycast; Anycast address; BGP; IGP; IPv6 Anycast Prefix Assignment; TLD anycast DNS server

I. INTRODUCTION

A DNS [1, 2, 3, 4] service is one of the most important Internet infrastructure, and anycast [5, 6, 7] based DNS service [8] has been discussed within DNS operation relevant areas for providing a stable DNS services to the users.

In general, anycast-base DNS service has an 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 of 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, cause of outstanding two regulation [9], it was substantially impossible to deploy at the real IPv6 Internet environment. However, as the related rules were removed, as described in [10], IPv6 anycast-based DNS service could be applicable to name servers on real IPv6 Internet. NIDA 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 a overall DNS service improvements, such as robustness, redundancy and resiliency of DNS Services.

II. IPV6 ANYCAST DNS

2.1 Background

Anycast is defined and considered for a long time, and some limitations that anycast has are analyzed. Anycast is not appropriate for protocols that needs stateful connection, such as various TCP based protocols, and needs packet fragmentations due to large packet size. Anycast does not guarantee that the destination of session is always the same host, but when unstable state of routing system, the destination of session may be changed to another host. This fact put a difficulty in applying anycast to stateful services.

However, anycast is appropriate for DNS protocol and use of

anycast to distribute authoritative name servers has been implemented, such as root name servers and TLD name servers. In most cases of domain name resolution, DNS protocol needs a stateless connection and needs one UDP packet for DNS query and another one UDP packet for DNS response in usual case of DNS query and response process, unless the DNS message size is not larger than 512 octets. Authoritative name server needs TCP session, the stateful connection, for the zone transfer in zone data synchronization between authoritative name servers. Using anycast for authoritative name servers, one should avoid using anycast address for destination address in zone transfer session.

Figure 1. BGP-based anycast service concept

This research was supported by the Ministry of Information and Communication Republic of Korea(MIC) under the project of Internet address resources managemental infrastructure implementation.

Proceedings of Asia-Pacific Conference on Communications 2007

1-4244-1374-5/07/$25.00 ©2007 IEEE 247

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. In this section, we present a typical BGP-based mechanism, as shown in Figure 1.

Figure 2. IGP-based anycast service concept

The above figure, as shown Figure 2, shows an example of IGP-based anycast service mechanism . This paper 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.

2.2. IPv6 Anycast Address Issue

In order to deploy an IPv6 anycast address to the name server served in the IPv6 environment, there are two restrictions as follows [9]. 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 a

IPv6 anycast to DNS service in the IPv6 Internet environment until now. However, the above restrictions were removed by RFC4291[10]. 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 only. This means that it is possible to apply a IPv6 anycast-based DNS service, and NIDA has been providing IPv4/IPv6 anycast DNS service on this fact.

2.3 IPv6 Anycast Prefix Assignments

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 [10]), for service of TLD anycast DNS server. IPv6 anycast node should advertise an address block(prefix) that hasn't no problem with global routing. IPv6 anycast prefix assigned to TLD DNS is decided by RIR's address allocation policy. In case of kr DNS, it was assigned /32 IPv6 address block by APNC's address allocation policy [11] and other RIRs(e.g, RIPE-NCC and ARIN) have /48 allocation policy for that. About this IPv6 address block(prefix) assignment issue, it is necessary to discuss on aspect of RIRs and IETF.

III. TOPOLOGY

The architecture was considered to have an stability and scalability for providing IPv6 anycast DNS service. this will be divided into two parts.

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 3 shows a 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 crossing DNS service lines 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 according to increasing of throughput in the future.

Figure 3. DNS anycast mirror site topology

248

3.1. Internal Routing

Internal IPv6 network is connected with two subnets(subnet1, subnet2) between DNSs(DNS_A, DNS_S) applied with IGP routing daemon 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 physical interface IPv6 address is applied with an unique local IPv6 addresses(FC00::/7) for IGP routing between equipments (RFC4193 [12]). But, these addresses should never be advertised by IGP protocol toward external Internet.

3.2.BGP Routing

The anycast address 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), they are just configured to export only an anycast prefix to the external site(ASN X).

If a certain failures occur, such as DNS daemon down, failure of DNS inferface and disconnection of DNS service network and IPv6 anycast address is deleted on routing table of IGP routing protocol, the IPv6 anycast address should be automatically removed on BGP routing table of Router_A and Router_B. In this case, IPv6 anycast address 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 failured anycast DNS site.

It is possible to provide DNS service, which is served by the closest DNS server, through the implementation of BGP routing-based anycast. It shows that anycast DNS locally handles DNS query traffics through a distribution mechanism and makes preparation against DNS service failures by DDoS attack.

IV. MANAGEMENT

When anycast DNS is added on remote site to provide a service, there are several general guidelines to consider to be able to do it as smoothly as possible. This section lists recommendations for stable operation and maintenance from remote site.

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 [13], supporting IPv6 protocol can be used for monitoring the global routing status and seeing how things will shape up. Especially, BGPlay has a merit of visualization for BGP-based routing path and also it shows a variation of routing path intuitively, as shown in Figure 4.

Figure 4. BGPlay example

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 network based on PSTN is also be able to be use for preparation against console server's failure.

4.3. DNS Zone-transfer Management

In case of anycast DNS service, anycast IP address is not recommended as a use of zone-transfer, because it's not easy to distinguish each one of anycast DNS sites aspect of Identification, therefore, management IP address is recommended to download zone files from the master server. And also, secured transferring methods, such as cryptographic key sharing mechanism(i.e., TSIG[14]), VPN solution and so on, are recommended between master server and mirror site server because these zone data include very critical information. If the DNS zone files are transferred on unsecured Internet, those can be exposed to malicious voyeurs.

4.4. DNS Daemon Management

Whenever a DNS service daemon is failed on anycast DNS, It requires that DNS daemon status checking program

249

spontaneously works to avoid a incoming DNS query packet by using a mechanism that reflects that failure status over the routing table. Also, this checking program manages a status of DNS server’s physical interface and routing daemon. If physical interface is down or unplugged and the routing daemon is down, this checking program should reflect this situation onto the upper side routing table of Router_A and Router_B.

V. CONSIDERATION

5.1. Confirming the IPv6 peering site

Confirming 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 out before the installation of anycast DNS site.

5.2. Checking the access rule

BGP filtering: The BGP filtering and packet access rules on the upper-side network of anycast site(ASN XX) should be checked out in advance.

5.3. Secured BGP connection

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.

VI. CONCLUSION

This paper suggested the service model for IPv6 anycast DNS that supports a stable service in aspect of operation and management on IPv6 environment. This paper shows IPv6 anycast address issue for IPv6 anycast DNS implementation, IPv6 anycast prefix assignment, network configuration methods, overall management and considerations, which is based on kr IPv6 DNS implementation and operations. Especially, this paper introduced that network redundancy, DNS server redundancy model for supporting stable DNS service and presented detailed routing and operational methodologies.

We hope that IPv6 anycast DNS service model suggested

on this paper will be the guideline for DNS administrators who have a plan to deploy the IPv6 and anycast skill to their own DNS servers in the future.

REFERENCES

[1] Paul V. Mockapetris and Kevin J. Dumlap. “Development of the domain name system”, SIGCOMM88, pages 123-133, 1988

[2] Mockapetris, P., "Domain names – Concepts and Facilities", RFC 1034, November 1987.

[3] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.

[4] P. Albitz and C. Liu, “DNS and BIND(3rd ed)”, O’Reilly and Associates, 1998.

[5] Partridge, C., "Host Anycasting Service", RFC 1546, November 1993. [6] J.Abley, “Hierarchical Anycast for Global Service Distribution”, 2003. [7] H. Ballani and P. Francis, “Toward a deployable IP anycast Service”,

Proceedings of WORLDS, December 2004. [8] Hardie, T., "Distributing Authoritative Name Servers via Shared Unicast

Addresses", RFC 3258, April 2002. [9] Hinden, R., "Internet Protocol Version 6 (IPv6) Addressing

Architecture", RFC 3513, April 2003. [10] Hinden, R., "IP Version 6 Addressing Architecture", RFC 4291,

February 2006. [11] "APNIC Policy document, IPv6 Address Allocation and Assignment

Policy", May 2005. [12] Hinden, R., "Unique Local IPv6 Unicast Addresses", RFC 4193,

October 2005. [13] "BGPlay RIPE NCC Site, http://www.ris.ripe.net/bgplay". [14] P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellinton, “Secret Key

Transaction Authentication for DNS (TSIG)”, RFC 2845, May 2000.

250