IPv6、CDN 与全球加速 - 面试题

#

★★★

1. CDN 命中率优化中缓存策略、预热（push/prefetch）、刷新（purge）与查询参数规范化如何落地

问题

CDN 命中率如何优化（缓存策略、预热、刷新、查询参数规范化）？

考察点

缓存策略：TTL、Cache-Control、缓存键
预热：push/prefetch 主动填充边缘缓存
刷新：purge 主动失效

答案

CDN 命中率优化：① 缓存策略——合理设置 Cache-Control/TTL，可缓存内容长缓存，动态内容不缓存，避免 no-store 滥用；② 缓存键——缓存键包含 host+URI+参数，规范化查询参数（忽略随机参数、统一参数顺序）减少缓存碎片；③ 预热——push/prefetch 在发布前主动把热门资源推送到边缘节点，填充缓存，避免冷启动；④ 刷新——purge 主动失效缓存（资源更新、修正 bug），配合在 URL 中加版本号/时间戳让新内容自然过期。命中率衡量回源量，命中率高回源少。查询参数规范化是降低缓存碎片的关键。

解析

命中率优化是"缓存策略 + 缓存键 + 预热 + 刷新 + 参数规范化"。参数规范化减少碎片，预热/刷新管理与失效。

示例代码

# CDN 预热（示例）
curl -X POST "https://cdn.example.com/prefetch?url=/static/app.js"
# CDN 刷新
curl -X POST "https://cdn.example.com/purge?url=/static/app.js"

#

★★★

2. CDN 工作原理与缓存命中中边缘节点、回源策略、缓存键（cache key）与 TTL 如何影响命中率与回源量

问题

CDN 的工作原理与缓存命中如何理解？边缘节点、回源、缓存键与 TTL 如何影响命中率？

考察点

边缘节点就近缓存，回源策略
缓存键决定缓存粒度
TTL 决定缓存时长

答案

CDN 把内容分发到边缘节点，用户就近从边缘节点获取，边缘节点未命中时回源到源站。缓存键（cache key）决定缓存粒度：通常包含 host+URI+参数+Vary 头，键越窄缓存越细（碎片多），键越宽复用越多（但可能串内容）。TTL 决定缓存时长，TTL 长命中率高但更新慢，TTL 短命中率低但新鲜。命中率 = 边缘命中数/总请求数，命中率高则回源量低。回源策略：边缘未命中、TTL 过期、强制刷新时回源。优化命中率要平衡缓存键粒度与 TTL，同时控制回源量。源站成本与用户延迟由命中率决定。

解析

核心是"缓存键粒度 + TTL 时长 + 边缘节点"决定命中率。命中率高回源少，需平衡新鲜度与性能。

示例代码

# 查看缓存命中与回源
curl -sI https://cdn.example.com/a.js | grep -iE "x-cache|age|via"

#

★★★

3. IPv6 规模化部署的过渡与共存策略中双栈（dual-stack）、NAT64/DNS64、隧道（6to4/ISATAP）的适用场景与运维排障差异

问题

IPv6 规模化部署的过渡与共存策略（双栈、NAT64/DNS64、隧道）如何选择？

考察点

双栈：同时运行 IPv4/IPv6，最普遍
NAT64/DNS64：IPv6-only 访问 IPv4
隧道：6to4/ISATAP 过渡

答案

IPv6 过渡与共存策略：① 双栈（dual-stack）——同时配置 IPv4 与 IPv6，v6 优先，最普遍、兼容最好，运维需同时维护两套地址与 DNS；② NAT64/DNS64——IPv6-only 客户端访问 IPv4 资源，DNS64 合成 AAAA 记录、NAT64 做地址转换，适合纯 IPv6 网络，但引入转换开销与受限；③ 隧道（6to4/ISATAP）——把 IPv6 封装在 IPv4 隧道中，用于过渡，但性能与可靠性差，已不推荐。排障差异：双栈查 A/AAAA 解析与 v4/v6 连通，NAT64 查 DNS64 合成与 NAT 转换，隧道查封装与 MTU。规模化部署以双栈为主，IPv6-only 用 NAT64。

解析

过渡策略选择是"双栈最普遍、NAT64 适合纯 v6、隧道过渡"。排障关注 v4/v6 解析、转换与封装。

示例代码

# 双栈验证
ping6 -c 3 2001:4860:4860::8888
dig AAAA example.com

#

★★★

4. 双栈下 Happy Eyeballs 的 A/AAAA 竞速机制中 IPv6 链路故障时客户端回退行为与运维验证手段

问题

双栈下 Happy Eyeballs 的 A/AAAA 竞速机制如何工作？IPv6 故障时客户端如何回退？

考察点

Happy Eyeballs 并行尝试 v6/v4，取快者
IPv6 故障时回退到 IPv4
竞速机制与回退时间

答案

Happy Eyeballs（RFC 6555）让客户端在双栈下并行发起 IPv6 与 IPv4 连接，谁先建立用谁，避免"IPv6 故障导致长时间等待"。机制：先尝试 IPv6，若在一定时间（如 250ms）内未建立则同时尝试 IPv4，取先成功的。当 IPv6 链路故障时，客户端自动回退到 IPv4，避免连接失败。运维验证：用 dig AAAA 确认 v6 配置，用 ping6/traceroute6 验证 v6 路径，用 curl -6/-4 分别测试，抓包看 v4/v6 的双连接尝试。若 v6 声明但路径故障，Happy Eyeballs 会回退 v4，但需确认 v6 不拖慢整体。验证 v6 可用性避免"v6 有记录但不可达"。

解析

Happy Eyeballs 是"并行竞速，取快者"。v6 故障自动回退 v4，避免等待。运维验证 v6 路径与竞速行为。

示例代码

curl -6 -sI https://example.com/   # 强制 v6
curl -4 -sI https://example.com/   # 强制 v4
ping6 -c 3 example.com

#

★★

5. CDN 回源与源站保护中回源 HOST/SNI 配置、回源鉴权、限流与防绕过（直连源站 IP）如何设计

问题

CDN 回源与源站保护如何设计？回源 HOST/SNI、鉴权、限流与防绕过？

考察点

回源 HOST/SNI 配置（源站虚拟主机）
回源鉴权（token/签名）
限流与源站防护

答案

CDN 回源与源站保护：① 回源 HOST/SNI——CDN 回源时设置正确的 Host 与 SNI（即使回源 IP 不同），源站虚拟主机才能正确响应；② 回源鉴权——源站用 token/签名校验回源请求（CDN 回源带签名头），防止伪造回源；③ 限流——源站对回源做限流，防 CDN 缓存失效时突发回源打爆源站；④ 防绕过——源站只允许 CDN 回源 IP 访问，屏蔽直连源站 IP（ACL/防火墙放行 CDN 回源段），防止绕过 CDN 直接访问源站。源站可加 WAF、隐藏真实 IP。设计核心是"源站只信任 CDN 回源、回源带鉴权、限流兜底"。

解析

源站保护核心是"回源鉴权 + 只放行 CDN 回源 IP + 限流 + 防绕过"。回源 HOST/SNI 保证虚拟主机正确。

示例代码

# 源站防火墙只放行 CDN 回源段
iptables -A INPUT -p tcp --dport 80 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

#

★★

6. CDN 缓存一致性中版本号、签名 URL、Cache-Control/ETag 在强一致与性能之间的取舍

问题

CDN 缓存一致性如何通过版本号、签名 URL、Cache-Control/ETag 在强一致与性能间取舍？

考察点

版本号/URL 版本化实现强一致
签名 URL 控制访问与过期
Cache-Control/ETag 校验与新鲜度

答案

CDN 缓存一致性权衡：① 版本号——在 URL 中加版本（/v1/app.js）或内容 hash（app-abc123.js），发布新版本用新 URL，天然绕过旧缓存，实现强一致；② 签名 URL——带签名与过期时间的 URL 控制访问，防止资源被篡改/附访问权；③ Cache-Control/ETag——Cache-Control: max-age 控制新鲜度，ETag/If-None-Match 做条件校验（304）确认是否更新。取舍：强一致（每次回源校验）性能差，长缓存（久不校验）性能好但更新慢。常用"版本号 + 长缓存"组合：URL 版本化 + 长 max-age，既强一致又高性能。ETag 用于动态内容的校验。

解析

取舍是"版本化 URL 实现强一致 + 长缓存实现高性能"。ETag 做条件校验，签名 URL 控访问与过期。

示例代码

# 版本化 URL + 长缓存
location ~* \.(js|css)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

#

★★

7. DNS 与 CDN 联动中 CNAME 接入、GeoDNS/ECS 就近调度、TLS 证书在 CDN 的部署与 SNI 匹配

问题

DNS 与 CDN 如何联动？CNAME 接入、GeoDNS/ECS 就近调度、TLS 证书部署与 SNI？

考察点

CNAME 接入 CDN 域名
GeoDNS/ECS 就近调度
TLS 证书在 CDN 部署与 SNI 匹配

答案

DNS 与 CDN 联动：① CNAME 接入——把业务域名 CNAME 到 CDN 提供的域名，CDN 用 DNS 解析把用户调度到就近边缘节点；② GeoDNS/ECS 就近调度——按地理位置或客户端子网（ECS）返回就近节点 IP，实现就近访问；③ TLS 证书部署——业务要在 CDN 边终终止 TLS，需把证书（含域名 SAN）部署到 CDN，CDN 按 SNI 匹配返回对应证书。联动要点：CNAME 让 CDN 接管解析，GeoDNS/ECS 决定就近，证书与 SNI 匹配决定 HTTPS 正确。运维上要保证 CNAME 正确、ECS 透传、证书 SAN 覆盖域名、SNI 匹配。

解析

联动是"CNAME 接管解析 + GeoDNS/ECS 就近 + 证书 SNI 匹配"。DNS 决定去哪，SNI 决定证书。

示例代码

# CNAME 接入
example.com CNAME example.com.cdn.cloudflare.net.

#

★★

8. IPv6 地址规划与生命周期中 GUA/ULA/链路本地地址、SLAAC 与 DHCPv6 的分配差异、临时地址与隐私扩展的影响

问题

IPv6 地址规划与生命周期（GUA/ULA/链路本地、SLAAC/DHCPv6、临时地址）如何理解？

考察点

GUA 全局单播、ULA 私有、链路本地地址
SLAAC 无状态配置 vs DHCPv6 有状态
临时地址与隐私扩展

答案

IPv6 地址类型：GUA（全局单播，公网可达）、ULA（本地唯一，类似私有）、链路本地（fe80:: 每接口自动生成）。分配方式：SLAAC（无状态，用 RA 广播前缀，主机基于前缀+接口标识自动生成地址）与 DHCPv6（有状态，服务器分配完整地址）。临时地址与隐私扩展（RFC 4941）：主机用随机临时地址发起出站连接，避免用基于 MAC 的稳定地址导致隐私泄露，但临时地址会轮换。地址生命周期：preferred → deprecated → invalid，SLAAC 地址有 preferred/deprecated 期限。运维影响：临时地址使按 IP 的访问控制/审计需注意地址变化，SLAAC 无状态需管理 RA。

解析

规划核心是"地址类型 + 分配方式 + 隐私扩展"。GUA/ULA/链路本地区分可达性，SLAAC/DHCPv6 决定分配，临时地址影响可审计性。

示例代码

ip -6 addr show eth0
# 查看临时地址与稳定地址
ip -6 addr show | grep -i temporary

#

★★

9. IPv6 安全运维中 NDP 欺骗/邻居缓存投毒防护、IPv6 ACL 与防火墙差异、RA Guard 等价防护如何落地

问题

IPv6 安全运维（NDP 欺骗、邻居缓存投毒、RA Guard）如何落地？

考察点

NDP 欺骗/邻居缓存投毒（ARP 的 IPv6 版）
防护：SEND、DAI 等价、RA Guard
IPv6 ACL 与防火墙差异

答案

IPv6 安全运维：NDP（邻居发现协议）可被欺骗，攻击者伪造 NS/NA 响应投毒邻居缓存，劫持流量（类似 ARP 欺骗）。防护：① SEND（Secure Neighbor Discovery，RFC 3971）用证书验证邻居；② NDP 检测（类似 DAI）绑定 IP-MAC；③ RA Guard——交换机上抑制/校验 RA（路由通告）报文，防止恶意 RA 使主机上网关劫持；④ IPv6 ACL 与防火墙——IPv6 用 ACL（deny/allow IPV6 报文）与防火墙（扩展头检查、片段处理），注意 IPv6 扩展头与分片需特殊处理。落地：交换机开 RA Guard/NDP 防欺骗、防火墙上限制 ICMPv6 必要类型（如只放行 echo/NS/NA）、ACL 限制管理面。IPv6 无广播，探测方式不同，防火墙需处理扩展头。

解析

IPv6 安全重点是"NDP 防欺骗 + RA Guard + 防火墙扩展头处理"。NDP 是 IPv6 的邻居解析，防护类似 ARP 但需 SEND/RA Guard。

示例代码

# 交换机启用 RA Guard（示意）
ipv6 nd raguard enable
# 查看邻居缓存
ip -6 neigh show

#

★★

10. IPv6 网络排障中 ping6/traceroute6、NDP 邻居发现异常、MTU 分片与地址解析失败如何定位

问题

IPv6 网络排障（ping6/traceroute6、NDP 异常、MTU 分片、地址解析失败）如何定位？

考察点

ping6/traceroute6 验证连通与路径
NDP 邻居发现异常（地址解析失败）
MTU 分片（IPv6 无中间分片，靠 PMTUD）

答案

IPv6 排障工具：ping6（ICMPv6 echo）、traceroute6（路径）、ip -6 neigh（邻居缓存/NDP 状态）。NDP 异常：地址解析失败时邻居缓存为 INCOMPLETE/FAILED，检查对端是否可达、RA 是否下发、链路是否正常。IPv6 无中间分片（发送方分片），依赖 PMTUD 与 ICMPv6 "Packet Too Big"，MTU 黑洞（ICMPv6 被丢弃）导致大包失败，用 ping6 -M do -s 探测。定位顺序：先 ping6 连通性 → traceroute6 路径 → ip -6 neigh 看 NDP → ping6 -M do 测 MTU。地址解析失败多为 NDP 不通或链路问题。

解析

IPv6 排障核心是"ping6/traceroute6 看连通路径、ip -6 neigh 看 NDP、ping6 -M do 测 MTU"。IPv6 无中间分片，MTU 黑洞更需注意。

示例代码

ping6 -c 3 2001:db8::1
traceroute6 2001:db8::1
ip -6 neigh show
ping6 -M do -s 1452 2001:db8::1

#

★★

11. 全球加速方案对比中 CDN、Anycast 与云厂商全球加速产品（Global Accelerator/GA）的适用场景与代价

问题

全球加速方案（CDN、Anycast、云 GA）如何对比与选择？

考察点

CDN 静态内容加速
Anycast 就近路由
云 GA（Global Accelerator）动态/全局加速

答案

全球加速方案对比：① CDN——主要加速静态/边缘缓存内容，就近缓存，适合静态资源，对动态请求优化有限；② Anycast——多节点宣告同一 IP，就近路由，适合 DNS/静态接入，但动态会话保持与全局一致性有挑战；③ 云 GA（AWS Global Accelerator/Aliyun GA）——用 Anycast 就近接入 + 私有网络回源，针对动态内容/全局应用，优化 TCP/UDP、会话保持、故障切换，代价是费用与依赖云厂商。选择：静态资源用 CDN，DNS/就近接入用 Anycast，全球动态应用/低延迟用 GA。代价：CDN 静态有余动态不足，Anycast 会话保持难，GA 贵但功能全。

解析

三方案分别侧重"静态缓存、就近路由、动态优化"。GA 结合 Anycast 与私有回源，适合全局动态应用，代价是成本。

示例代码

# AWS Global Accelerator 创建加速器（示意）
aws globalaccelerator create-accelerator --name my-ga

#

★★

12. 动态内容加速（DSA）中 TCP 优化、QUIC/HTTP3 与边缘计算如何降低跨地域动态请求延迟

问题

动态内容加速（DSA）如何通过 TCP 优化、QUIC/HTTP3 与边缘计算降低动态请求延迟？

考察点

DSA 优化动态请求（非缓存）
TCP 优化（优化窗口、快速重传、私有回源）
QUIC/HTTP3 减少握手

答案

动态内容加速（DSA）针对不可缓存的动态请求，降低跨地域延迟：① TCP 优化——优化 TCP 参数（窗口、MSS、快速重传、选择性 ACK），用私有网络/专线回源降低 RTT 与丢包；② QUIC/HTTP3——减少握手（0-RTT/1-RTT）、消除队头阻塞，提升动态请求性能；③ 边缘计算——把部分逻辑（鉴权、个性化、聚合）下放到边缘节点就近处理，减少回源与往返。DSA 组合"就近接入 + 协议优化 + 私有回源 + 边缘计算"，相比普通 CDN 更针对动态请求延迟。代价是需回源优化与边缘逻辑。

解析

DSA 是"就近接入 + TCP/QUIC 优化 + 私有回源 + 边缘计算"。针对动态请求减 RTT，非缓存。

示例代码

# HTTP/3 客户端测试
curl --http3 https://example.com/api

#

★★

13. 边缘故障与容灾中 CDN 节点故障切换、回源兜底、多 CDN 容灾与切换演练

问题

CDN 边缘故障与容灾（节点故障切换、回源兜底、多 CDN 容灾）如何设计？

考察点

边缘节点故障切换
回源兜底（源站兜底）
多 CDN 容灾与切换

答案

CDN 边缘故障与容灾：① 节点故障切换——CDN 调度系统检测节点故障，把流量调度到健康节点，DNS/调度层自动切换；② 回源兜底——边缘故障或缓存失效时回源到源站，源站高可用兜底；③ 多 CDN 容灾——部署多个 CDN 供应商，DNS 按权重/健康分配流量，单一 CDN 故障时切换其他 CDN；④ 切换演练——定期演练 DNS 切换、多 CDN 切换、回源兜底，验证容灾流程。设计核心是"调度层故障切换 + 源站兜底 + 多 CDN 冗余 + 演练"。切换后需监控流量与可用性，避免雪崩。

解析

容灾核心是"调度切换 + 回源兜底 + 多 CDN 冗余 + 演练"。切换靠 DNS 调度与健康检查，源站兜底。

示例代码

# 多 CDN 切换（DNS 权重调整）
# CDN_A 权重 0，CDN_B 权重 100

#

★★

14. 视频/大文件场景的 Range 分片请求中缓存分片策略、回源流量控制与断点续传支持如何配置

问题

视频/大文件场景的 Range 分片请求如何配置（缓存分片、回源控制、断点续传）？

考察点

Range 请求分片下载
缓存分片策略（按 Range 缓存）
回源流量控制

答案

视频/大文件场景用 Range 请求分片下载，客户端按字节范围请求。CDN/源站需支持：① 缓存分片策略——缓存按 Range 分片（如每 4MB 一片），避免整文件缓存，边缘按需缓存分片，减少回源；② 回源流量控制——分片回源，控制单次回源大小与并发，避免大文件整文件回源打爆源站；③ 断点续传支持——响应 206 Partial Content、Content-Range 头，支持客户端断点续传与拖动。配置：源站支持 Range、CDN 开分片缓存（Accept-Ranges、Content-Range）。大文件场景需平衡缓存粒度与回源流量。

解析

Range 分片核心是"按范围缓存 + 206 响应 + 回源控制"。分片缓存减少回源，断点续传依赖 Range/Content-Range。

示例代码

# 测试 Range 请求
curl -sI -H "Range: bytes=0-1023" https://cdn.example.com/video.mp4
# 期望 206 Partial Content + Content-Range

#

★

15. CDN 可观测性中边缘日志回传、命中率/回源率/边缘延迟指标、多 CDN 对比监控如何建设

问题

CDN 可观测性（边缘日志、命中率/回源率/延迟指标、多 CDN 对比）如何建设？

考察点

边缘日志回传与分析
命中率/回源率/边缘延迟指标
Cache 状态、回源量

答案

CDN 可观测性建设：① 边缘日志回传——CDN 边缘节点日志回传到中心做分析（请求、status、Cache 状态、字节）；② 核心指标——命中率（HIT/MISS）、回源率/回源量、边缘延迟、TTFB、错误率（5xx）、带宽；③ Cache 状态分布——$upstream_cache_status 的 HIT/MISS/EXPIRED 分析缓存失效原因；④ 多 CDN 对比——对多个 CDN 供应商的同一资源做拨测对比（命中率、延迟、可用性），用监控大盘统一呈现。建设用 CDN 日志服务 + 指标采集（Prometheus/Grafana）+ 拨测。指标用于优化命中率与发现异常。

解析

可观测性核心是"边缘日志 + 命中率/回源率/延迟指标 + 多 CDN 对比"。指标驱动缓存优化与故障发现。

示例代码

# 命中率指标
sum(rate(cdn_hit_requests_total[5m])) / sum(rate(cdn_requests_total[5m]))

#

★

16. 全球网络质量监控中主动拨测（TCP/HTTP）、RUM 与 BGP 路由质量监控如何组合评估用户体验

问题

全球网络质量监控（主动拨测、RUM、BGP 路由质量）如何组合评估用户体验？

考察点

主动拨测（TCP/HTTP）从探测点测
RUM 真实用户监控
BGP 路由质量监控

答案

全球网络质量监控组合：① 主动拨测（probe）——从全球节点对目标做 TCP/HTTP 探测，测连通性、延迟、丢包、可用性，主动发现故障；② RUM（真实用户监控）——采集真实用户端到端性能（页面加载、TTFB、资源耗时），反映真实体验，但样本被动；③ BGP 路由质量监控——监控 BGP 路由变化、路径抖动、前缀劫持，关联网络层问题。组合：主动拨测看"目标可达性"，RUM 看"真实体验"，BGP 看"路由层异常"。三者结合：主动拨测定位故障，RUM 量化体验，BGP 解释路由影响。评估用户体验以 RUM 为主，拨测用于主动排查。

解析

组合是"主动拨测（可达）+ RUM（真实体验）+ BGP（路由层）"。三者互补，主动定位、RUM 量化、BGP 解释。

示例代码

# 主动拨测示例
curl -w "connect:%{time_connect} ttfB:%{time_starttransfer}\n" -o /dev/null -s https://example.com

#

★

17. 双栈改造与 IPv6-only 验证中改造验证清单、应用兼容测试、故障回退方案与合规要求

问题

双栈改造与 IPv6-only 验证的清单、兼容测试、回退与合规要求是什么？

考察点

双栈改造验证清单
应用兼容测试（IPv6 硬编码、地址解析）
故障回退方案

答案

双栈改造与 IPv6-only 验证：① 改造清单——DNS 加 AAAA、应用/负载均衡/防火墙支持 IPv6、验证链路（GUA）、安全策略（ACL）更新；② 兼容测试——检查应用是否硬编码 IPv4、是否正确解析 AAAA、地址格式处理（IPv6 冒号）、日志/审计对 IPv6 支持；③ 故障回退——双栈保留 IPv4 兜底，IPv6 故障时回退 v4（Happy Eyeballs），IPv6-only 需 NAT64 兜底；④ 合规要求——国内工信部要求公网服务支持 IPv6 访问，需完成改造与备案。验证用 dig AAAA、curl -6、ping6、traceroute6。回退方案保证服务不中断。

解析

改造核心是"清单 + 兼容测试 + 回退 + 合规"。双栈保留 v4 兜底，IPv6-only 用 NAT64，合规要求工信部 IPv6。

示例代码

# 验证 AAAA 与 v6 连通
dig AAAA example.com
curl -6 -sI https://example.com/

#

★

18. 多 CDN 流量调度中按权重与健康状态分配流量、切换演练及域名与证书的一致性管理

问题

多 CDN 流量调度如何按权重与健康状态分配？切换演练与域名/证书一致性管理？

考察点

按权重分配多 CDN 流量
按健康状态自动切换
切换演练

答案

多 CDN 流量调度：① 按权重分配——DNS 按权重把流量分到多个 CDN（如 50/50 或 70/30），可逐步调整；② 按健康状态——调度系统监控各 CDN 健康（拨测/可用性），故障时自动把流量切到健康 CDN；③ 切换演练——定期演练权重调整、故障切换，验证调度与源站；④ 域名与证书一致性——各 CDN 的域名/CNAME 与证书需一致（SAN 覆盖域名、SNI 匹配），切换时证书正确。设计核心是"权重控制 + 健康切换 + 演练 + 域名证书一致"。用 DNS 调度（GSLB/GEO 或权威 DNS 权重）实现。

解析

多 CDN 调度是"权重 + 健康切换 + 演练 + 域名证书一致"。DNS 调度是载体，健康检查驱动切换。

示例代码

# DNS 权重（示意）
example.com 300 IN A 1.2.3.4   # CDN A
example.com 300 IN A 5.6.7.8   # CDN B