在研究如何在我们的网络中设置一些静态DNS-SD服务时,我遇到了http://www.dns-sd.org/ServerStaticSetup.html,其中指出Active Directory的DNS服务器不支持带空格的DNS名称。在他们中。
有谁知道这是否仍然正确(因为页面感觉很旧)?
更新:我主要是指PTR和SRV记录,而不是A / CNAME记录。
在研究如何在我们的网络中设置一些静态DNS-SD服务时,我遇到了http://www.dns-sd.org/ServerStaticSetup.html,其中指出Active Directory的DNS服务器不支持带空格的DNS名称。在他们中。
有谁知道这是否仍然正确(因为页面感觉很旧)?
更新:我主要是指PTR和SRV记录,而不是A / CNAME记录。
Answers:
甲域名可以包括在到255的范围0任何二进制八位位组。
但是,如果您的AD条目表示主机名,则空格不是有效字符。主机名(即指向A
或的域名AAAA
)必须遵循RFC 1123中的规则,该规则实际上将合法字符限制为LDH(“字母数字连字符”)。
因此,对于其他条目,MS很有可能会误解了RFC。他们不会是第一个,当然也不会是最后一个。
参考文献
的§5.1 RFC 1035:
引用约定允许将任意字符存储在域名中。
以及第6.1.3.5节。的RFC 1123:
DNS非常笼统地定义域名语法-一串标签,每个标签最多包含63个8位八位字节,以点分隔
和RFC 2181的 §11 :
任何二进制字符串,可以用作任何资源记录的标签
啊-不好意思,不过您这里有一只狗。不是说AD不支持带空格的DNS名称,而是每个定义和RFC的DNS名称不允许以空格开头。RFC 952和1123都不允许空格作为DNS名称的一部分。
因此,AD并不缺少对DNS名称中空格的支持,而是因为它遵循与其他所有人相同的规则。
SRV
记录中使用前缀名称。另请参阅RFC 1123的§6.1.3.5和我的个人资料。
您的特定问题的答案是“ 否”,Active Directory 不允许 DNS 主机名中包含空格。KB 909264-在Active Directory中针对计算机,域,站点和OU的命名约定中明确列出了禁止的字符,在其标记为“ 禁止的字符”的部分中显示:
DNS主机名不能包含空格或空格字符。
通常,将答案从Active Directory扩展到DNS域名系统时,会遇到一些棘手的问题,因为尽管在某些情况下在技术上允许使用空格,但实际上您自己可能永远不会遇到这种情况。
简短的答案:请勿在DNS主机名中使用空格!
根据RFC 3696§2(域名(DNS)名称限制)的长答案是:
DNS名称中允许使用任何字符或位的组合(如八位字节)。
它继续说明(强调我的意思):
但是,大多数应用程序都需要一种首选形式。这种首选形式是顶级域名(TLD)名称中唯一允许的形式。通常,它也是顶级域名(TLD)中注册的大多数第二级名称所允许的唯一格式, 尽管用户通常看不到的某些名称遵循其他规则。它源自用于主机命名的原始ARPANET规则(即“主机名”规则),并可能在其允许的字符之后更好地描述为“ LDH规则”。最新的LDH规则规定组成域名的标签(用句点分隔的单词或字符串)必须仅由ASCII [ASCII]字母和数字字符以及连字符组成。不允许使用其他符号或标点符号,也不允许使用空格。 如果使用连字符,则不允许在标签的开头或结尾出现连字符。还有一条附加规则,本质上要求顶级域名不能为全数字。
实际上,这意味着您不应使用空格,即使在RFC 1035§5.1的这些摘录中定义的最通用域名规范中,也可以在域名中允许使用空格:
<domain-name>构成了主文件中大部分数据。域名中的标签表示为字符串,并用点分隔。引用约定允许将任意字符存储在域名中。
和
<character-string>用一种或两种方式表示:连续的无内部空格的字符集,或以“开头并以”结尾的字符串。在“定界字符串中,除了”本身,任何字符都可以出现,必须使用\(反斜杠)将其引起来。
请记住,RFC 1035中的其他地方,特别是§2.3,它警告:
2.3。约定
域系统具有处理低级但基本问题的几种约定。 尽管实现者可以在自己的系统内随意违反这些约定,但他必须在从其他主机观察到的所有行为中遵守这些约定。
2.3.1。首选名称语法
DNS规范试图在构造域名的规则中尽可能通用。这个想法是,任何现有对象的名称都可以用最少的更改就可以表示为域名。
但是,在为对象分配域名时,谨慎的用户将选择一个既要满足域系统规则又要满足该对象的任何现有规则的名称,无论这些规则是由现有程序发布还是隐含。
例如,命名邮件域时,用户应同时满足本备忘录的规则和RFC-822中的规则。创建新的主机名时,应遵循HOSTS.TXT的旧规则。当将旧软件转换为使用域名时,这可以避免出现问题。
我当然欢迎进一步澄清或更正我的解释,但是除非您能够引用RFC的特定部分来确认或拒绝这种解释,否则请不要这样做。