在履行一些工作职责的过程中，我需要对SRVlogging进行调整，并且试图使维基百科声明与我在DNS挖掘中看到的一致。
根据维基百科的SRVlogging条目 ，
SRVlogging中的目标必须指向具有地址logging（A或AAAAlogging）的主机名。 指向具有CNAMElogging的主机名不是有效的configuration。
但我看到logging在哪里dig返回一个SRVlogging指向一个名称，这是一个CNAMElogging中的别名。
就是这样的：
> 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
看起来SRVlogging的configuration方式与维基百科条目不允许的方式完全相同。 我误解了什么？ 是不是显示SRVlogging指向alias.domain.com，它有一个CNAMElogging，而不是地址logging？
您所引用的维基百科文章报告了SRVlogging相关的RFC 2782的内容：
目标
目标主机的域名。 这个名字必须有一个或多个地址logging，名称不能是别名（RFC 1034或RFC 2181）。
你所看到的是明显的违反规定; 然而，它可能工作（ 通常是这样），如果任何客户端应用程序正在寻找SRVlogging足够聪明，以正确处理一个CNAMElogging，即使它应该只期望在响应中的Alogging。
但它也可能根本不起作用：它不受支持，完全依赖于客户端应用程序; 因此应该避免，因为它没有遵循适当的规则，并可能导致错误和/或不可预知的结果。
这类似于将MXlogging指向CNAME，CNAME 不仅在一个而且在两个 RFC中被定义为错误 ，但是这是相当普遍的做法（并且没有邮件服务器似乎有问题）。
这是一个限制行为的例子，是的。 限制本身来自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.
不幸的是，允许禁止configuration的DNS服务器软件并不新鲜。 它可以和确实发生，就像其他loggingtypes一样，别名的目标被禁止，如NS和MX 。 （上文提到的）
仅仅因为它可以在野外find并不意味着它是“好的”，当忽略标准时发生的情况因产品而异。 我没有testing过与SRVlogging的交互，但ISC BIND关于指向别名的NSlogging的非常着名的devise决定是如果在recursion期间发现logging，则完全删除logging 。 如果所有NSlogging都以这种方式被删除，则所有查询的结果都是SERVFAIL 。
总之，坚持标准。 这是唯一安全的事情。