Cisco Conf idential--For Internal Use Only

IPV4 DNS Anycast

This document describes how IP version 4 (IPV4) anycast works, how you can deploy this technology for improving load balancing and security for DNS services in your network, and provides specific configuration instructions for implementation. This document is intended for network design architects, support engineers, and marketing professionals who are responsible for planning, designing, implementing, and operating networks.

Contents
Contents Overview
1 2

What is Anycast? 3 Broadcast 4 Multicast 5 Anycast 6 Anycast Benefits

Deploying IPV4 DNS Anycast 7 How Anycast Works 7 Operational Considerations 8 A Typical DNS Anycast Deployment

Configuration Details 10 Adding a Virtual Interface on the DNS Server 11 Configuring a Routing Process on the DNS Server 12 Verifying the Configuration 13 Additional References
15

Corporate Headquarters: Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

Copyright 2004 Cisco Systems, Inc. All rights reserved.

Overview

Cisco Conf idential--For Internal Use Only

Overview
IP version 4 (IPV4) anycast is an IP addressing technique that facilitates delivery of traffic to any one of several distributed servers offering the same service. Anycast is ideal for services that are stateless and based on a single request and a single response, such as DNS, quote servers, AAA, and syslog. You can also use anycast with applications that are widely distributed across the network, such as distributed sink holes and mitigation clusters. This document only discusses the deployment of anycast services within an IGP (Interior Gateway Protocol) domain and does not address wide area anycast. Anycast uses a single IP address for multiple physical servers offering the same service and distributes these servers at strategic points in the topology. This provides some important benefits, including the ability to sink or contain a saturation attack against a specific instance of a server closest to the ingress point of the attack. By distributing the attack, the load is shared by multiple servers across the entire topology instead of being directed at a single server. Figure 1 shows where this technique fits into the end-to-end security framework, which divides the network into four paths for traffic, referred to as planes.

Data PlaneUser data traffic that is forwarded through a router or other networking device. Control PlaneSystem traffic that terminates or originates at the router or device, which is processed locally, and is essential for maintaining network connectivity. Examples of this kind of traffic include routing updates and Layer 2 keepalives. Management PlaneTraffic that terminates or originates on the router or network device that is not essential to maintain network connectivity, such as management traffic that is used to monitor or configure the device. Examples include Simple Network Management Protocol (SNMP), Telnet, and Syslog. Services PlaneAll traffic associated with essential services offered by the service provider such as DNS, authentication, billing, web services, and software downloads using FTP.
IPV4 DNS Anycast in the SP Infrastructure Security Framework
Planes
Data Plane Control Plane Management Plane Services Plane

Figure 1

Roles Threat Vectors

Reconnaissance Distributed Denial of Service/ Infrastructure Break-ins/Device takeover Theft of Service/ Fraud mitigation Endpoint Customer Premise Access Aggregation Core Data Center NOC Peering

Security risks are classified into four well-known threat vectors.

ReconnaissanceAttacks designed to obtain information required for performing additional exploits.

IPV4 DNS Anycast

Version 1

119967

What is Anycast?

Cisco Conf idential--For Internal Use Only

Distributed Denial of Service / InfrastructureAttacks that seek to disrupt network connectivity or the availability of services. Break-Ins / Device TakeoverAttacks designed to take over network devices or to circumvent network security devices. Theft of Service / Fraud mitigationAttacks or misuse that results in services or data being used without proper authorization.

The matrix in Figure 1 shows how each of these attacks can be directed to different devices, which are classified according to the function or location of the device in the network:

EndpointClient PCs, servers, hosts, or other devices that originate requests for network connectivity or services. Customer PremisesDevices located on the customer site that are required for providing network connectivity to the service provider. AccessDevices located in the access layer that provide connectivity between the Customer Premises devices and the Aggregation layer. AggregationDevices located in the aggregation layer that consolidate traffic from access layer devices and deliver it to devices in the Core layer. CoreDevices located in the core layer that provide backbone connectivity between different networks. Data CenterDevices that provide centralized application, storage, and services for the entire network. NOCDevices in the network operation center that are used for monitoring and managing other network devices. PeeringDevices used for interconnectivity between different IGP (Interior Gateway Protocol) domains.

From the perspective of this security framework, IPV4 anycast is a technique that is part of the services plane security toolkit, shown in Figure 1 by orange dots. You can use anycast to contain a DDoS attack to a specific server in the anycast group. These servers are typically located in the Access, Aggregation, or Core layers of the network infrastructure. In the case of a distributed attack, IPV4 anycast can help ensure that services remain available by distributing the attack load among the servers in the anycast group.

What is Anycast?
All traffic flow in an IP network can be broadly classified as one of four different types:

Unicast Broadcast Multicast Anycast

Multicast and broadcast involve a single sender with multiple recipients, while anycast is designed for traffic exchange between a single sender and recipient in a particular session. Anycast is not a Cisco IOS software feature but is rather an IP addressing technique that is based on advertising non-unique IP addresses from multiple points of origin and then using dynamic routing to deliver anycast traffic to the nearest instance of the service in the network topology.

IPV4 DNS Anycast Version 1

What is Anycast?

Cisco Conf idential--For Internal Use Only

Broadcast
There are three types of broadcast traffic:

Layer 2 or MAC-level broadcast IP limited broadcast IP Directed broadcast

Each of these broadcast types are illustrated in the following diagrams.

Figure 2 MAC-Level or IP Limited Broadcast (Layer 2 or Layer 3)

10.1.1.1 /24

10.1.1.2 /24

10.1.2.1 /24

10.1.3.1 /24
119968

10.1.3.2 /24

Receivers

As shown in Figure 2, in a MAC-level or Layer 2 broadcast, the traffic is received by all devices that are physically connected to the network or VLAN, regardless of the protocol they are running or their IP subnet. This type of traffic is not forwarded by any Layer 3 device, such as a router, and the broadcast domain is limited to the physical network or VLAN. The destination address of the MAC frame is always FF:FF:FF:FF:FF:FF. In an IP limited broadcast, the destination IP address is set to 255.255.255.255. The recipients are all IP devices that are physically connected to the network or VLAN regardless of their IP subnet. This type of traffic is not forwarded by any Layer 3 device, such as a router. The recipients do not include workstations or devices on the network that do not support IP.

IPV4 DNS Anycast

Version 1

What is Anycast?

Cisco Conf idential--For Internal Use Only

Figure 3 IP Directed Broadcast (Layer 3)

10.1.1.1/24

10.1.5.1/24

10.1.1.2/24

10.1.5.2/24

10.1.5.3/24 10.1.1.3/24
119969

Sender 10.1.3.1/24 Receivers

10.1.5.4/24

As shown in Figure 3, in an IP directed broadcast, the destination address is set to 10.1.5.255. All IP devices that are part of the logical IP subnet 10.1.5.0 receive this transmission. Directed broadcast traffic is forwarded by Layer 3 devices, such as routers. However, due to security considerations, many routers are configured to discard directed broadcast traffic.

Multicast
Multicast transmission provides a process for delivering traffic to a set of recipients that belong to a group and may be distributed anywhere across the IP network. The traffic is delivered to every member of the group. Multicast transmission (Figure 4) is based on grouping a set of devices into a multicast group that is defined by a multicast IP address.
Figure 4 Multicast Traffic

10.1.5.1/24

10.1.1.1/24

10.1.5.2/24

10.1.1.2/24

10.1.6.2/24

10.1.6.4/24 10.1.1.3/24 10.1.7.3/24 10.1.3.1/24 Sender Receivers 10.1.7.4/24

119970

IPV4 DNS Anycast Version 1

What is Anycast?

Cisco Conf idential--For Internal Use Only

By using IGMP, any IP device in the network may join the multicast group and become a recipient of multicast traffic directed to the specific multicast address. The sender does not necessarily have to belong to the group.

Anycast
IPV4 anycast transmission is based on identifying a group of servers that offer the same service. Anycast allows a request for a service, which is sent to the group, to be directed to a single server in the group, typically based on route proximity to the origin of the request. As originally described in RFC 1546, anycast is a network service that delivers a datagram to a single mirror server out of a group of servers distributed throughout the network. In IPV4 anycast, a set of servers share the same IP host address (the anycast address), which is typically assigned to a virtual interface on the server. Each server advertises the anycast address using a dynamic routing protocol and the router picks the best route to the server host address based on routing protocol metrics. In the example shown in Figure 5, a request to the anycast address 10.10.10.1 is forwarded by the router to the closest server, which has a virtual IP address set to the anycast address and an actual IP address of 10.1.5.1. Even though other servers on the network share the same anycast address, they do not receive the request because the request is directed by the router to the closest server instance on the 10.1.5.0 network.
Figure 5 Anycast Traffic
10.1.5.1/24 10.10.10.1/24 10.1.1.1/24 10.1.6.2/24 10.10.10.1/24

10.1.1.2/24

10.1.6.4/24 10.1.1.3/24 10.1.7.3/24 10.1.3.1/24 Sender Receivers 10.1.7.4/24 10.10.10.1/24

119971

Anycast Benefits
IPV4 anycast improves high availability and load balancing by causing multiple devices, which provide a service, to appear as a single device. Response time for clients can be improved because requests are routed to servers with the best path to the originator of the request. It is also easier to take server instances out of service for routine maintenance because the load is automatically distributed to the other devices in the anycast group.

IPV4 DNS Anycast

Version 1

Deploying IPV4 DNS Anycast

Cisco Conf idential--For Internal Use Only

In addition, geographic and topological separation of devices makes the service less vulnerable to severe security threats like denial of service (DoS) attacks because the attack is spread over many devices. If detected early, the attack can potentially be contained to a smaller region, which effectively sinks the DoS attack at the server instance that is closest to the source of the attack.

Deploying IPV4 DNS Anycast

This section describes how IPV4 DSN anycast works and explains how you can deploy it in a network. This section includes the following topics:

How Anycast Works Operational Considerations A Typical DNS Anycast Deployment

How Anycast Works

As described earlier, IPV4 DNS anycast is a network service that delivers a datagram to a single server out of a group of servers distributed throughout the network. Figure 6 shows how DNS IPV4 anycast works within a network.
Figure 6 How Anycast Works

192.168.101.15 192.168.5.40 PE-1 P1 P2

192.168.101.15 192.168.7.68 PE-2

OSPF route for 192.168.101.15/32

OSPF route for 192.168.101.15/32

192.168.101.15

192.168.5.40

Sender Receiver

192.168.101.15

192.168.7.68

To implement a DNS anycast service, choose an IP address that will be used as the anycast address for DNS queries. The anycast address represents a group of servers, all of which are capable of providing the same DNS service. In Figure 6, the anycast address is 192.168.101.15 / 32. A virtual interface (loopback or sub-interface) is created on each server that belongs to the anycast group. This newly created interface is assigned the group anycast address of 192.168.101.15 on every server. One of the base requirements for deploying DNS anycast is for the DNS servers to be able to send a route update for the specific anycast address (example 192.168.101.15/32). In order to do this, a routing protocol that supports VLSM needs to be installed on the DNS server. There are many freely available routing protocol implementations, such as quagga, that you can install for OSPF/ISIS/BGP support and that can be used to send route updates for the anycast host address (192.168.101.15 / 32).

IPV4 DNS Anycast Version 1

126103

Deploying IPV4 DNS Anycast

Cisco Conf idential--For Internal Use Only

For example, in Figure 6, PE-1 has a route in the FIB to the anycast address associated with 192.168.5.40 while PE-2 has a route to 192.168.7.68. Based on the FIB entries, incoming traffic to PE-1 that is destined for 192.168.101.15 is forwarded to 192.168.5.40, while incoming traffic to PE-2 for the same anycast address is forwarded to 192.168.7.68 The network topologies for both PE-1 and PE-2 are shown in Figure 7. If PE-1 stops seeing routing updates for the anycast address from 192.168.5.40, it will forward traffic to the anycast address towards P1. P1, in turn, will send it towards P2 from where it will be forwarded to 192.168.7.68.
Figure 7 Network Topology of Server Instances

192.168.101.15 192.168.5.40 PE-1 P1 P2

192.168.101.15 192.168.7.68

PE-2

Operational Considerations
A user workstation is typically configured (static or DHCP) with two different DNS servers, a primary and secondary. If the resolution fails with the primary address, the secondary address is used. Best practices for implementing DNS anycast servers recommend multiple DNS anycast groups as shown in Figure 8. When two anycast groups are available, clients would be configured to use the address of the first anycast group as the primary DNS address, and the address of the second anycast group as their secondary server. Anycast is not suited for long lasting connection-oriented services or any server that has to maintain state information about the client. This is typically not a problem for web services unless they maintain stateful per session user information instead of embedding this information in cookies or URLs. Troubleshooting an anycast deployment includes an additional step for identifying the server instance that is not functioning correctly. You can use the traceroute command to help identify the unicast/administrative IP address of the server instance. Even though the server instance will respond to the traceroute from its anycast address, the previous hop in the path can be helpful in identifying the server. Once a DNS anycast service has been deployed, it is absolutely critical to constantly monitor the widely distributed service to ensure that it is available and reachable from everywhere in the network. Because there are many instances of the same server distributed across the network, it is very important to make sure that all instances of the DNS service are synchronized and serve the same version of the zone. DNS anycast is mostly of relevance for authoritative (non-recursive) service.

IPV4 DNS Anycast

119973

PE-1 Network topology for 192.168.101.15

PE-2 Network topology for 192.168.101.15

Version 1

Deploying IPV4 DNS Anycast

Cisco Conf idential--For Internal Use Only

Also, note that even though the actual DNS service on the server may be down, the machine can still be up and advertising the route to the host and getting requests for the service. To avoid this problem, link the route advertisement to the service by means of a cron job. This is a process, typically implemented with a shell script, that constantly checks to see if the service is active and suppresses the route advertisement if it detects a problem with the DNS service. If the DoS targeted at the DNS server is intense enough, it can take out the infrastructure in front of it, or the server itself. The traffic will then shift to target another instance of the server. This is well known behavior. When designing an anycast solution you must be very careful about understanding the order in which each instance of the service will become the target of an attack. Constantly monitoring all instances of the server and the service is key to detecting an attack and preventing it from spreading to other instances.

A Typical DNS Anycast Deployment

A typical DNS anycast deployment is shown in Figure 8. In this illustration, there are two anycast addresses defined, 192.168.101.15 and 192.168.201.15. There are a total of eight servers that are kept up to date by zone transfers. These eight servers are equally distributed towards the edge of the service provider network. Half of them belong to the anycast group with the address 192.168.101.15 (shown in green) and the other half belong to the anycast group with the address 192.168.201.15 (shown in blue).
Figure 8 Typical DNS Anycast Deployment

First DNS = 192.168.201.15 Second DNS = 192.168.101.15

First DNS = 192.168.101.15 Second DNS = 192.168.201.15

192.168.101.15

192.168.201.15

Zone Transfers 192.168.201.15 Primary DNS server 192.168.101.15 Zone Transfers 192.168.201.15 192.168.101.15
119974

192.168.101.15

192.168.201.15

The service provider edge is divided into four regions and every region is serviced by two servers, each belonging to a different anycast group. The DNS load is distributed between these two anycast groups by assigning (static or DHCP) half the clients to 192.168.101.15 as the primary DNS server address and the other half to 192.168.201.15 as the primary DNS server. All clients have their secondary DNS service set to the other anycast group address.

IPV4 DNS Anycast Version 1

Configuration Details

Cisco Conf idential--For Internal Use Only

If a DNS query to the primary anycast address fails, the client tries the next DNS address and the request will be forwarded to the closest instance of the server that belongs to that group. Note that the DNS query to the primary anycast address will not fail as long as a single server in the primary anycast group can still provide adequate service. The zone transfers between primary and secondary or caching servers uses the unicast/administrative IP addresses of the servers. If Unicast Reverse Path Forwarding (uRPF) and egress filtering are configured at the edge, the appropriate adjustments need to be made to permit egress traffic sourced from the anycast addresses 192.168.101.15 and 192.168.201.15.

Configuration Details
There are several major steps in deploying anycast services. The configuration steps in this section refer to the network illustrated in Figure 9.
Figure 9 DNS Anycast Configuration Example

PE-1 .250 Cisco 3620 PE-2 .249 Cisco 3620 .2 192.168.2.0 .1 .251 .1 .2 192.168.3.0 Core 1 PoS .1 .3

192.168.101.15 DNS-2 .16 192.168.4.0 .2 192.168.1.0 .2 .1 .246 192.168.5.0 Core 2 .252 Cisco 6506 192.168.100.0 eBGP 10.1.1.0 10.1.2.0 10.1.3.0

PE-3 .248 Cisco 3620

192.168.101.15

PE-4

.247

Cisco 7200-VXR

In this example, the anycast group address is 192.168.101.15. The two DNS servers in this group, which share this anycast address, are DNS-1 and DNS-2. In this sample configuration, OSPF is used as the routing protocol on the DNS servers, which is then redistributed into ISIS used in the core. Normal operation for this implementation can be tested by trying to resolve a host name at PE1 and making sure that it is resolved by the DNS server DNS-1 because that is the DNS server that is topologically closest to PE1. The failure scenario can be tested by hitting DNS-1 with a saturation attack so it loses its OSPF adjacency with Core1. Core1 should then install a new route for the anycast address through Core2 so that all further DNS requests to the anycast address are forwarded to DNS-2.

IPV4 DNS Anycast

10

119975

.15

DNS-1

.3

Version 1

Configuration Details

Cisco Conf idential--For Internal Use Only

Adding a Virtual Interface on the DNS Server

This example, illustrated in Figure 9, is based on Solaris version 2.8. The steps for adding a virtual interface on a Solaris-based DNS server are shown below. In the example, these steps would be performed on DNS-1 and DNS-2.
Step 1

Create a new file in the /etc directory, as in the following example:

[root@DNS-1>>/root# cat /etc/hostname.hme1:1 DNS-1-virtual

In this example, the new filename is hostname.hme1, and the host name entry is DNS-1-virtual.
Step 2

Edit the /etc/hosts file to map the host name in the new file to the correct IP address:
[root@DNS-1>>/root# cat /etc/hosts # # Internet host table # 127.0.0.1 localhost unix 172.26.185.15 DNS-1 loghost 192.168.3.15 DNS-1-hme1 192.168.101.15 DNS-1-virtual [root@DNS-1>>/root#

Step 3

Edit the netmasks file and make sure there is a subnet mask configured for the new IP network:
[root@DNS-1>>/root# cat /etc/netmasks # # The netmasks file associates Internet Protocol (IP) address # masks with IP network numbers. <snip> 172.26.185.0 255.255.255.0 192.168.3.0 255.255.255.0 192.168.101.0 255.255.255.0 [root@DNS-1>>/root#

Step 4

The address used for the anycast group is 192.168.101.15 but you must set the subnet mask to using the ifconfig statement. In this example, the necessary statement is included in the file /etc/rc2.d/S76static-routes.
[root@DNS-1>>/etc/rc2.d# more S76static-routes route add net 192.168.0.0 192.168.3.1 route add default 172.26.185.1 1 ifconfig hme1:1 192.168.101.15 netmask 255.255.255.255

This subnet mask is based on Variable Length Subnet Masking (VLSM), which requires RIP version 2, which was introduced in Solaris versions 2.6 and above. If you are using RIP version 1, you will need to use a shorter subnet mask and dedicate the entire network to the anycast address.
Step 5

Verify that the virtual interface has the correct IP address and mask configured.
[root@DNS-1>>/etc/rc2.d# ifconfig -a lo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 hme0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 172.26.185.15 netmask ffffff00 broadcast 172.26.185.255 ether 8:0:20:a7:4a:b3 hme1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.3.15 netmask ffffff00 broadcast 192.168.3.255 ether 8:0:20:a7:4a:b3

IPV4 DNS Anycast Version 1

11

Configuration Details

Cisco Conf idential--For Internal Use Only

hme1:1: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3 inet 192.168.101.15 netmask ffffffff broadcast 192.168.101.255

Configuring a Routing Process on the DNS Server

This section describes the steps for configuring a routing process on each DNS server. In the lab we used the routing protocol suite downloaded from www.quagga.net that supports OSPF.
Step 1

Once compiled and installed, the OSPF process can be started as a daemon using the OSPF configuration file. The command to start the server is ospfd -d -f ospfd.conf. This configuration is specific to quagga. The config file used is shown below.
[root@DNS-1>>/opt/quagga/ospfd# more ospfd.conf ! -*- ospf -*! ! OSPFd sample configuration file ! ! hostname DNS-1 password splob enable password splob ! router ospf network 192.168.3.0/24 area 0 network 192.168.101.0/24 area 0 ospf router-id 192.168.3.15 ! Log stdout

Step 2

To verify that the OSPF process is running enter the following command:
[root@DNS-1>>/opt/quagga/ospfd# ps -ef | grep ospfd root 4787 4728 0 16:36:55 pts/7 0:00 grep ospfd quagga 4779 1 0 16:02:28 ? 0:00 ./ospfd -d -f /opt/quagga/ospfd/o spfd.conf

Step 3

To check the routing entries on the server, enter the netstat -r command, as shown in the following example:
[root@DNS-1>>/root# netstat -rn Routing Table: IPv4 Destination -------------------192.168.255.247 192.168.255.246 192.168.101.15 192.168.255.245 192.168.255.253 192.168.255.252 192.168.255.251 192.168.255.250 192.168.101.0 192.168.255.249 192.168.255.248 192.168.200.0 192.168.1.0 192.168.2.0 192.168.3.0 192.168.4.0 192.168.100.0

Gateway Flags Ref Use Interface -------------------- ----- ----- ------ --------192.168.3.1 UGH 1 0 192.168.3.1 UGH 1 1 192.168.101.15 UH 1 0 hme1:1 192.168.3.1 UGH 1 0 192.168.3.1 UGH 1 0 192.168.3.1 UGH 1 0 192.168.3.1 UGH 1 0 192.168.3.1 UGH 1 0 172.26.185.16 UGH 1 0 192.168.3.1 UGH 1 0 192.168.3.2 UGH 1 0 192.168.3.1 UG 1 0 192.168.3.1 UG 1 0 192.168.3.1 UG 1 18 192.168.3.15 U 1 79 hme1 172.26.185.16 UG 1 4 192.168.3.1 UG 1 0

IPV4 DNS Anycast

12

Version 1

Configuration Details

Cisco Conf idential--For Internal Use Only

192.168.5.0 172.26.185.0 192.168.0.0 224.0.0.0 default 127.0.0.1 [root@DNS-1>>/root# 192.168.3.1 172.26.185.15 192.168.3.1 172.26.185.15 172.26.185.1 127.0.0.1 UG U UG U UG UH 1 2 1 2935 1 0 1 0 1 4290 467492676 hme0 hme0 lo0

Step 4

Limit the updates received from the DNS server to the anycast address / network by applying a route map prior to redistribution into ISIS. In the lab setup that was tested, the route to the anycast address configured on the virtual interface of the DNS server was discovered using OSPF. Because the DNS server is typically not used for routing for security reasons, the updates received from it should be limited to the anycast address / network by applying a route map prior to redistributing the anycast host address using ISIS. This also prevents malicious routing updates from affecting the network even if the DNS server is compromised. The following is the sample configuration from a router exchanging OSPF routes with a Solaris-based DNS server. In the example, a route map called anycast is created that permits only the anycast address. This route map is then applied when redistributing OSPF into ISIS.
router ospf 100 log-adjacency-changes passive-interface FastEthernet1/0 passive-interface POS2/0 passive-interface Loopback0 network 192.168.3.0 0.0.0.255 area 0 ! router isis net 49.0001.0001.0001.1921.6825.5251.00 domain-password spLab redistribute ospf 100 route-map anycast level-1-2 passive-interface Loopback0 ! ip classless no ip http server ! ! ! access-list 1 permit host 192.168.101.15 ! route-map anycast permit 10 match ip address 1

Verifying the Configuration

This section describes the steps required to verify your configuration.
Step 1

On core1, make sure that the route learned from DNS-1, the DNS server, for the anycast address is installed in the routing table.
core1#sh ip route 192.168.101.15 Routing entry for 192.168.101.15/32 Known via "ospf 100", distance 110, metric 11, type intra area Redistributing via isis Advertised by isis metric-type internal level-1-2 Last update from 192.168.3.15 on FastEthernet1/1, 2d19h ago Routing Descriptor Blocks: * 192.168.3.15, from 192.168.3.15, 2d19h ago, via FastEthernet1/1

IPV4 DNS Anycast Version 1

13

Configuration Details

Cisco Conf idential--For Internal Use Only

Route metric is 11, traffic share count is 1

As can be seen from the information in this listing, the best path to 192.168.101.15 / 32 is through the real address of the DNS server, which is 192.168.3.15.
Step 2

Verify the route on core2.

core2#sh ip route 192.168.101.15 Routing entry for 192.168.101.15/32 Known via "ospf 100", distance 110, metric 11, type intra area Redistributing via isis Advertised by isis metric-type internal level-1-2 Last update from 192.168.4.16 on FastEthernet1/0, 2d19h ago Routing Descriptor Blocks: * 192.168.4.16, from 192.168.4.16, 2d19h ago, via FastEthernet1/0 Route metric is 11, traffic share count is 1

Here we see that the best path to the same anycast address is through the real IP address of the DNS server, DNS-2, which is 192.168.4.16.
Step 3

To make sure that DNS queries destined to the anycast address 192.168.101.15 coming in on core1 are being resolved by the DNS server DNS-1 we trace the route to the anycast address from PE-1
PE-1#traceroute ip 192.168.101.15 Type escape sequence to abort. Tracing the route to DNS-1.secure-lab.com (192.168.101.15) 1 192.168.2.1 4 msec 4 msec 0 msec 2 192.168.101.15 0 msec 0 msec 0 msec

This output shows that the route from PE-1 to the anycast address is two hops away through core1. So, all DNS queries directed to the anycast group from PE-1 will be resolved by DNS-1. If DNS-1 encounters a saturation attack and is unable to send OSPF updates for the anycast address 192.168.101.15, the router (core1) reinstalls a new route to that address using the redistributed route from core2 using ISIS. This process is shown below.
3d01h: %OSPF-5-ADJCHG: Process 100, Nbr 192.168.3.15 on FastEthernet1/1 from FULL to DOWN, Neighbor Down: Dead timer expired 3d01h: RT: del 192.168.101.15/32 via 192.168.3.15, ospf metric [110/11] 3d01h: RT: delete subnet route to 192.168.101.15/32 3d01h: RT: delete network route to 192.168.101.0 3d01h: RT: add 192.168.101.15/32 via 192.168.1.2, isis metric [115/10]

Step 4

A DNS request from PE-1 sent to the same anycast address 192.168.101.15 is now routed to DNS-2, which can be seen by tracing the route to the same anycast address 192.168.101.15:
PE-1#trace 192.168.101.15 Type escape sequence to abort. Tracing the route to DNS-1.secure-lab.com (192.168.101.15) 1 192.168.2.1 0 msec 0 msec 0 msec 2 192.168.1.2 0 msec 0 msec 0 msec 3 192.168.101.15 0 msec 0 msec 0 msec PE-1#

IPV4 DNS Anycast

14

Version 1

Additional References

Cisco Conf idential--For Internal Use Only

Additional References
The following are websites where you can obtain additional information about IPV4 DNS anycast: http://www.cisco.com/public/cons/isp/essentials/ip-anycast-cmetz-03.pdf http://marc.theaimsgroup.com/?l=nanog&m=102587711318901 http://www.nanog.org/mtg-0310/miller.html ftp://ftp.isi.edu/in-notes/rfc1546.txt RFC1546: Host Anycasting Service RFC2101: IPv4 Address Behavior Today RFC2181: Clarifications to DNS RFC2780: IANA Allocation Guidelines for IP RFC3068: An Anycast Prefix for 6to4 Relay Routers RFC3258: Distributing Authoritative Name Servers via Shared Unicast Addresses RFC3446: Anycast RP mechanism using PIM and MSDP

Copyright 2004 Cisco Systems, Inc. All rights reserved. CCSP, the Cisco Square Bridge logo, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, PreRouting, ProConnect, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0406R)

Copyright 2004 Cisco Systems, Inc. All rights reserved.

IPV4 DNS Anycast Version 1

15

Additional References

Cisco Conf idential--For Internal Use Only

IPV4 DNS Anycast

16

Version 1