CNAME记录中的_（下划线）是否非法？

9

我们无法在主机的Web界面上为DKIM密钥创建长TXT记录。

每行只能接受256个字符。

我们尝试了多行，然后尝试根据建议("在第一行和")最后一行添加。都不行。

然后，我们尝试为另一个主机上的记录创建一个cname，在此我们可以创建DKIM TXT记录。

但是现在，Web界面抱怨CNAME记录中的名称不合法。

mail._domainkey.example.com TXT是
mail._domainkey.example.com CNAME可以的，不是
mail.domainkey.example.com CNAME可以的，但是不是我们想要的。

是否只是确定Web界面使我们发疯，还是在其中添加下划线真的“非法” CNAME？

domain-name-system opendkim

— 伦内
source

1

在编写本文时，提供程序正在修复Web界面！

— Lenne

18

是的，DNS名称（也包括A / AAAA）只能包含[0-9], [a-z], -，因此下划线无效。请注意，TXT记录不是主机名，并且此限制不适用于它。最后编辑：-可能也不会用作第一个字符，因此mail.-domainkey.our.dom无效。

https://zh.wikipedia.org/wiki/主机名#Restrictions_on_valid_hostnames

最终编辑：我部分错了。当CNAME用作主机名时，上述限制适用。似乎CNAME在DKIM上下文中不被视为主机名，在这种情况下，它_应该是CNAME条目的有效部分。参见/programming/13650233/underscore-in-cname-required-by-ses-not-allowed-by-registrar/26692491#26692491

— 斯文
source

但是CNAME是主机名吗？一些文档显示在cname中使用下划线，因此貌似可以使用。 kb.mailchimp.com/accounts/email-authentication/…–

— Lenne

另外，下划线至少会在Microsoft的DNS管理工具中显示在Windows域下方MS Windows Active Directory集成区域的DNS条目中，但是我不确定这些下划线是否实际上是名称的一部分，并且Windows是否支持DNS中的下划线请求，或者下划线仅出现在DNS管理管理单元中，而实际上不属于名称的一部分。

— Todd Wilcox

请注意，引用的Wikipedia条目与Internet名称有关，而不与DNS有关。

— Jim B

@ Lenne：CNAME是有效的主机名，因为它是主机的别名。@ToddWilcox：是的，这是众所周知的，这是MS的（故意的）规范违规行为，尽管不合法，但其他系统却确实出现在DNS，DHCP，…数据包中，因此不会造成其他麻烦。

— mirabilos

2

@mirabilos“ CNAME是有效的主机名”否，CNAME的目标（RDATA）是域名，而不是主机名（域名是所有可能的主机名的超集）。_foo CNAME _bar完全合法，您可以使用进行测试named-checkzone。

— Patrick Mevzek '18年

2

DNS中允许使用任何有效字符。参见https://tools.ietf.org/html/rfc2181#section-11

“ DNS本身对可用于标识资源记录的特定标签仅设置了一个限制。该限制与标签的长度和全名有关。任何一个标签的长度都限制在1到63个八位字节之间。 ”

客户必须验证名称值，例如MX记录中可能包含值“ Alice”，但是在查找之后，该值应被拒绝，因为“ Alice”不是有效的电子邮件地址。

在这种情况下，您的托管人似乎正在“验证”您的输入，并且他们应该能够为您手动输入。

— 吉姆·B
source

“ DNS中允许使用任何有效字符”，这要复杂得多。有域名和主机名。除非另有说明，否则您到处都具有域名标签，这实际上意味着任何字符，所以_您也喜欢其他任何东西。但是，对于某些记录，您只能使用主机名，不能使用域名。主机名仅是字母数字和连字符，仅此而已。例如，A或AAAA记录的所有者是主机名，而不是域名。记录的RDATA（目标）NS也是主机名，而不是域名。

— Patrick Mevzek '18年

1

“一个MX记录可能包含值“ Alice”，但是在查找后该值应被拒绝，因为“ Alice”不是有效的电子邮件地址。“ MX RR从什么时候开始引用电子邮件地址？

— CVn

0

RFC 1034：标签必须遵循ARPANET主机名的规则。它们必须以字母开头，以字母或数字结尾，并且仅以字母，数字和连字符作为内部字符。在长度上也有一些限制。标签不得超过63个字符。

— 米卡夫
source

我在Arduino上也遇到了问题，其中某些库提供了一个主机名，例如ESP_245537，当DHCPserver尝试更新DNS时，该名称将被拒绝。

— Lenne

错了 CNAME的标签不一定是主机名，因此所有字符在此处均有效，包括_。

— Patrick Mevzek '18年

1

即使没有这些，这些都是旧规则。他们禁止以数字开头的主机名，但是为了适应3com.com该规则，例如，放宽了规则，请参阅tools.ietf.org/html/rfc1123#page-13 “主机名语法的一个方面已更改：对第一个字符的限制放宽以允许输入字母或数字。”

— Patrick Mevzek '18年

@Lenne如果esp_245537用作主机名，则由于它不是有效的主机名，因此必须拒绝DNS更新。如果将其用作域名，则DNS更新应该成功（否则是错误），因为它是有效的DNS标签。

— Patrick Mevzek '18年

我看到过暗示，有可能将无效字符从DHCP转换为DNS，但从未使它起作用。

— Lenne

0

通过编辑，@ Sven的答案已经是正确的，但仅是直接表达短语。

TL; DR是下划线在CNAME双方记录中均有效，请阅读以下内容以了解原因。

RFC 1034等基于“域名”定义记录，“域名”是具有任何字符的标签，因此包括_。

但是某些记录对所有者名称和/或资源数据（RDATA）具有更严格的规则。只有一个主机名将被接受，并且确实是规则（现在放宽了，因为以前主机名不能以数字开头），您可以使用任何ASCII字母（不区分大小写），任何ASCII数字和连字符，再加上一些额外的位置规则：在开始或结束处没有连字符，在位置3和4处没有双连字符（因为“保留”形式的IDN xn--仅允许使用大小写形式）。

例如，A或AAAA记录的所有者名称是主机名，而不是域名。因此 test.example.com A 192.0.2.1为什么所有这些都不是正确的：

_test.example.com A 192.0.2.1
-test.example.com A 192.0.2.1
test-.example.com A 192.0.2.1

使用该named-checkzone程序可以很容易地进行测试（部分bind名称服务器软件，但可以单独使用和安装，其他名称服务器可能具有类似的检查工具，并且总有可能存在在线接口），只需将记录放入文件中并运行它在：

$ cat z1.txt
test.example.com. 1 IN A 192.0.2.1
_test.example.com. 1 IN A 192.0.2.1
-test.example.com. 1 IN A 192.0.2.1
test-.example.com. 1 IN A 192.0.2.1
$ /usr/local/sbin/named-checkzone example.com z1.txt
z1.txt:2: _test.example.com: bad owner name (check-names)
z1.txt:3: -test.example.com: bad owner name (check-names)
z1.txt:4: test-.example.com: bad owner name (check-names)

（之前的数字IN是TTL，这与此处的问题无关，但只需要通过记录的语法验证即可）。

对于其他记录，则相反：因为NS对所有者没有限制，但是对作为数据的“目标”有限制。数据只能是主机名，不能是域名，因为您需要指向作为响应DNS查询的物理主机的权威名称服务器。

现在CNAME，这里是RFC 1034第3.6节中的相关引号：

“所有者：这是找到路由反射器的域名。” 默认情况下，这意味着任何名称，而不仅仅是主机名（作为CNAME记录的来源）

“ RDATA：是描述资源的类型，有时是类相关的数据：”

“ CNAME一个域名。”

因此，a的所有者CNAME（左侧的内容）以及附加到其的资源数据，目的地/目标（右侧的内容）都是域名，而不仅仅是主机名。基本上是任何字符，因此_在两侧都允许包含。

同样，易于测试named-checkzone：

$ cat z2.txt
_foo 1 CNAME _bar
$ /usr/local/sbin/named-checkzone example.com z2.txt
zone example.com/IN: has 0 SOA records
zone example.com/IN: has no NS records
zone example.com/IN: not loaded due to errors.

没有任何有关错误的CNAME（其他的错误预期，因为在我的假带我并没有把任何SOA或NS记录像一个真正的区域将有）

— 帕特里克·梅夫克（Patrick Mevzek）
source