我们正在使用 GCP 和 Cloud DNS 来管理我们的域，并且我正在尝试解决以下用例：
- 对于数据库之类的内容拥有私人记录，这些记录只能在公司网络（我们的 VPC）内解析。
- 使用私有 IP 覆盖公共记录，以便在公司网络内进行替代路由。
- 能够发出 DNS01 质询并在我们的网络内公开解析记录。我们需要此功能是因为 cert-manager 的工作方式（我们使用它通过 letsencrypt 颁发证书）。
我曾尝试使用公共和私有区域（又名分割水平 DNS）来解决这个问题，但是，这个解决方案只能解决用例 1 和 2。并且，只有当我们确保私有区域拥有公共区域中所有记录的副本时（如果没有私有对应项），它才能解决用例 2。
此解决方案无法满足用例 3，因为我们的 cert-manager 服务器在公共区域中创建记录，然后无法在公共区域中解析它们。由于我们的设置的特殊性，通过某些本地配置自定义 cert-manager 来解析两个区域并不理想。在两个区域上创建记录也很困难，因此这也不是理想的解决方案。
我希望私有区域在特定请求没有记录的情况下将请求转发到公共区域。有没有办法做到这一点，特别是使用 GCP Cloud DNS？
理想
nslookup -> private zone -> public zone
目前我们有
nslookup -> private zone -> error (NXDOMAIN) if no record
例如，
# While on my laptop
> nslookup ws1.example.com
...
Name: ws1.example.com
Address: 34.111.111.111 # Public IP for web server
# While on the GCP network
> nslookup db.example.com
...
Name: db.example.com
Address: 10.10.0.2 # Private IP for a database
> nslookup ws1.example.com
...
Name: ws1.example.com
Address: 10.0.0.10 # Private IP (from private zone) for web server
这对于用例 1 和 2 来说工作正常，但是当我们尝试解析仅存在于公共区域的记录时......
# While on my laptop
> nslookup ws1.example.com
...
Name: ws1.example.com
Address: 34.111.111.111 # Public IP for web server
> nslookup ws2.example.com # We only have this record in the public zone
...
Name: ws2.example.com
Address: 34.111.111.112 # Public IP for another web server
# While in the GCP VPC
> nslookup ws1.example.com
...
Name: ws1.example.com
Address: 10.0.0.1 # Private IP (override) for web server
> nslookup ws2.example.com # We only have this record in the public zone
...
** server can't find ws2.example.com: NXDOMAIN # Fails to resolve. Should look at private then public zone and resolve to 34.111.111.112.
有什么建议么？
作为一种解决方法，目前，我们已切换为使用 HTTP01 挑战来进行证书管理器，但如果可能的话，我们更愿意使用 DNS01。
答案1
如果示例.com既是私有区域又是公共区域，那么您必须拥有以下资源记录：ws2在公共和私有区域中均如此。没有从私有到公共的故障转移。每个区域都必须权威性。
理解问题的关键：查询是在示例.com。如果区域返回 NXDOMAIN，则查询结束。DNS 不会转移到另一台服务器来查询不同的答案。
答案2
我知道这是一个老问题，上面的 John Hanley 已经很好地回答过了，但我还是会在这里发布我们的解决方案，希望它能对其他人有所帮助。
我们最近遇到了与水平分割 DNS 类似的问题，并通过实现 Eventarc 触发的云功能解决了该问题，该功能将公共区域中的所有更改复制到私有区域，因此我们不必手动执行此操作。
免责声明：我们的解决方案可能不适用于 cert-manager 用例，但应该足以满足大多数其他用例的要求。