Using Anycast in Infoblox DNS Reference Architecture
Anycast is a network addressing and routing methodology with many advantages for service providers. It increases network speed for better user experience. It makes your network more resilient in the case of a data center outage. And, it makes your network more secure, particularly against DDoS attacks. All of this is possible because Anycast enables multiple destinations to have the same IP address – meaning there are not only multiple routes to the final destination, but multiple final destinations. Having these options reduces the number of hops needed between nodes (faster), and reduces the risk of cyber attack (traffic can still flow even if one server is being bombarded).
Infoblox’s reference architecture supports Anycast, and we can help network architects and DNS operators leverage all of its benefits. Infoblox’s secure appliances, in combination with Anycast, provide service providers with the most efficient and resilient DNS service delivery platform. In this article, you will learn about:
- Properties of Infoblox’s reference architecture
- Implementation with Infoblox
- Operational management
PROPERTIES OF THE REFERENCE ARCHITECTURE
The Infoblox best practice architecture deploys Anycast on the backbone between PoPs (Point of Presence) and Anycast within the PoP. This architecture has several important properties, which are outlined below.
In case of a PoP failure, Infoblox will automatically reroute the DNS traffic to the closest available PoP. In case of appliance failure within a PoP, DNS traffic will be automatically shared amongst remaining Infoblox appliance in the PoP.
Infoblox Bidirectional Forwarding Detection (BFD) protocol support allows for sub-second link failure discovery and DNS rerouting triggering. Appliances can also be deployed in HA pairs for additional redundancy.
DNS caching service health is also tracked in real time by active watchdog processes linked to BFD protocol state. If a set of DNS resolution fails, the appliance will automatically leave the Anycast group to avoid a DNS black hole effect.
Anycast effectively shortens the path between the subscriber and DNS service, as Infoblox appliances are designed to be installed close to core routing. Without needing to secure the load balancing layer, Anycast routing will enable a fully flexible and path-optimized DNS packet flow and will take advantage of all future core packet routing upgrades.
Also, Infoblox appliances have been optimized for low latency as they perform record prefetching. On high-end Infoblox appliances, latency can be measured in the order of microseconds.
Additional DNS capacity can be added by inserting new Infoblox DNS appliances in the Anycast group. New appliances can be located on an existing or new POP as long as the routing constraints permit it.
Anycast tuning and monitoring is a pure routing place process that relies on standard BGP/OSPF/BGD protocols. It can be easily added to the existing core routing procedures, and the existing core network team does not require any DNS knowledge.
In case an appliance needs to be taken down for maintenance by shutting down the DNS service, Infoblox will automatically remove the Anycast route advertisement.
Security-hardened Infoblox appliances do not require peripheral security devices like firewalls, DPI or other components to defend the DNS, resulting in lower acquisition and operating costs.
Separate management and production
Infoblox appliances come with dedicated management and production interfaces. Management traffic and production traffic can be completely isolated. For production, dedicated IP addresses for subscriber DNS service delivery (Anycast) and dedicated IPs for recursion to the Internet can be configured.
Figure 1: Overview of Anycast between PoPs and within PoP
CONFIGURE AN INFOBLOX APPLIANCE WITH ANYCAST
Infoblox uses Anycast to provide reliable DNS service. Multiple appliances share one or more common Anycast IP address. On the appliance, Anycast addresses are assigned to a loopback interface with a subnet mask of /32. These Anycast IP are advertised by BGP or OSPF with the LAN interfaces as next hops. The core then routes DNS packets according to RFC standard and routing policy.
BGP support offers internal/external setup with multihop support, along with OSPFv2/v3, BFD for IPv4 and IPv6.
If Infoblox Advanced DNS Protection (ADP) is implemented, enabling OSPF/BGP/BFD will automatically enable the corresponding ADP protection.
With an ADP rate limit, rules can enforce policy per source IP. This implies that balancing must be done at the session level, not at the packet level, to achieve a level of persistence that the same DNS server will serve a specific subscriber. For that purpose, Equal Cost Multi Path (ECMP) should be used. DNS Anycast with ECMP guarantees that DNS queries are distributed between the Anycast group members with a persistent flow per Source IP/Destination IP.
ECMP algorithms are vendor-specific. Hash-based algorithms prioritize session stickiness, which Infoblox prefers for ADP. The number of ECMP paths is hardware-specific and determines the number of appliances behind an Anycast address. For example, Cisco NX-OS and Juniper support up to 16 paths to a destination.
FOUR CONFIGURATION STEPS
Anycast can be enabled in four steps:
- Configure the Loopback address
- Configure OSPF/BFD on the interface
- Configure DNS services to use (“listen”) on the Anycast address
- DNS Health check monitor
Each step is described in more detail below.
Step 1: Configure the Loopback address
The loopback interface lets you assign “extra” addresses to the appliance. The Loopback interface supports up to 20 “extra” addresses. You will assign the Anycast address to the loopback interface on each appliance in the group.
In the grid member settings, you can add the Loopback address in the Anycast tab.
Step 2: Configure OSPF/BFD on the LAN interface
BFD templates need to be created and assigned to OSPF Area or BGP neighbors. BFD can be enabled for BGP or OSPF. Simultaneous is possible, but only one BFD session will be created for a given neighbor. Infoblox recommends you use the same BFD template for both OSPF and BGP neighbor whenever such a configuration is required.
BFD templates can be configured from the toolbar under Grid > Grid Manager.
Next, an example will be given where OSPF will be enabled.
The Hello and Dead parameters that determine how OSPF responds can be tuned to your network. In case of good quality links, Hello can be set to 2 and Dead to 6. Note: BFD kicks in faster than OSPF hold-down timers. The neighbor router will remove the IP from routing tables before OSPF does.
Step 3: Configure DNS services to use (“listen”) on the Anycast address
In the member DNS properties, the Anycast IP address can be added to the addresses on which the server provides DNS service.
The appliance also needs to be configured to send recursive queries to the Internet from a dedicated interface. To accomplish this, the following setup should be applied:
- LAN 1: Receive queries and therefore has to listen on the Anycast address. This can be an address from a private address range.
- LAN 2 is used for recursion to the Internet to resolve the names that are not yet in cache. This interface uses a public IP address.
Ensure that you configure an access list (ACE or named ACL) in the Member DNS properties so that the appliance will only provide DNS services to your subscribers and it cannot be abused as an open resolver.
Step 4: DNS Health Check Monitor
A DNS health probe can query for DNS names. Multiple names can be configured. Once the health check fails according to the settings, BFD can mark itself unavailable, which will bring down the BFD session. The BDF peer picks this up and also removes the route. Health check continues, and once the health status is back to normal, it will advertise itself again.
The following section discusses best practices for operational management, including DNS service integration and Anycast server identification.
DNS Service Integration
Anycast is fully integrated with the DNS service. The routes are automatically removed when the DNS service is stopped.
When the user stops the DNS service, BGP/OSPF are also stopped, and the BFD peer is notified.
When DNS is restarted (planned or recovery), OSPF is restarted immediately (OSPF advertisements are reset). BGP is not immediately restarted, but if DNS remains down for a longer duration (> 5 sec), BGP will be stopped. The BFD peer will also pick up on this.
The appliance supports OSPF, BGP and BFD SNMP traps compliant with RFC 7330 & 7331.
Anycast Server Identification
With Anycast, the network will decide what server will receive the query. For debugging purposes, the Infoblox solution can be configured to include server identification.
When the server identification is configured, the Infoblox appliance will include the hostname or server-id in the response. Below you find an example with the dig command. With the +nsid the server-id1234 of the above screenshot is returned.