The following is a list of requirements and recommendations for supporting Anycast DNS:

• Clients should be configured to resolve DNS queries via the Caching DNS server's Anycast address(es).

• Nameservers should advertise their Anycast address in NS and A RRs.

• Nameservers should listen to DNS queries on the Anycast IP addresses.

• Nameservers should be configured with at least one Anycast IP address on a loopback interface.

• Additionally, the server should be configured with a management IP, which can be either a physical or an additional loopback interface.

• At least one physical IP must be defined on the DNS server for the exchange of routing information, as well as, system access and maintenance in the absence of the routes to the Anycast IP address(es).

• Nameservers should be configured to use the physical or management IP addresses for zone transfers, zone updates, and/or query source to ensure that these updates go to the intended server.

• Nameservers should Inject Anycast IP address(es) into the routed network using routing protocols such as RIP, OSPF, or BGP.

Anycast can be manually configured, it is best implemented using routing protocols such as BGP or OSPF, which announces the Anycast destination address to its gateway router. Using a routing protocol to announce availability of the DNS service ensures that routers do not send DNS queries into a blackhole if the service goes down. As the Cisco Prime Network Registrar DNS application does not have routing capabilities, some code, external to the DNS application must be added to the DNS environment (physical server or virtual machine). The prominent and open source products are FRRouting (FRR) for RHEL/CentOS 8.x and Quagga for RHEL/CentOS 7.x.

A sample python script is included with Cisco Prime Network Registrar installation and is located at:

• FRR:

  /opt/nwreg2/local/examples/dns/python/dns_anycast_bgp_frr.py

• Quagga:

  /opt/nwreg2/local/examples/dns/python/dns_anycast_bgp.py

The script starts and stops FRR/Quagga, and monitors the DNS service by sending DNS queries to ensure that it is operational. When FRR/Quagga is started, its FRR/Quagga daemon sends an Anycast advertisement to the connected router making the DNS service available over the Anycast address. If the DNS server does not respond to queries from the script, the script will stop the FRR/Quagga daemon. Stopping FRR/Quagga breaks the TCP connection and the router will stop receiving BGP keep-alive messages. The router will then remove the DNS service from its Anycast group, and start sending DNS queries to the next closest and available DNS service. If the DNS server responds to queries from the script, the script checks to see if the FRR/Quagga daemons are running. If the daemons are not running, then the script starts the daemons.

It is recommended to copy the sample script to a different location, set up a cron job to periodically run the script to check the status of the DNS server (recommended interval is 5 minutes) and start or stop the BGP daemon accordingly. An example of a cron job is outside the scope of this solution.

Your configuration will probably be different based on your network requirements and variations in addressing schemes.

This section describes the basic setup and configuration of Anycast using BGP on a Cisco router and FRR/Quagga host-based routing software. The purpose of this section is not to instruct administrators on the configuration of routers and BGP, but to show a configuration that was successfully tested in the Cisco Prime Network Registrar labs. Note that your network requirements may be different.

BGP is a standardized exterior gateway protocol designed to exchange routing and reachability information among Autonomous Systems (AS) on the Internet. This configuration uses a single AS this recipe is not intended to be solution deployed across Autonomous Systems.

Perform the following steps on the hosts DNS-1 and DNS-2:

DEVICE=lo:0
IPADDR=10.10.10.1
NETMASK=255.255.255.255
BOOTPROTO=none
ONBOOT=yes

Configure the FRR configuration files on both the servers. The following example is for DNS-1. DNS-2 also needs to be configured similarly. The configuration files are located in /etc/frr.

There are number of example configuration files in /etc/frr: one for each routing protocol that FRR supports; one for zebra, the main process. For enabling Anycast using BGP, we need to configure zebra.conf, bgpd.conf, and daemons file.

Configure the Quagga configuration files on both the servers. The following example is for DNS-1. DNS-2 also needs to be configured similarly. The configuration files are located in /etc/Quagga.

There are number of example configuration files in /etc/Quagga: one for each routing protocol that Quagga supports; one for zebra, the main process. For enabling Anycast using BGP, we need to configure zebra.conf and bgpd.conf.

Run diagnostics on the router to make sure that the Anycast is set up properly.

The sh ip bgp summary command output shows that router-1 has opened a BGP session with the two neighbors. The value State/PfxRcd indicates that the TCP session is up and the routers and hosts are exchanging routes. This field should be a numeric value showing how many route prefixes have been received from the remote neighbor. The example value is 1. At this point, the BGP connection with the DNS servers is in Established state.

BGP router identifier 2.2.2.2, local AS number 65500 
BGP table version is 86, main routing table version 86 
1 network entries using 248 bytes of memory 
2 path entries using 240 bytes of memory 
1/1 BGP path/bestpath attribute entries using 248 bytes of memory 
0 BGP route-map cache entries using 0 bytes of memory 
0 BGP filter-list cache entries using 0 bytes of memory 
BGP using 736 total bytes of memory 
BGP activity 16/15 prefixes, 61/59 paths, scan interval 60 secs 

The show ip bgp neighbors command shows information about the neighbors in detail.

#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP 
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
 E1 - OSPF external type 1, E2 - OSPF external type 2 
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 
 ia - IS-IS inter area, * - candidate default, U - per-user static route 
 o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP 
 a - application route 
 + - replicated route, % - next hop override, p - overrides from PfR 
B 10.10.10.1/32 [200/0] via 10.0.3.2, 00:00:10

To monitor the BGP traffic logs on the hosts DNS-1 and DNS-2, use the telnet localhost bgpd command.

FRR:

Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

Hello, this is FRRouting (version 7.0).
Copyright 1996-2005 Kunihiro Ishiguro, et al.


User Access Verification

Password: 
dns-anycast-1> enable
dns-anycast-1# terminal monitor
dns-anycast-1# conf t
dns-anycast-1(config)# debug bgp keepalives
dns-anycast-1(config)# 2020/10/27 02:56:22 BGP: : 10.0.3.1 KEEPALIVE rcvd

dns-anycast-1(config)# 2020/10/27 02:56:23 BGP: : 10.0.3.1 sending KEEPALIVE
2020/10/27 02:56:27 BGP: : 10.0.3.1 KEEPALIVE rcvd
2020/10/27 02:56:28 BGP: : 10.0.3.1 sending KEEPALIVE
2020/10/27 02:56:32 BGP: : 10.0.3.1 KEEPALIVE rcvd
2020/10/27 02:56:33 BGP: : 10.0.3.1 sending KEEPALIVE
2020/10/27 02:56:37 BGP: : 10.0.3.1 KEEPALIVE rcvd
2020/10/27 02:56:38 BGP: : 10.0.3.1 sending KEEPALIVE
2020/10/27 02:56:42 BGP: : 10.0.3.1 KEEPALIVE rcvd
2020/10/27 02:56:43 BGP: : 10.0.3.1 sending KEEPALIVE
2020/10/27 02:56:47 BGP: : 10.0.3.1 KEEPALIVE rcvd
2020/10/27 02:56:48 BGP: : 10.0.3.1 sending KEEPALIVE

Quagga:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Hello, this is Quagga (version 0.99.15).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
User Access Verification
Password:
DNS-1> enable
DNS-1# terminal monitor
DNS-1# 2016/07/13 15:49:20 BGP: 10.0.5.1 send message type 4, length (incl. header) 19
2016/07/13 15:49:21 BGP: 10.0.5.1 rcv message type 4, length (excl. header) 0
2016/07/13 15:49:25 BGP: 10.0.5.1 send message type 4, length (incl. header) 19
2016/07/13 15:49:27 BGP: 10.0.5.1 rcv message type 4, length (excl. header) 0

While this is the conclusion of setting up the Anycast functionality, administrators will need to complete the configuration of the DNS servers. See Managing Zones.

For more information, refer the following links:

• http://www.pacnog.org/pacnog6/IXP/Anycast-v10.pdf

• http://www.nongnu.org/Quagga

• https://frrouting.org/

• https://cumulusnetworks.com/learn/frrouting/

• https://bgpgeek.com/installing-frr/

• https://access.redhat.com/solutions/4967711

• https://access.redhat.com/solutions/4538371

• http://www.linuxjournal.com/magazine/ipv4-anycast-linux-and-Quagga

• http://ddiguru.com/blog/125-anycast-dns-part-5-using-bgp

Note	The above links reference external websites and Cisco is not responsible for keeping them up-to-date. They are provided for reference only. If you find that the content is outdated or if you cannot access the links, please contact the website owner for updated information.