![后缀与 route53 中的子区域匹配的记录的 DNS 解析行为](https://linux22.com/image/792804/%E5%90%8E%E7%BC%80%E4%B8%8E%20route53%20%E4%B8%AD%E7%9A%84%E5%AD%90%E5%8C%BA%E5%9F%9F%E5%8C%B9%E9%85%8D%E7%9A%84%E8%AE%B0%E5%BD%95%E7%9A%84%20DNS%20%E8%A7%A3%E6%9E%90%E8%A1%8C%E4%B8%BA.png)
假设我example.com
在 route53 中有一个区域,其中包含以下记录:
foo.sub.example.com A 1.2.3.4
在同一个example.com
区域中,我还有一个委派,因此sub.example.com
子区域有 NS 记录。该sub.example.com
区域不包含foo.sub.example.com
A 记录;父区域包含。
现在,我注意到,使用此设置,请求会foo.sub.example.com A
失败,因为(从中可以看出dig +trace
)解析过程最终会搜索子区域,而不是停在记录确实存在的父区域。
根据我的研究,我找不到强制这种行为的参考、RFC 或标准,但它似乎是这样运作的。
所以问题是:上述行为是预期/标准的还是仅仅是 route53 的事情,如果是前者,那么它在哪里记录?
答案1
这是标准未指定的行为。
foo.sub.example.com
属于胶水数据的更广泛定义(见RFC 8499和RFC 2181),但特定行为仅针对仅包含相关记录的狭义定义进行定义NS
。至于其他记录,服务器既不需要也不被禁止在答复中发送此类记录。许多流行的服务器不发送,但有些会发送。我检查了 Bind、PowerDNS 和 Route53 - 它们不会发送。我还检查了一个区域托管提供商 DNS 解决方案(可能基于 TinyDNS),他们确实会发送此类记录。还有一个例子这个问题。
如果服务器发送了胶水记录,那么解析器会很乐意接受它,并且不会联系权威服务器(如RFC 2181),但这样的记录并不存在,这可能会导致一些意外。我使用标准进行了测试systemd-resolved
。
结论——避免这样的记录,不要依赖现有的行为。
答案2
是的,这是标准行为。通过将区域委托sub.example.com
给指定的名称服务器,您将名称及其以下所有名称的全部权限移交sub.example.com
给上述名称服务器。
该规则的唯一例外是所谓的glue
记录,它们为位于委托区域的名称服务器提供地址提示。请注意,这些只是提示,一旦解析到达权威名称服务器,它应该用来自区域的数据替换它们(强烈建议使提示与权威区域内数据保持同步)。