顶级域名末尾可以带数字吗?
从技术上讲是的,除非它是纯数字的,否则根据当前规则并且出于易于理解的原因(为了消除与 IP 地址的歧义),它不能是 TLD。出于 ICANN 强制执行的原因,它的末尾不能包含数字,除非它是 IDN TLD。
让我们回到一些 RFC,以获得一些更清晰的定义:
RFC 952:DOD 互联网主机表规范(1985 年 10 月)
这是当时互联网“主机名”的定义:
“名称”(网络、主机、网关或域名)是一个文本字符串
最多 24 个字符,取自字母表 (A-Z)、数字 (0-9)、减号
符号 (-) 和句点 (.)。请注意,只有在以下情况下才允许使用句点:
它们用于界定“域样式名称”的组成部分。 (看
RFC-921,“域名系统实施时间表”,用于
背景)。不允许有空白或空格字符作为
姓名。不区分大小写。首先
字符必须是字母字符。最后一个字符不能是
减号或句号。
请注意,这还具有以下内容:
单字符名称
或昵称是不允许的。
因此在这一点上:
-
com1
是有效的 TLD
-
3com
不是(“第一个字符必须是字母字符。”)
-
42
不是(同样的原因)
-
1
不是(同样的原因)
-
a
不是(“不允许使用单字符名称或昵称。”)
RFC 1034:域名 - 概念和设施(1987 年 11 月)
这是创建我们今天所知的 DNS 的 RFC 之一。出于兼容性原因,它将主机名定义为标签序列,其中标签定义如下:
它们必须以字母开头,以字母或数字结尾,并且具有以下内容:
内部字符仅限字母、数字和连字符。还有
对长度有一些限制。标签必须为 63 个字符或
较少的。
TLD 是众多标签之一(TLD 中的 L)。根据上述规则,com1
是一个有效的标签,因此也是一个有效的 TLD,其中3com
不会的。这直接给我们带来了以下修改。
RFC 1123:互联网主机的要求 - 应用程序和支持(1989 年 10 月)
这通过更改一条规则来修改之前的 RFC:
RFC-952 中指定了合法 Internet 主机名的语法
[DNS:4]。主机名语法的一方面发生了变化:
对第一个字符的限制放宽,允许
字母或数字。主机软件必须支持这种更自由的
句法。
所以在这一点上:
-
com1
是有效的 TLD
-
3com
也有效
-
42
已验证
-
1
已验证
-
a
已验证
对于“数字”TLD 的情况,第一份文件中的以下规则适用:
每当用户输入互联网主机的身份时,它应该
可以输入 (1) 主机域名或 (2) IP
点分十进制 ("#.#.#.#") 形式的地址。主机应该检查
语法上的字符串之前是点分十进制数
在域名系统中查找它。
and
如果可以输入点分十进制数而无需这样
识别分隔符,那么必须进行完整的语法检查
制作,因为现在允许主机域名的一部分
以数字开头并且合法地可以是完全数字
(参见第 6.1.2.4 节)。然而,有效的主机名永远不能
具有点分十进制形式 #.#.#.#,因为至少
最高级别的组件标签将按字母顺序排列。
RFC 1738:统一资源定位符 (URL)(1994 年 12 月)
这也涉及 TLD,但给出:
网络主机的完全限定域名或其 IP
地址作为一组四个十进制数字组,由
“。”。完全限定域名采用所述形式
RFC 1034 [13] 第 3.5 节和 RFC 1123 第 2.1 节
[5]:由“.”分隔的域标签序列,每个域
以字母数字字符开头和结尾的标签,以及
可能还包含“-”字符。最右边的域
不过,标签永远不会以数字开头,这
在语法上区分所有域名和 IP
地址。
RFC 3696:名称检查和转换的应用技术(2004 年 2 月)
这是引入 IDN(国际化域名)所必需的,它是这样说的:
允许使用任何字符或位组合(如八位字节)
DNS 名称。然而,有一种需要的首选形式
大多数应用程序。这种首选形式是唯一的一种
允许出现在顶级域名 (TLD) 的名称中。一般来说,它
也是大多数注册二级名称中允许的唯一形式
在 TLD 中,尽管用户通常看不到的一些名称遵循
其他规则。它源自最初的 ARPANET 规则
主机命名(即“主机名”规则)也许更好
描述为“LDH 规则”,位于其允许的字符之后。
更新后的 LDH 规则规定标签(单词或字符串)
由句点分隔)组成的域名必须仅包含
ASCII [ASCII] 字母和数字字符,加上连字符。
不允许使用其他符号或标点符号
空格处。如果使用连字符,则不允许出现在
标签的开头或结尾。还有一条附加规则
这本质上要求顶级域名不能全部是-
数字。
事实上,一旦涉及 IDN,并且它们是 IDN TLD(现在是 ccTLD 和 gTLD),所选编码就会生成以下形式的 ASCII 字符串xn--something
其中某物可以有数字,包括末尾,如其他答案中所示。
然而,最后一句中的“附加规则”从何而来并不清楚。
RFC 4697:观察到的 DNS 解析不当行为(2006 年 10 月)
不定义任何内容,但提供一些有趣的事实:
根名称服务器接收大量 A 记录
QNAME 看起来像 IPv4 地址的查询。
and
一个可能的解决方案是委托这些数字 TLD
从根区域到一组单独的服务器以吸收
交通。
这清楚地表明,在野外确实存在一些应用程序,可能是错误的,但它至少表明它在技术上是有效的,发送对格式确实类似于 IPv4 地址的名称的查询,因此具有完全数字的“TLD”。
事实上,有一次推出.42
注册管理机构,显然完全处于 ICANN 生态系统之外。您可以在以下位置查看其摘要:http://www.dotsauce.com/experimental-numeric-tld-42-domain/ http://www.dotsauce.com/experimental-numeric-tld-42-domain/以及他们的主要解释的存档https://web.archive.org/web/20101222151118/http://register.42registry.org:80/ https://web.archive.org/web/20101222151118/http://register.42registry.org:80/(法语)。
尽管技术上可行,但它并没有走得太远。
例如,它表明基于 Microsoft 的操作系统默认情况下根本不考虑纯数字 TLD,但他们为此提供了一个补丁:https://support.microsoft.com/en-us/help/947228/error-message-when-you-try-to-join-a-windows-vista-based-client-comput https://support.microsoft.com/en-us/help/947228/error-message-when-you-try-to-join-a-windows-vista-based-client-comput“当您尝试将基于 Windows Vista 的客户端计算机加入具有纯数字后缀的顶级域 (TLD) 时,基于 Windows Vista 的客户端计算机无法加入该域。[..] 此行为是设计使然。 ”
互联网草案 Draft-liman-tld-names-06:顶级域名规范(2011 年 11 月)
最后给出了一些解释,解释了为什么纯数字 TLD 甚至只有一位数字的 TLD 有时会被视为无效(当上述规范没有明确结果时):
(下面第 2.1 节引用了上面引用的 RFC 1123 中的内容)
此外,第 2.1 节的讨论部分说:
'However, a valid host name can never have the dotted-decimal form
#.#.#.#, since at least the highest-level component label will be
alphabetic.' [Section 2.1]
一些实施者可能已经理解了上面这句话“将是”
按字母顺序排列是协议限制。
但它基本上只是建议随波逐流并继续相同的限制:
[RFC0952] 和 [RFC1123] 都没有明确说明原因
这些限制。可以认为人为因素是
考虑; [RFC1123]似乎表明原因之一
是为了防止点分十进制 IPv4 地址和
主机域名。无论如何,有理由相信
一些已部署的软件中已假定存在限制,并且
对规则的修改应谨慎进行。
因此它给出了这样的定义:
传统顶级标签 = 1*63(ALPHA)
该草案从未转换为 RFC,因为并非所有人都同意。您可以在以下位置找到有反对声音的帖子:https://www.ietf.org/mail-archive/web/dnsop/current/msg08866.html https://www.ietf.org/mail-archive/web/dnsop/current/msg08866.html;基本上不清楚过去是否有限制,我们现在正在尝试放松一点,或者是否从一开始就没有限制,以及人们错误地实施了系统。
例如,您可以查看此 Chromium/Chrome 错误报告:https://bugs.chromium.org/p/chromium/issues/detail?id=31405 https://bugs.chromium.org/p/chromium/issues/detail?id=31405如果使用以数字或纯数字开头的 TLD,则浏览会失败(如果以前面有字母的数字结尾,则浏览会失败)。这不被认为是一个错误,也没有被修复,因为浏览器附带了一个 TLD 列表,因此除了测试它们的语法之外,它还可以知道哪些是有效的,哪些是无效的。
ICANN 新 TLD 申请指南(2012 年 6 月)
可用于https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf从第 64 页开始,内容如下:
ASCII 标签(即在线路上传输的标签)必须按照技术标准域名:实施和规范 (RFC 1035) 以及 DNS 规范的澄清 (RFC 2181) 及其任何更新中的规定有效。
ASCII 标签必须是有效的主机名,如技术标准 DOD 互联网主机表规范 (RFC 952)、互联网主机要求 — 应用程序和支持 (RFC 1123) 以及名称检查和转换应用技术 (RFC 3696)、应用中的国际化域名 (IDNA)(RFC 5890-5894) 及其任何更新。这包括以下内容:
ASCII 标签必须完全由字母(字母字符 a-z)组成,或者
该标签必须是有效的 IDNA A 标签(进一步限制如下文第二部分所述)。
特别注意的是:ASCII 标签必须完全由字母组成(字母字符 a-z)
这会立即禁止任何完整的数字,以及事实上的任何数字,包括末尾的数字,但 IDN TLD 除外,其形式为xn--something
.
请注意,有人直接向 ICANN 询问此事,并得到了以下回复,如下所示:https://domaingang.com/domain-news/icann-applicant-handbook-this-is-why-we-cannot-have-numeric-gtlds/ https://domaingang.com/domain-news/icann-applicant-handbook-this-is-why-we-cannot-have-numeric-gtlds/ :
请注意,数字 TLD 在第一轮申请中被禁止。
申请人指南中禁止数字 gTLD(http://newgtlds.icann.org/en/applicants/agb http://newgtlds.icann.org/en/applicants/agb)源于对此类域正常运行能力的许多技术问题。域名通常用于可能使用其他类型标识符(如 IP 地址)的地方。
TLD 全部由字母组成的事实通常是软件识别域名的关键决定因素。如果允许使用诸如“.123”之类的 TLD,您可能会拥有一个域名“74.125.244.123”,该域名很难与 IP 地址“74.125.244.123”区分开来。还有其他考虑因素:一些技术标准文档规定 TLD 将按字母顺序排列,这也已被编码为软件中的假设。
AGB 对字母字符的限制旨在限制这些情况,这意味着此类 TLD 不太可能在软件中正常工作,并限制相同问题可能导致的潜在安全问题。