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

Question

在执行某些工作职责的过程中，我需要加强 SRV 记录，并且我正在尝试将 Wikipedia 声明与我在 DNS 挖掘中看到的内容进行协调。

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

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

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

也就是说，像这样：

> 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 记录，而不是一个地址记录？

Answer 1

您引用的维基百科文章报告了SRV 记录的相关RFC 2782说明：

目标

目标主机的域名。这个名字必须有一个或多个地址记录，名字不能是别名（在 RFC 1034 或 RFC 2181 的意义上）。

您所看到的是明显违反规则；但是，它可能会起作用（并且通常会起作用），如果正在寻找该 SRV 记录的任何客户端应用程序足够智能以正确处理 CNAME 记录，即使它应该只期待响应中的 A 记录。

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

这类似于将 MX 记录指向 CNAME，这不仅在一个RFC 中被定义为错误，而且在两个RFC 中被定义为错误，但这是很常见的做法（似乎没有邮件服务器有问题）。