注意：

本教程需要访问 Oracle Cloud。要注册免费账户，请参阅开始使用 Oracle Cloud Infrastructure 免费套餐。
它对 Oracle Cloud Infrastructure 身份证明、租户和区间使用示例值。完成实验室后，请使用特定于云环境的那些值替换这些值。

在 Oracle Cloud Infrastructure 中的 BIND9 域名系统上实施高可用性

简介

OraStage 是一家能源领域的领先公司，专注于可再生能源解决方案和创新电力技术，该公司宣布了一项战略性决定，将工作负载迁移到 Oracle Cloud Infrastructure (OCI)，以提高性能、可扩展性和安全性。

考虑到 OraStage 概述的具体需求和条件，该公司需要混合域名系统 (DNS)。云中的解决方案和混合云在这里意味着除了 OCI DNS 服务之外，还要使用他们自己的 Berkeley Internet Name Domain Version 9 (BIND9) DNS 系统，他们希望构建的最终体系结构如下图所示。

OraStage DNS 要求：

该公司拥有多个内部域和子域，所有这些域都应通过其在 OCI 中的 BIND9 DNS 进行解析，其中 OraStage 将管理所有相关区域和记录。其中一个域是 orastage.com，我们将在本教程中使用它。因此，对 orastage.com 的任何查询都必须转发到其 BIND9。
在某些情况下，他们仍然需要解析 OCI 本机域（oraclevcn.com、oraclecloud.com 等），而这可以通过使用 OCI 专用 DNS 组件来实现：专用视图、转发端点和规则以及监听端点。
所有查询都必须通过 pfSense 防火墙实例进行检查。
为了避免单点故障，OraStage 计划使用另一台 DNS 服务器，并利用 OCI 负载平衡器在主 DNS 和辅助 DNS 之间分配查询。

本教程系列将逐步指导您实现上述概述的要求，从头开始构建整个解决方案。您可以从以下列表中轻松导航到每个教程：

教程 1：在 OCI 中配置 BIND9 DNS 。了解如何在计算实例上安装和配置 BIND9，使其成为 OCI 中两个测试环境的本地 DNS 服务器。这些环境将包括“前端”和“后端”服务器，每个服务器都托管在单独的分支网络中。BIND9 服务器将处理定向到 orastage.com 的所有 DNS 查询。
教程 2：在 OCI 中的 BIND9 DNS 方案上实施高可用性。本教程重点介绍添加辅助 BIND9 服务器以及配置网络负载平衡器 (Network Load Balancer，NLB) 以在两台服务器之间分配 DNS 流量。对 orastage.com 的 DNS 查询将定向到 NLB IP，这将平衡主 BIND9 服务器和辅助 BIND9 服务器之间的负载。如果一台服务器不可用，DNS 解析将继续，不会中断服务。
教程 3：使用 OCI DNS 解析本机域。仅关注特定用例，在需要解析 oraclevcn.com 和 oraclecloud.com 等原生域的情况下，我们在 OCI 中使用原生 DNS 组件。BIND9 本教程中未使用 DNS。
教程 4：使用 pfSense 防火墙向 DNS 体系结构添加安全性。侧重于在 OCI 中的中心 VCN 中安装 pfSense 防火墙，并执行所需的网络配置以通过要检查的防火墙路由所有东西流量，包括 DNS 查询（在过去的教程中完成）。

概述

如今，可靠、高效的 DNS 基础设施对于确保无缝网络运营至关重要。在第一个教程中：在 Oracle Cloud Infrastructure 中配置 BIND9 域名系统，我们已经解释了如何在 OCI 中部署和使用 BIND9，这是使用最广泛的 DNS 软件之一，它提供了强大的功能和灵活性来管理 DNS 服务。虽然单个 BIND9 服务器可以有效地处理 DNS 请求，但添加第二个 BIND9 服务器具有许多优势，可以增强网络的整体性能和可靠性。

本教程将指导您完成在 OCI 中设置辅助 BIND9 服务器和负载平衡器的过程，并重点介绍此配置的优势。通过实施此操作，您将实现：

冗余：确保 DNS 服务的连续可用性，即使主服务器发生故障也是如此。
负载平衡：在服务器之间分配 DNS 查询负载，缩短响应时间并降低超载风险。
地理分布：如果需要，将 DNS 服务器放在不同位置可以为全球用户提供更快的响应时间。
增强安全性：通过在多个服务器之间分离和保护 DNS 服务来降低风险。

OCI 网络负载平衡器

OCI 灵活网络负载平衡器 (NLB) 是一种服务，可帮助在多个后端资源之间分配传入流量。这对于管理大量流量以及确保即使一台或多台服务器发生故障，应用程序仍然可用且响应迅速特别有用。

OCI 网络负载平衡器在开放系统互连 (Open Systems Interconnection，OSI) 模型的第 3 层和第 4 层运行，处理传输控制协议 (Transmission Control Protocol，TCP)、用户数据报协议 (User Datagram Protocol，UDP) 和 Internet 控制消息协议 (Internet Control Message Protocol，ICMP) 等协议。通过高效平衡负载，它可以提高应用性能，提供高可用性，并提高系统的整体可扩展性。该服务还提供健康检查等功能来监视后端服务器的状态，从而确保流量仅传输到运行状况良好的实例。

总之，OCI 网络负载平衡器通过在多个资源之间智能地分配网络流量，在维护应用的可靠性和可扩展性方面发挥着关键作用。由于我们提到的所有优势，我们将在设置中添加一个网络负载平衡器来优化我们的 DNS 解决方案。

目标

将 OCI 网络负载平衡器和 OCI 中的辅助 BIND9 服务器无缝集成到您的网络中，确保 DNS 基础设施健壮且具有弹性。
本教程的主要目标是使 FE-VM 客户机 (fe.orastage.com) 可以查询 BE-VM (be.orastage.com)，反之亦然，通过 DNS-NLB 在 Primary-DNS (primary-dns.orastage.com) 和 Secondary-DNS (secondary-dns.orastage.com) 之间分配客户机请求来回答所有查询。

最终体系结构

先决条件

访问 OCI 租户以及管理所需网络和计算服务的权限。
基本了解 OCI 网络路由和安全及其功能：虚拟云网络 (VCN)、路由表、动态路由网关 (DRG)、安全列表、堡垒和 OCI 网络负载平衡器。
基本了解 OCI 日志记录服务。
基本了解 Ubuntu Linux 和 DNS。
确保完成第一个教程：在 Oracle Cloud Infrastructure 中配置 BIND9 域名系统，您应该已在其中构建了以下体系结构。

任务 1：预配辅助 DNS 实例并配置 BIND9

请参阅第一个教程：在 Oracle Cloud Infrastructure 中配置 BIND9 域名系统，其中任务 2 和任务 3 显示了 Primary-DNS 实例的创建和配置，配置 Secondary-DNS 时应执行相同的任务，请考虑以下信息：

实例名称将为 Secondary-DNS 。
它将驻留在与 Primary-DNS 相同的子网中，必须为其分配 IP 地址 10.0.0.20。
通过配置过程，每次提到 Primary-DNS 10.0.0.10 时，都应将其替换为 Secondary-DNS 10.0.0.20，一个示例是此实例的 FQDN 应为 secondary-dns.orastage.com。
使用相同的 SSH 密钥。
用于访问 Primary-DNS 的同一 OCI 堡垒也可用于访问 Secondary-DNS ，但可使用新会话。

在主实例和辅助实例的 /var/lib/bind/db.orastage.com 文件中，确保存在以下所有记录，以便除 FE-VM 和 BE-VM 实例外，这两台 DNS 服务器都能够相互解析。

primary-dns                 IN  A       10.0.0.10
secondary-dns               IN  A       10.0.0.20
fe                          IN  A       10.1.0.5
be                          IN  A       10.2.0.5

在此任务结束时，体系结构应如下所示：

任务 2：配置 OCI 网络负载平衡器

任务 2.1：添加详细信息

单击左上角的汉堡菜单（≡）。
1. 单击 Networking 。
2. 单击 Network load balancer 。
单击 Create network load balancer 。
1. 负载平衡器名称：输入名称。
2. 选择可见性类型：选择专用。
3. 选择网络：选择 DNS-VCN 及其专用子网，我们将在其中放置网络负载平衡器。
4. 单击下一步。

任务 2.2：配置监听程序

监听程序是负载平衡器中的一个重要组件，负责使用特定端口（例如 TCP/port 80、UDP/port 21）接收特定类型的流量并将其定向到后端服务器。在本教程中，我们希望监听程序监听端口 53 (TCP) 和 (UDP)，因为 DNS 使用这两个端口。

输入以下信息。
1. 监听程序名称：输入名称。
2. 指定监听程序处理的流量类型：选择 UDP/TCP 。
3. 指定端口：输入端口号 53 。
4. 单击下一步。

任务 2.3：选择后端集

后端集是网络负载平衡器将流量路由到的后端服务器的逻辑分组。我们这里的后端服务器为 Primary-DNS 和 Secondary-DNS 。

输入以下信息。
1. 后端集名称：输入后端集名称。
2. 单击添加后端。
3. 后端类型：选择计算实例。
4. 后端 IPv4 计算实例：选择以下两台 DNS 服务器： Primary-DNS 和 Secondary-DNS 。
5. 单击添加后端。
6. 您可以看到后端服务器已添加到集。
7. 指定健康检查策略：健康检查策略用于通过发出请求或尝试连接来验证后端服务器的可用性。网络负载平衡器按指定的常规时间间隔执行这些健康检查，使用此策略持续监视后端服务器的状态。
8. 单击下一步。

任务 2.4：复核并创建

查看所有详细信息，然后单击创建网络负载平衡器。
DNS-NLB 已创建，请记下专用 IP 地址，因为我们将在任务 3 中使用它。

任务 2.5：添加安全规则

避免运行状况检查失败并确保通信顺畅而不会中断任何流量。

在 DNS-Private-Subnet 安全列表中添加以下规则，这允许将 DNS 流量从网络负载平衡器发送到其后端。
体系结构应如下图所示。

任务 3：配置 OCI DNS 转发规则

任务 3.1：配置前端 VCN 转发规则

单击左上角的汉堡菜单（≡）。
1. 单击 Networking 。
2. 单击虚拟云网络。
单击 Frontend-VCN 。
单击 VCN 的 DNS 解析程序。
向下滚动
1. 单击规则。
2. 单击管理规则。
3. 将目标 IP 地址从 Primary-DNS IP 地址更改为在任务 2 中创建的 DNS-NLB IP 地址 (10.0.0.110)。
4. 单击保存更改。
5. 已成功更改目标 IP 地址。现在，来自 FE-VM 的所有查询都将转发到 DNS-NLB IP 地址，该地址将在主 DNS 服务器和辅助 DNS 服务器之间分配。

任务 3.2：配置后端 VCN 转发规则

单击左上角的汉堡菜单（≡）。
1. 单击 Networking 。
2. 单击虚拟云网络。
单击 Backend-VCN 。
单击 VCN 的 DNS 解析程序。
向下滚动。
1. 单击规则。
2. 单击管理规则。
3. 将目标 IP 地址从 Primary-DNS IP 地址更改为在任务 2 中创建的 DNS-NLB IP 地址 (10.0.0.110)。
4. 单击保存更改。
5. 已成功更改目标 IP 地址。现在，来自 BE-VM 的所有查询都将转发到 DNS-NLB IP 地址，该地址将在主 DNS 服务器和辅助 DNS 服务器之间分配。

任务 4：测试和验证

先决条件

启用日志：要验证流量流，我们将启用子网流日志，以便我们监视和跟踪进入或离开特定子网的网络流量。这些日志捕获有关网络通信的详细信息，例如源和目标 IP 地址、端口号以及传输的数据量。要启用日志，请执行以下步骤：
1. 转到 DNS-VCN 专用子网，其中 Primary-DNS 、 Secondary-DNS 和 DNS-NLB 驻留。
2. 单击日志。
3. 选择启用日志。
有关日志以及如何在 OCI 中使用日志的详细信息，请参阅
- VCN 流日志。
- VCN 流日志的详细信息 —了解如何读取日志的内容。
- 遵循 OCI 中的 Hub 和 Spoke VCN 路由体系结构中的包 —一个有用的教程，介绍了如何使用多种方法（例如防火墙数据包捕获、子网日志和 TCPdump）跟踪 OCI 环境中的网络数据包。跟随任务 6 和任务 13。
  - 任务 6：在 Spoke A 专用子网上启用日志记录（所有日志）。
  - 任务 13：查看所有日志记录点和数据包捕获并遵循路径 - 日志记录点 B。

现在，将记录此子网的所有入站和出站流量。

测试场景 1：当辅助 DNS 关闭时，主 DNS 响应 FE-VM 查询

如果 Secondary-DNS 中出现故障，我们需要确保 Primary-DNS 响应来自 FE-VM 的查询，因为 DNS-NLB 正在将流量定向到它。

下图展示了我们想要实现的测试场景。
当前，所有实例已启动且正在运行。首先，关闭 Secondary-DNS 实例。单击左上角的汉堡菜单（≡）。
1. 单击计算。
2. 单击实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击停止。
4. 单击停止。
5. 实例现在处于已停止状态。
访问 FE-VM 并通过运行查询执行测试。为此，我们将使用 OCI 堡垒服务。单击左上角的汉堡菜单（≡）。
1. 单击身份和安全。
2. 单击堡垒。
单击 FEBastion 。
单击创建会话。
输入以下信息。
1. 会话类型：选择托管 SSH 会话。
2. 会话名称：输入会话的名称。
3. 用户名：输入用户名。对于 Oracle Linux 实例，默认用户名是 opc 。
4. 计算实例：选择 FE-VM 实例。
5. 粘贴教程 1 中生成的相同公共密钥：任务 2.1：生成 SSH 密钥对。
6. 单击创建会话。

创建会话后，单击三个点和复制 SSH 命令。

命令应如下所示：

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aiaxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

打开 OCI Cloud Shell。
1. 使用 cd .ssh 命令导航到 .ssh 目录。
2. 粘贴 SSH 命令。确保将 <privateKey> 替换为私钥文件名 id_rsa。
3. 输入 yes 。
已成功注册。现在，使用 host 命令执行从 FE-VM 到 be.orastage.com 的测试查询。验证查询是否成功并收到响应。
我们知道只有一个健康的后端服务器来处理请求，即 Primary-DNS 。在这里，我们将验证 DNS 查询的流程，看看哪些服务器使用 OCI 子网日志响应了该查询。
1. 单击日志。
2. 请求从位于与 FE-VM 相同的子网中的转发端点 (10.1.0.6) 转发到 DNS-VCN 中的 NLB IP 地址 (10.0.0.110)。
3. 然后，从 NLB IP 地址 (10.0.0.110) 将请求发送到 Primary-DNS (10.0.0.10)。
测试成功。如果 Secondary-DNS 发生故障， Primary-DNS 能够处理 DNS 查询。

测试场景 2：主 DNS 关闭时，辅助 DNS 响应 FE-VM 查询

如果 Primary-DNS 中出现故障，我们需要确保 Secondary-DNS 响应来自 FE-VM 的查询，因为 DNS-NLB 正在将流量定向到它。

下图展示了我们想要实现的测试场景。
首先，关闭 Primary-DNS 实例。单击左上角的汉堡菜单（≡）。
1. 单击计算。
2. 单击实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击停止。
4. 单击停止。
5. 实例现在处于已停止状态。
启动 Secondary-DNS 实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击开始。
4. 单击开始。
5. 实例现在处于正在运行状态。
接下来，我们将访问 FE-VM 并通过运行查询执行测试。为此，我们将使用 OCI 堡垒服务。单击左上角的汉堡菜单（≡）。
1. 单击身份和安全。
2. 单击堡垒。
单击 FEBastion 。
单击创建会话。
输入以下信息。
1. 会话类型：选择托管 SSH 会话。
2. 会话名称：输入会话的名称。
3. 用户名：输入用户名。对于 Oracle Linux 实例，默认用户名是 opc 。
4. 计算实例：选择 FE-VM 实例。
5. 粘贴教程 1 中生成的相同公共密钥：任务 2.1：生成 SSH 密钥对。
6. 单击创建会话。

创建会话后，单击三个点和复制 SSH 命令。

命令应如下所示：

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxzo2q7dka@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.1.0.5

打开 OCI Cloud Shell。
1. 使用 cd .ssh 命令导航到 .ssh 目录。
2. 粘贴 SSH 命令。确保将 <privateKey> 替换为私钥文件名 id_rsa。
3. 输入 yes 。
已成功注册。现在，使用 host 命令执行从 FE-VM 到 be.orastage.com 的测试查询。验证查询是否成功并收到响应。
我们知道只有一个健康的后端服务器来处理请求，即 Secondary-DNS 。在这里，我们将验证 DNS 查询的流程，看看哪些服务器使用 OCI 子网日志响应了该查询。
1. 单击日志。
2. 请求从位于与 FE-VM 相同的子网中的转发端点 (10.1.0.6) 转发到 DNS-VCN 中的 NLB IP 地址 (10.0.0.110)。
3. 然后，从 NLB (10.0.0.110) 将请求发送到 Secondary-DNS (10.0.0.20)。
测试成功。Secondary-DNS 能够在 Primary-DNS 发生故障时处理 DNS 查询。

测试场景 3：当辅助 DNS 关闭时，主 DNS 响应 BE-VM 查询

如果 Secondary-DNS 中出现故障，我们需要确保 Primary-DNS 响应来自 BE-VM 的查询，因为 DNS-NLB 正在将流量定向到它。

下图展示了我们想要实现的测试场景。
当前，所有实例已启动且正在运行。首先，关闭 Secondary-DNS 实例。单击左上角的汉堡菜单（≡）。
1. 单击计算。
2. 单击实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击停止。
4. 单击停止。
5. 实例现在处于已停止状态。
接下来，我们将访问 BE-VM 并通过运行查询执行测试。为此，我们将使用 OCI 堡垒服务。单击左上角的汉堡菜单（≡）。
1. 单击身份和安全。
2. 单击堡垒。
单击 BEBastion 。
单击创建会话。
输入以下信息。
1. 会话类型：选择托管 SSH 会话。
2. 会话名称：输入会话的名称。
3. 用户名：输入用户名。对于 Oracle Linux 实例，默认用户名是 opc 。
4. 计算实例：选择 BE-VM 实例。
5. 粘贴教程 1 中生成的相同公共密钥：任务 2.1：生成 SSH 密钥对。
6. 单击创建会话。

创建会话后，单击三个点和复制 SSH 命令。

命令应如下所示：

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5axxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxuk7pafla@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

打开 OCI Cloud Shell。
1. 使用 cd .ssh 命令导航到 .ssh 目录。
2. 粘贴 SSH 命令。确保将 <privateKey> 替换为私钥文件名 id_rsa。
3. 输入 yes 。
已成功注册。现在，使用 host 命令执行从 BE-VM 到 fe.orastage.com 的测试查询。验证查询是否成功并收到响应。
我们知道只有一个健康的后端服务器来处理请求，即 Primary-DNS 。在这里，我们将验证 DNS 查询的流程，看看哪些服务器使用 OCI 子网日志响应了该查询。
1. 单击日志。
2. 请求从位于与 BE-VM 相同的子网中的转发端点 (10.2.0.6) 转发到 DNS-VCN 中的 NLB IP 地址 (10.0.0.110)。
3. 然后，从 NLB (10.0.0.110) 中，将请求发送到 Primary-DNS (10.0.0.10)。
测试成功。如果 Secondary-DNS 发生故障， Primary-DNS 能够处理 DNS 查询。

测试场景 4：主 DNS 关闭时，辅助 DNS 响应 BE-VM 查询

如果 Primary-DNS 中出现故障，我们需要确保 Secondary-DNS 响应来自 BE-VM 的查询，因为 DNS-NLB 正在将流量定向到它。

下图展示了我们想要实现的测试场景。
首先，关闭 Primary-DNS 实例。单击左上角的汉堡菜单（≡）。
1. 单击计算。
2. 单击实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击停止。
4. 单击停止。
5. 实例现在处于已停止状态。
启动 Secondary-DNS 实例。
1. 选中实例旁边的复选框。
2. 单击操作。
3. 单击开始。
4. 单击开始。
5. 实例现在处于正在运行状态。
接下来，我们将访问 BE-VM 并通过运行查询执行测试。为此，我们将使用 OCI 堡垒服务。单击左上角的汉堡菜单（≡）。
1. 单击身份和安全。
2. 单击堡垒。
单击 BEBastion 。
单击创建会话。
输入以下信息。
1. 会话类型：选择托管 SSH 会话。
2. 会话名称：输入会话的名称。
3. 用户名：输入用户名。对于 Oracle Linux 实例，默认用户名是 opc 。
4. 计算实例：选择 BE-VM 实例。
5. 粘贴教程 1 中生成的相同公共密钥：任务 2.1：生成 SSH 密钥对。
6. 单击创建会话。

创建会话后，单击三个点和复制 SSH 命令。

命令应如下所示：

ssh -i <privateKey> -o ProxyCommand="ssh -i <privateKey> -W %h:%p -p 22 ocid1.bastionsession.oc1.eu-milan-1.amaaaaaaldij5aia73xcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa@host.bastion.eu-milan-1.oci.oraclecloud.com" -p 22 opc@10.2.0.5

打开 OCI Cloud Shell。
1. 使用 cd .ssh 命令导航到 .ssh 目录。
2. 粘贴 SSH 命令。确保将 <privateKey> 替换为私钥文件名 id_rsa。
3. 输入 yes 。
已成功注册。现在，使用 host 命令执行从 BE-VM 到 fe.orastage.com 的测试查询。验证查询是否成功并收到响应。
我们知道只有一个健康的后端服务器来处理请求，即 Secondary-DNS 。在这里，我们将验证 DNS 查询的流程，看看哪些服务器使用 OCI 子网日志响应了该查询。
1. 单击日志。
2. 请求从位于与 BE-VM 相同的子网中的转发端点 (10.2.0.6) 转发到 DNS-VCN 中的 NLB IP 地址 (10.0.0.110)。
3. 然后，从 NLB (10.0.0.110) 将请求发送到 Secondary-DNS (10.0.0.20)。
测试成功。如果 Primary-DNS 发生故障， Secondary-DNS 能够处理 DNS 查询。

后续步骤

在本教程中，我们通过集成 OCI 网络负载平衡器和辅助 DNS 服务器来增强在 OCI 中设置的简单客户端服务器 BIND9 DNS，以确保在主服务器发生故障时持续提供服务可用性。

到目前为止，我们已经开发了一个高性能和可靠的 DNS 架构，专门用于处理 orastage.com 域查询。但是，OraStage 公司还要求解析 OCI 本机域名，例如 oraclevcn.com 和 oraclecloud.com，为此需要执行其他步骤。在接下来的教程使用 OCI DNS 解析本机域中，我们将演示如何实现此配置。

确认

作者 — Anas abdallah（云网络专家）

在 Oracle Cloud Infrastructure 中的 BIND9 域名系统上实施高可用性

简介

概述

目标

先决条件

任务 1：预配辅助 DNS 实例并配置 BIND9

任务 2：配置 OCI 网络负载平衡器

任务 2.1：添加详细信息

任务 2.2：配置监听程序

任务 2.3：选择后端集

任务 2.4：复核并创建

任务 2.5：添加安全规则

任务 3：配置 OCI DNS 转发规则

任务 3.1：配置前端 VCN 转发规则

任务 3.2：配置后端 VCN 转发规则

任务 4：测试和验证

测试场景 1：当辅助 DNS 关闭时，主 DNS 响应 FE-VM 查询

测试场景 2：主 DNS 关闭时，辅助 DNS 响应 FE-VM 查询

测试场景 3：当辅助 DNS 关闭时，主 DNS 响应 BE-VM 查询

测试场景 4：主 DNS 关闭时，辅助 DNS 响应 BE-VM 查询

后续步骤

确认

更多学习资源