Delivering Anycast DNS in AWS with Infoblox Universal DDI™ and AWS Cloud WAN

Introduction

Over the past few months, in conversations I've had with enterprises running workloads across multiple regions and hybrid clouds, one theme kept coming up: DNS keeps biting them. Everyone wants the same thing: consistent, resilient DNS services that "just work" everywhere. But when you start layering in multi-cloud topologies, global reach and the need for fast failover, Anycast DNS quickly shifts from "nice to have" to "hard to manage."

That's where this story begins. In this blog, we'll walk through how Infoblox Universal DDI™ and NIOS-X can be deployed natively in AWS, integrated with Cloud WAN and extended with Anycast DNS to provide global reachability. The magic is in combining Infoblox's centralized management and automation with AWS's global networking fabric so you can onboard apps faster, reduce operational overhead and deliver a DNS fabric that's both highly available and cloud ready.

The lab we built demonstrates a practical design with two AWS regions, Frankfurt and Paris. Each region has Shared Services and Production virtual private clouds (VPCs), with Infoblox NIOS-X appliances delivering Anycast DNS. AWS Cloud WAN ties the regions together, optimizing routing and ensuring DNS requests seamlessly fail over when needed.

Figure 1. High-level topology across Frankfurt (eu-central-1) and Paris (eu-west-3) interconnected by AWS Cloud WAN

Deploying Infoblox NIOS-X in AWS

The foundation of the design is the deployment of Infoblox NIOS-X appliances in the Shared Services VPCs across regions. These appliances act as the DNS engines for the environment and are centrally managed through the Universal DDI portal. Deployment leverages standard AWS EC2 workflows together with Infoblox join tokens for seamless onboarding.

Deployment steps:

1. Launch NIOS-X instances in each target region using the Infoblox-provided AMI from the AWS Marketplace.
2. Apply join tokens during instance initialization so that appliances automatically register with the Universal DDI portal.
3. Validate onboarding by confirming that the new NIOS-X instances appear under Configure → Servers in the Universal DDI portal.

While this blog keeps the focus on architecture, the lab that follows goes further. There we'll show how the same deployment workflow can be integrated into a continuous integration (CI)/continuous delivery (CD) pipeline so that NIOS-X appliances can be spun up, registered and configured automatically as part of your infrastructure-as-code process.

Figure 2. Universal DDI portal showing NIOS-X appliances registered and online (Configure → Servers)

Why This Matters: This automated onboarding workflow eliminates manual registration steps and ensures new appliances are consistently visible in Universal DDI across regions, reducing deployment time and human error.

AWS Infrastructure Setup

In each AWS region, we provisioned two distinct VPCs:

• Shared Services VPC hosting Infoblox NIOS-X appliances and other foundational infrastructure services.
• Production VPC hosting the application workloads that consume DNS and other shared services.

This separation is not new. It's a classic networking design principle. In the data center, we always carved out a shared infrastructure domain: DNS, DHCP, Active Directory, logging, PKI, monitoring and other core services ran there, decoupled from individual app environments. Connectivity was enforced through virtual routing and forwarding (VRF) separation and route leaking, ensuring reachability while keeping lifecycles cleanly isolated.

In the cloud, the same logic applies, only the mechanics change. Instead of VRFs and firewalls, you use VPCs, peering, Transit Gateway, Cloud WAN and security constructs provided by the cloud service provider (CSP). The architectural pattern stays the same: shared infrastructure delivers consistency while application environments consume those services over well-defined, secure pathways.

As networking architects, we need to recognize that the move to cloud doesn't eliminate these design rules, it just translates them into new constructs. And at the global level, AWS Cloud WAN stitches those shared infrastructures together, providing the backbone that makes services like Anycast DNS available everywhere.

Figure 3. Create AWS global network in network manager

Figure 4. Create core network and select regions/edge/segments

Why This Matters: Defining edge locations and segments early provides a structured backbone that scales across multiple regions and simplifies traffic separation.

Attaching VPCs and Connect Attachments

With the Cloud WAN backbone in place, the next step is to attach the regional resources so that traffic can actually flow across the global fabric. Attachments act as the integration points between VPCs, appliances and the Cloud WAN core network, enabling routing consistency and policy enforcement end-to-end.

Steps performed:

1. VPC Attachments: Connected both Shared Services and Production VPCs into Cloud WAN, with DNS support enabled to ensure queries are routed through the backbone.
2. Connect Attachments: Established Connect attachments for the Infoblox NIOS-X appliances, using tunnel-less Border Gateway Protocol (BGP) (no additional encapsulation).
3. Connect Peers: Configured BGP peers for each NIOS-X instance with their assigned IP addresses and Autonomous System Numbers (ASNs), establishing dynamic routing into the Cloud WAN fabric.
4. VPC Route Tables: Updated to forward inter-VPC traffic and the Anycast VIP (10.10.10.10) through Cloud WAN, ensuring applications in any region can reach DNS consistently.

Design Callout: Why tunnel-less BGP?

By using tunnel-less mode, routing is simplified-there's no Generic Routing Encapsulation (GRE) or IPsec encapsulation overhead, fewer moving parts and less operational complexity. Troubleshooting is more straightforward, since routes exchanged over Cloud WAN are visible as native BGP sessions without additional encapsulation layers. The result is a cleaner design that's easier to scale and operate.

Figure 5. VPC attachment creation with DNS support enabled

Figure 6. Connect attachment creation (NO_ENCAP/tunnel-less)

Figure 7. Connect attachment BGP peer's configuration (peer IPs, ASNs)

Figure 7. Connect attachment BGP peers configuration details (BGP would show down since we didn't yet configure the NIOS-X side, but the screenshot here is when all is configured, hence it shows BGP Status UP)

Figure 8. VPC route tables (updated)

Why This Matters: Using both VPC and Connect attachments allows application VPCs and DNS infrastructure to be integrated consistently while enabling NIOS-X to advertise Anycast IPs into Cloud WAN through BGP.

Defining AWS Cloud WAN Policies

Once VPCs and Connect attachments are in place, the next step is to apply Cloud WAN policies. Policies are the control plane logic that determine:

• How attachments are grouped into segments (similar to VRFs in a traditional network)
• How routing information is shared between those segments
• Which paths are preferred or load-balanced across the backbone

Think of Cloud WAN policies as the "intent file" for your global network-they abstract away per-VPC routing complexity and instead let you describe connectivity in terms of segments and sharing rules.

Below is the full policy applied in our lab:

{ 
  "version": "2021.12", 
  "core-network-configuration": { 
    "vpn-ecmp-support": true, 
    "dns-support": true, 
    "security-group-referencing-support": false, 
    "inside-cidr-blocks": [ 
      "172.16.222.0/24", 
      "172.16.223.0/24" 
    ], 
    "asn-ranges": [ 
      "65400-65500" 
    ], 
    "edge-locations": [ 
      { 
        "location": "eu-central-1", 
        "asn": 65400, 
        "inside-cidr-blocks": [ 
          "172.16.222.0/24" 
        ] 
      }, 
      { 
        "location": "eu-west-3", 
        "asn": 65402, 
        "inside-cidr-blocks": [ 
          "172.16.223.0/24" 
        ] 
      } 
    ] 
  }, 
  "segments": [ 
    { 
      "name": "SharedServices", 
      "edge-locations": [ 
        "eu-central-1", 
        "eu-west-3" 
      ], 
      "require-attachment-acceptance": false 
    }, 
    { 
      "name": "PROD", 
      "edge-locations": [ 
        "eu-central-1", 
        "eu-west-3" 
      ], 
      "require-attachment-acceptance": false 
    } 
  ], 
  "network-function-groups": [], 
  "segment-actions": [ 
    { 
      "action": "share", 
      "mode": "attachment-route", 
      "segment": "SharedServices", 
      "share-with": [ 
        "PROD" 
      ] 
    }, 
    { 
      "action": "share", 
      "mode": "attachment-route", 
      "segment": "PROD", 
      "share-with": [ 
        "SharedServices" 
      ] 
    } 
  ], 
  "attachment-policies": [ 
    { 
      "rule-number": 100, 
      "description": "Attach SharedServices VPCs to SharedServices segment", 
      "condition-logic": "or", 
      "conditions": [ 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "vpc-024743b1d00009219" 
        }, 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "vpc-02add70a8637c5acf" 
        } 
      ], 
      "action": { 
        "association-method": "constant", 
        "segment": "SharedServices" 
      } 
    }, 
    { 
      "rule-number": 110, 
      "description": "Attach PROD VPCs to PROD segment", 
      "condition-logic": "or", 
      "conditions": [ 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "vpc-098ea96bb41ecbfa7" 
        }, 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "vpc-0fb8ce0b7277bcaec" 
        } 
      ], 
      "action": { 
        "association-method": "constant", 
        "segment": "PROD" 
      } 
    }, 
    { 
      "rule-number": 120, 
      "description": "Place CONNECT attachment for niosx01aws/niosx02aws (eu-central-1) into SharedServices", 
      "condition-logic": "or", 
      "conditions": [ 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "attachment-060212557d5e7d06b" 
        } 
      ], 
      "action": { 
        "association-method": "constant", 
        "segment": "SharedServices" 
      } 
    }, 
    { 
      "rule-number": 125, 
      "description": "Place CONNECT attachment for niosx03aws/niosx04aws (eu-west-3) into SharedServices", 
      "condition-logic": "or", 
      "conditions": [ 
        { 
          "type": "resource-id", 
          "operator": "equals", 
          "value": "attachment-00a26092ee329caeb" 
        } 
      ], 
      "action": { 
        "association-method": "constant", 
        "segment": "SharedServices" 
      } 
    } 
  ] 
} 

Policy Breakdown:

Core Configuration: Defines ASN ranges, inside CIDR blocks for Connect peers, edge locations and two segments (Shared Services, PROD).

Segment Actions: Allow Shared Services and PROD to exchange routes for reachability.

Rule 100: Associates Shared Services VPCs (vpc-024743b1d00009219, vpc-02add70a8637c5acf).

Rule 110: Associates PROD VPCs (vpc-098ea96bb41ecbfa7, vpc-0fb8ce0b7277bcaec).

Rule 120: Maps Frankfurt NIOS-X Connect attachment (attachment-060212557d5e7d06b) to Shared Services.

Rule 125: Maps Paris NIOS-X Connect attachment (attachment-00a26092ee329caeb) to Shared Services.

Why This Matters: VPCs are dynamically associated with the right segments, DNS appliances are always anchored in Shared Services and segments share routes for seamless DNS resolution.

Figure 9. AWS network manager policy view showing applied policy/version

Configuring Anycast DNS in Infoblox

With connectivity in place, we enabled Anycast DNS in Universal DDI.

Steps performed for all NIOS-X appliances in the Infoblox Portal:

1. Enable DNS service under Configure → Service Deployment → Protocol Service.
2. Create Anycast configuration under Configure → Networking → Anycast.
3. Create Anycast Service and associate it with DNS.
4. Configure BGP peers to advertise the Anycast route into Cloud WAN.

Figure 10. Universal DDI-Enable DNS service (Configure → Service Deployment → Protocol Service → Create Service → DNS)

Figure 11. Universal DDI-Anycast configuration (Networking → Anycast → Create Anycast Configuration)

Figure 12. Universal DDI-Anycast service creation (Configure → Service Deployment → Protocol Service → Create Service → Anycast)

Figure 13. Universal DDI-BGP peer configuration for Anycast service

Figure 14. Universal DDI-Anycast IP shows green/active

We didn't cover it in this blog, but the hands-on lab that follows goes deeper. There, you'll see how to make Anycast DNS failover much faster, without being stuck with default BGP control-plane timers. In the lab, we show how you can use AWS Lambda to listen for events like a BGP session flapping or a route disappearing from the routing table-and react in real time.

Validation

We validated the design end to end across both regions.

Checks performed:

• Routes learned from Cloud WAN visible in the Cloud WAN route tables.
• BGP sessions UP between NIOS-X and Cloud WAN Connect peers.
• Anycast IP shows active in Universal DDI.
• EC2 queries via Anycast from both regions.

Figure 15. Routes learned from Cloud WAN visible in the Cloud WAN route tables

Figure 16. AWS-Connect peer's status shows UP (per region)

Figure 17. EC2 in PROD (Frankfurt)-dig output resolving via Anycast IP

Figure 18. EC2 in PROD (Paris)-dig output resolving via Anycast IP

Why This Matters: Validation proves Anycast DNS works seamlessly across regions-routing handled by Cloud WAN, resiliency provided by BGP.

Conclusion

This lab showcases how Universal DDI and NIOS-X can be deployed in AWS to deliver a resilient, Anycast-based DNS fabric across multiple regions. By integrating with AWS Cloud WAN, enterprises gain a single policy-driven backbone that makes DNS highly available, globally reachable and easier to operate at scale.

What you get is more than just DNS resolution-it is a cloud-native architecture that aligns with enterprise requirements for agility, security and reach while preserving the design principles you already know from on-prem networking.

And this is only the beginning. The hands-on lab that follows goes further, showing how to speed up failover beyond default BGP timers, how to use Lambda functions to react to routing events and even how to tie these deployments into a CI/CD pipeline for full automation.

Try It Yourself: Hands-On Lab

If you'd like to explore this design in action, we've created an on-demand lab where you can walk through deploying Infoblox Universal DDI with Anycast DNS on AWS Cloud WAN step by step.

Infoblox UDDI - DNS Anycast AWS with Cloud WAN Lab

This lab will give you hands-on experience with:

• Deploying NIOS-X in AWS
• Configuring Cloud WAN with Shared Services and PROD segments
• Enabling Anycast DNS and validating end-to-end queries

If you're interested in the Terraform code used to automate the setup, you can find it in the CloudWAN Terraform repository.

Coming Next: Anycast on Azure

We're just getting started. In my next blog, we'll explore how Infoblox Universal DDI and Anycast DNS can be deployed in Microsoft Azure using vWAN. The same principles apply, but the mechanics differ, and we'll dive into how Cloud WAN concepts translate into the Azure ecosystem.

Stay tuned for Part 2 in this series.