私有 DNS 在 VPC 内可用，但通过 VPN 不可用
在 EC2 内可解析、但通过 VPN 无法解析的私有名称，属于解析器路径问题。修改区域记录之前，先读懂故障的形态。
私有名称可以从 EC2 实例解析，但从通过 VPN 连接的笔记本却解析不了，而区域在控制台里看起来是正确的。第一反应是去修改记录，而这几乎从来不是问题所在。记录正在回答某个人；它只是没有回答你的笔记本。两个调用方的差别在于它们询问哪个解析器，以及该解析器是否有受支持的路径进入 VPC 的 DNS 视图。
我先证明记录确实存在，剩下的时间都花在查询路径上。这是两套系统，失败时的形态并不相同。
在改动任何东西之前，先读懂故障的形态
三种结果意味着三件不同的事，而一条查询就能把它们区分开：用客户端实际使用的解析器对该名称执行 dig。
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
超时是关于网络的陈述。NXDOMAIN 是关于 DNS 视图的陈述。公开答案是关于策略的陈述。在有超时的情况下修改区域记录，会丢掉这个案例里唯一有用的证据。
为什么 VPC 的加二地址不是远程解析器
CIDR 加二地址是 VPC 内部资源的本地服务。AWS 的文档指出，把来自本地网络或另一个 VPC 的 DNS 服务器的查询直接转发到该地址并不受支持，还可能产生不稳定的结果。
这并不意味着实验从不会看起来可用。它意味着这种行为不是可以写进帮助台脚本的契约。受支持的方向是入站 Resolver 端点：位于你的 VPC 内、可从你控制的网络访问、接受来自 AWS 之外查询的一对地址。
按失败得最干净的顺序来搭建路径
必须存在三个跳点，每个都有自己的失败方式。
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses转发器需要一条通过 VPN 到达端点地址的路由，回程路径也必须可用。对于端口 53 上的常规 DNS，端点通过 UDP 和 TCP 应答，所以两种协议都要放行，而且两者都必须能通过中途的任何有状态检查。
然后单独检查 DNS 视图。私有托管区域只对它关联的 VPC 可见，或者通过刻意的共享安排可见。一个可达的端点本身，并不会让每个私有区域在其解析上下文中都变得可解析。
出站端点服务于相反的方向，不会回答从你的笔记本进来的查询。
从两端分别验证
先从客户端向转发器查询，再从转发器向端点查询。如果客户端失败而转发器成功，缺口就在这两者之间。
如果两端都失败，就看端点上的安全策略，以及它实际看到的源地址。位于 NAT 之后的转发器呈现的是 NAT 地址而不是笔记本的 VPN 地址，仅这一点差别就足以让查询被丢弃。如果两端都成功但应用仍然失败，应用可能使用的解析器与你测试的不是同一个。
有意把公有和私有命名空间分开。Split DNS 是你配置的策略，而不是某次查询碰巧返回数据的副作用。
我不会做的事
我不会加一条让单次查询可用的 NAT 规则，然后把它称为设计。
我不会因为一次测试曾经返回过记录，就把所有远程客户端都指向加二地址。也不会在只需要一个转发器访问时，把端点的安全策略放宽到整个 VPN 地址池。如果组织已经在 VPC 内运行经批准的转发器，先读那份设计，因为你添加的第二个端点，正是没有人记录的那个。