我们有一个 DNS 区域 example.com，它是水平分割（内部与公共）的。例如，内部区域具有 的私有 IP 地址，app.example.com而公共区域具有同名的公有 IP 地址app.example.com。我们最近将公有 DNS 切换到 Cloudflare，我想开始将它们用作 CDN/代理，但是在投入生产之前，我需要让 QA 团队审核这些更改。我们需要能够在app.example.com办公室内使用内部版本的 DNS 区域时访问 的公有 IP。此 DNS 会将人们发送到内部 IP，因此他们将无法测试 Cloudflare。修改客户端的 HOSTS 文件可以工作，但这很麻烦，我无法使用公有 IP 地址更新内部 DNS。想知道是否有人能想到其他选择？
答案1
这个答案提出了一个可能的选择，当然也是一个有争议的选择。
放弃这种水平分割 DNS 想法 (1) 趁你还能放弃的时候，以及 (2) 趁你暂时有“业务”理由放弃它的时候。随着组织的发展，不明确的 DNS 配置会越来越困扰你，但它与你的环境结合得越紧密，就越难摆脱它。
使用IP层来解决IP层的问题。
优点：
- 减少人类用户的困惑
- 无论客户端位于网络中的哪个位置，DNS名称的解析都是相同的
- 轻松合并外部网络与自己的 DNS 区域
- 当你需要性能时，你可以使用
app.in.example.com并且知道它会解析为私有 IP
缺点：
- 你会遇到“发夹式 NAT”的情况 - 谷歌搜索
- 路由器将传递两倍以上的数据包（针对发夹式 NAT 情况）
- 延迟增加微秒（针对发夹式 NAT 情况）
- 对于发夹情况，你的 DNAT-from-public 服务器将在匿名源 IP 下看到自己的子网
- 这是因为你为他的整个 IP 子网设置了 SNAT
- 例如服务器
192.168.8.8将看到用户192.168.8.9在netstat192.168.8.1 - 但同一台服务器将
192.168.1.3看到192.168.1.3 - 它将把互联网用户
9.9.9.9视为9.9.9.9 - 它很容易修复，因为 DNAT-from-public 服务器通常是反向代理，并且可以轻松地放在远离用户的单独子网中（换句话说：revproxies 通常位于 DMZ 中）