☰

发布的指向 CNAME 别名的 SRV 记录违反了 RFC 2782 吗？

tag-icon • tag-icon domain-name-system cname-record srv-record
发布的指向 CNAME 别名的 SRV 记录违反了 RFC 2782 吗？

在履行一些工作职责的过程中，我需要熟悉 SRV 记录，并且我正在尝试将维基百科声明与我在 DNS 挖掘中看到的内容进行协调。

根据维基百科的 SRV 记录条目，

SRV 记录中的目标必须指向具有地址记录（A 或 AAAA 记录）的主机名。指向具有 CNAME 记录的主机名不是有效配置。

但是我看到记录dig返回一个指向 CNAME 记录中的别名的名称的 SRV 记录。

也就是这样的：

> dig _https._tcp.alpha.domain.com SRV

;; QUESTION SECTION:
;_https._tcp.alpha.domain.com.    IN    SRV

;; ANSWER SECTION:
_https._tcp.alpha.domain.com 59 IN SRV 30 30 4443 alias.domain.com


> dig alias.domain.com

;; QUESTION SECTION:
;alias.domain.com.    IN    A

;; ANSWER SECTION:
alias.domain.com.  35  IN  CNAME canonical.name.amazonaws.com.
canonical.name.amazonaws.com. 35 IN A 52.78.234.189
canonical.name.amazonaws.com. 35 IN A 107.21.179.88
canonical.name.amazonaws.com. 35 IN A 52.12.126.92

看起来 SRV 记录的配置方式与 Wikipedia 条目中所说的不允许的方式完全一致。我误解了什么？它不是显示 SRV 记录指向 alias.domain.com，它具有 CNAME 记录，而不是地址记录吗？

答案1

你引用的维基百科文章报道了相关RFC 2782对于 SRV 记录，状态为：

目标

目标主机的域名。此名称必须有一个或多个地址记录，名称不得是别名（根据 RFC 1034 或 RFC 2181 的定义）。

你所看到的明显违反了规则；然而，它可能工作（并且它通常如果任何客户端应用程序正在寻找该 SRV 记录，并且该应用程序足够智能，可以正确处理 CNAME 记录，即使它在响应中只应期望出现 A 记录，它也会这样做。

但也可能不是根本无法工作：它不受支持并且完全依赖于客户端应用程序；因此应该避免使用它，因为它没有遵循正确的规则并且可能导致错误和/或不可预测的结果。

这类似于将 MX 记录指向 CNAME，其定义为就是错的不仅一， 但二RFC，但它是一种相当常见的做法（并且似乎没有邮件服务器对此有问题）。

答案2

是的，这就是限制行为的一个例子。限制本身来自RFC 2781在“目标”的定义中：

   Target
        The domain name of the target host.  There MUST be one or more
        address records for this name, the name MUST NOT be an alias (in
        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
        not required, to return the address record(s) in the Additional
        Data section.  Unless and until permitted by future standards
        action, name compression is not to be used for this field.

        A Target of "." means that the service is decidedly not
        available at this domain.

不幸的是，DNS服务器软件允许禁止配置并不是什么新鲜事。这种情况确实会发生，就像其他禁止别名目标的记录类型一样，例如NS和MX。（如上所述）

仅仅因为它可以在野外找到并不意味着它是“可以的”，当标准被忽略时会发生什么因产品而异。我还没有测试与SRV记录的交互，但 ISC BIND 在指向别名的记录方面有一个非常著名的设计决定，NS那就是彻底放弃记录如果在递归过程中发现。如果所有NS记录都以这种方式被删除，则所有查询的结果都将SERVFAIL针对相关子域。

简而言之，坚持标准。这是唯一安全的做法。

相关内容