使用Infoblox Universal DDI™和AWS Cloud WAN在AWS中实现Anycast DNS

本文详细介绍了如何在AWS多区域环境中部署Infoblox Universal DDI™和NIOS-X，通过AWS Cloud WAN实现全局Anycast DNS架构，包括技术部署步骤、网络策略配置和验证方法。

在AWS中使用Infoblox Universal DDI™和AWS Cloud WAN交付Anycast DNS

引言

在过去几个月中，与在多个区域和混合云中运行工作负载的企业进行对话时，一个主题不断出现：DNS问题持续困扰着他们。每个人都希望获得相同的目标：一致、弹性的DNS服务，在任何地方都能"正常工作"。但是，当开始涉及多云拓扑、全球覆盖和快速故障转移需求时，Anycast DNS迅速从"锦上添花"变成了"难以管理"。

这就是本文的开始。在本博客中，我们将详细介绍如何将Infoblox Universal DDI™和NIOS-X原生部署在AWS中，与Cloud WAN集成并通过Anycast DNS扩展以提供全局可达性。关键在于将Infoblox的集中管理和自动化与AWS的全球网络结构相结合，从而更快地上线应用、减少运营开销，并提供既高可用又云就绪的DNS结构。

我们构建的实验室展示了一个实用设计，包含两个AWS区域：法兰克福和巴黎。每个区域都有共享服务和生产虚拟私有云（VPC），其中Infoblox NIOS-X设备提供Anycast DNS。AWS Cloud WAN将这些区域连接在一起，优化路由并确保DNS请求在需要时无缝故障转移。

图1. 通过AWS Cloud WAN互联的法兰克福（eu-central-1）和巴黎（eu-west-3）之间的高层拓扑

在AWS中部署Infoblox NIOS-X

该设计的基础是在跨区域的共享服务VPC中部署Infoblox NIOS-X设备。这些设备充当环境的DNS引擎，并通过Universal DDI门户进行集中管理。部署利用标准的AWS EC2工作流程以及Infoblox加入令牌实现无缝上线。

部署步骤：

  1. 使用AWS Marketplace中Infoblox提供的AMI在每个目标区域启动NIOS-X实例
  2. 在实例初始化期间应用加入令牌，使设备自动注册到Universal DDI门户
  3. 通过在Universal DDI门户的Configure → Servers中确认新的NIOS-X实例出现来验证上线

虽然本博客重点放在架构上，但后续的实验室将更深入。在那里，我们将展示如何将相同的部署工作流程集成到持续集成（CI）/持续交付（CD）管道中，以便作为基础设施即代码流程的一部分，NIOS-X设备可以自动启动、注册和配置。

图2. Universal DDI门户显示NIOS-X设备已注册并在线（Configure → Servers）

重要性说明：这种自动上线工作流程消除了手动注册步骤，确保新设备在跨区域的Universal DDI中一致可见，减少部署时间和人为错误。

AWS基础设施设置

在每个AWS区域中，我们配置了两个不同的VPC：

  • 共享服务VPC：托管Infoblox NIOS-X设备和其他基础架构服务
  • 生产VPC：托管消耗DNS和其他共享服务的应用工作负载

这种分离并不新鲜。这是一个经典的网络设计原则。在数据中心中，我们总是划分出共享基础设施域：DNS、DHCP、Active Directory、日志记录、PKI、监控和其他核心服务在那里运行，与各个应用环境解耦。通过虚拟路由和转发（VRF）分离和路由泄漏来强制执行连接性，确保可达性同时保持生命周期干净隔离。

在云中，相同的逻辑适用，只是机制发生了变化。不再使用VRF和防火墙，而是使用VPC、对等连接、Transit Gateway、Cloud WAN和云服务提供商（CSP）提供的安全构造。架构模式保持不变：共享基础设施提供一致性，而应用环境通过定义明确的安全路径消耗这些服务。

作为网络架构师，我们需要认识到向云的迁移并不会消除这些设计规则，只是将它们转化为新的构造。在全球层面，AWS Cloud WAN将这些共享基础设施缝合在一起，提供使Anycast DNS等服务随处可用的骨干网。

图3. 在网络管理器中创建AWS全球网络

图4. 创建核心网络并选择区域/边缘/段

重要性说明：早期定义边缘位置和段提供了一个可跨多个区域扩展的结构化骨干网，并简化了流量分离。

附加VPC和连接附件

在Cloud WAN骨干网就位后，下一步是附加区域资源，以便流量实际上可以跨全球结构流动。附件充当VPC、设备和Cloud WAN核心网络之间的集成点，实现端到端的路由一致性和策略执行。

执行的步骤：

  1. VPC附件：将共享服务和生产VPC连接到Cloud WAN，启用DNS支持以确保查询通过骨干网路由
  2. 连接附件：为Infoblox NIOS-X设备建立连接附件，使用无隧道边界网关协议（BGP）（无额外封装）
  3. 连接对等体：为每个NIOS-X实例配置BGP对等体及其分配的IP地址和自治系统号码（ASN），建立到Cloud WAN结构的动态路由
  4. VPC路由表：更新以通过Cloud WAN转发VPC间流量和Anycast VIP（10.10.10.10），确保任何区域中的应用都能一致地访问DNS

设计要点：为什么使用无隧道BGP？

通过使用无隧道模式，路由得以简化——没有通用路由封装（GRE）或IPsec封装开销，更少的移动部件和操作复杂性。故障排除更直接，因为通过Cloud WAN交换的路由作为原生BGP会话可见，没有额外的封装层。结果是更清晰、更易于扩展和操作的设计。

图5. 创建VPC附件并启用DNS支持

图6. 创建连接附件（NO_ENCAP/无隧道）

图7. 连接附件BGP对等体配置（对等体IP、ASN）

图8. VPC路由表（已更新）

重要性说明：同时使用VPC和连接附件允许应用VPC和DNS基础设施一致地集成，同时使NIOS-X能够通过BGP向Cloud WAN通告Anycast IP。

定义AWS Cloud WAN策略

在VPC和连接附件就位后，下一步是应用Cloud WAN策略。策略是控制平面逻辑，决定：

  • 附件如何分组到段（类似于传统网络中的VRF）
  • 路由信息如何在那些段之间共享
  • 哪些路径在骨干网上是首选的或负载均衡的

将Cloud WAN策略视为全球网络的"意图文件"——它们抽象了每个VPC的路由复杂性，而是让您用段和共享规则来描述连接性。

以下是我们实验室中应用的完整策略：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144

{ 
  "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" 
      } 
    } 
  ] 
}

策略分解：

  • 核心配置：定义ASN范围、连接对等体的内部CIDR块、边缘位置和两个段（共享服务、生产）
  • 段操作：允许共享服务和生产交换路由以实现可达性
  • 规则100：关联共享服务VPC（vpc-024743b1d00009219，vpc-02add70a8637c5acf）
  • 规则110：关联生产VPC（vpc-098ea96bb41ecbfa7，vpc-0fb8ce0b7277bcaec）
  • 规则120：将法兰克福NIOS-X连接附件（attachment-060212557d5e7d06b）映射到共享服务
  • 规则125：将巴黎NIOS-X连接附件（attachment-00a26092ee329caeb）映射到共享服务

重要性说明：VPC动态关联到正确的段，DNS设备始终锚定在共享服务中，段共享路由以实现无缝DNS解析。

图9. AWS网络管理器策略视图显示应用的策略/版本

在Infoblox中配置Anycast DNS

在连接就位后，我们在Universal DDI中启用了Anycast DNS。

在Infoblox门户中为所有NIOS-X设备执行的步骤：

  1. 在Configure → Service Deployment → Protocol Service下启用DNS服务
  2. 在Configure → Networking → Anycast下创建Anycast配置
  3. 创建Anycast服务并将其与DNS关联
  4. 配置BGP对等体以将Anycast路由通告到Cloud WAN

图10. Universal DDI—启用DNS服务（Configure → Service Deployment → Protocol Service → Create Service → DNS）

图11. Universal DDI—Anycast配置（Networking → Anycast → Create Anycast Configuration）

图12. Universal DDI—Anycast服务创建（Configure → Service Deployment → Protocol Service → Create Service → Anycast）

图13. Universal DDI—Anycast服务的BGP对等体配置

图14. Universal DDI—Anycast IP显示绿色/活动

我们在本博客中没有涵盖，但后续的动手实验会更深入。在那里，您将看到如何使Anycast DNS故障转移更快，而不受默认BGP控制平面计时器的限制。在实验室中，我们展示了如何使用AWS Lambda监听事件，如BGP会话抖动或路由从路由表中消失——并实时响应。

验证

我们端到端地验证了两个区域的设计。

执行的检查：

  1. 从Cloud WAN学习的路由在Cloud WAN路由表中可见
  2. NIOS-X和Cloud WAN连接对等体之间的BGP会话为UP状态
  3. Anycast IP在Universal DDI中显示为活动状态
  4. 来自两个区域的EC2通过Anycast进行查询

图15. 从Cloud WAN学习的路由在Cloud WAN路由表中可见

图16. AWS—连接对等体状态显示UP（每个区域）

图17. 生产中的EC2（法兰克福）—通过Anycast IP解析的dig输出

图18. 生产中的EC2（巴黎）—通过Anycast IP解析的dig输出

重要性说明：验证证明Anycast DNS在跨区域间无缝工作——路由由Cloud WAN处理，弹性由BGP提供。

结论

本实验室展示了如何将Universal DDI和NIOS-X部署在AWS中，以在多个区域之间提供基于Anycast的弹性DNS结构。通过与AWS Cloud WAN集成，企业获得了一个单一的策略驱动骨干网，使DNS高度可用、全局可达且更易于大规模操作。

您获得的不仅仅是DNS解析——它是一种云原生架构，与企业的敏捷性、安全性和覆盖范围要求保持一致，同时保留了您从本地网络已经熟知的设计原则。

而这仅仅是个开始。后续的动手实验将更进一步，展示如何加速故障转移超越默认BGP计时器，如何使用Lambda函数响应路由事件，甚至如何将这些部署与CI/CD管道绑定以实现完全自动化。

亲自尝试：动手实验

如果您想在实践中探索此设计，我们创建了一个按需实验室，您可以逐步完成在AWS Cloud WAN上部署Infoblox Universal DDI与Anycast DNS的过程。

Infoblox UDDI - DNS Anycast AWS with Cloud WAN Lab

本实验将为您提供以下方面的实践经验：

  • 在AWS中部署NIOS-X
  • 使用共享服务和生产段配置Cloud WAN
  • 启用Anycast DNS并验证端到端查询

如果您对用于自动化设置的Terraform代码感兴趣，可以在CloudWAN Terraform存储库中找到它。

即将推出：Azure上的Anycast

我们才刚刚开始。在我的下一篇博客中，我们将探讨如何使用vWAN在Microsoft Azure中部署Infoblox Universal DDI和Anycast DNS。相同的原则适用，但机制不同，我们将深入探讨Cloud WAN概念如何转化为Azure生态系统。

请继续关注本系列的第2部分。

comments powered by Disqus
© 2020 - 2025 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次