顶级域名最后可以包含一个数字吗？ Idk没有任何关于DNS规则等但是当我尝试将PHP的filter_var（）函数与FILTER_VALIDATE_EMAIL用于[email protected]时，它返回true。
从概念上讲，没有任何东西可以禁止TLD和未来的数字，谁知道，也许会有数字顶级域名。
目前还没有TLD确实存在数字 - 该功能可能不会针对已知TLD列表进行测试（因为它可能会发生变化），但是在词汇上。
实际上目前有很多TLD使用包含数字的TLD：
XN--1QQW23A XN--3BST00M XN--3DS443G XN--3E0B707E XN--45BRJ9C XN--4GBRIM XN--55QW42G XN--55QX5D XN--6FRZ82G XN--6QQ986B3XL XN--80ADXHKS XN--80AO21A XN--80ASEHDB XN--80ASWG XN--90A3AC XN--C1AVG XN--CG4BKI XN--CLCHC0EA0B2G2A9GCD XN--CZR694B XN--CZRU2D XN--D1ACJ3B XN--FIQ228C5HS XN--FIQ64B XN--FIQS8S XN--FIQZ9S XN--FPCRJ9C3D XN--FZC2C9E2C XN--GECRJ9C XN--H2BRJ9C XN--I1B6B1A6A2E XN--IO0A7I XN--J1AMH XN--J6W193G XN--KPRW13D XN--KPRY57D XN--KPUT3I XN--L1ACC XN--LGBBAT1AD8J XN--MGB9AWBF XN--MGBA3A4F16A XN--MGBAAM7A8H XN--MGBAB2BD XN--MGBAYH7GPA XN--MGBBH1A71E XN--MGBC0A9AZCG XN--MGBERP4A5D4AR XN--MGBX4CD0AB XN--NGBC5AZD XN--NQV7F XN--NQV7FS00EMA XN--O3CW4H XN--OGBPF8FL XN--P1AI XN--PGBS0DH XN--Q9JYB4C XN--RHQV96G XN--S9BRJ9C XN--SES554G XN--UNUP4Y XN--VHQUV XN--WGBH1C XN--WGBL6A XN--XHQ521B XN--XKC2AL3HYE2A XN--XKC2DL3A5EE0H XN--YFRO4I67O XN--YGBI2AMMX XN--ZFR164B
你可以在这里看到data.iana.org/TLD/tlds-alpha-by-domain.txt的最新清单或这里有swcs.com.au/tld.htm描述的清单
顶级域名最后是否可以包含数字？
从技术上讲是正确的，除非它纯粹是数字，否则根据现行规则并且易于理解（以消除IP地址的歧义），它不能是TLD。并且由于ICANN强制执行的理由，最终不能包含数字，除非它是IDN TLD。
让我们回到一些RFC，以便对事物有一些更明确的定义：
这是当时互联网“主机名”的定义：
“名称”（网络，主机，网关或域名）是文本字符串 从字母表（A-Z），数字（0-9），减去24个字符 符号（ - ）和句点（。）。请注意，仅在允许时间段 它们用于划分“域样式名称”的组件。 （看到 RFC-921，“域名系统实施时间表”，用于 背景）。不允许使用空格或空格字符作为名称的一部分。大小写没有区别。第一个字符必须是字母字符。最后一个字符不能是减号或句号。
请注意，还有：
不允许使用单个字符名称或昵称。
因此，在那一点上：
com1是有效的顶级域名3com不是（“第一个字符必须是字母字符。”）42不是（同样的原因）1不是（同样的原因）a不是（“不允许使用单个字符名称或昵称。”）这是我们今天所知的创建DNS的RFC之一。出于兼容性原因，它将主机名定义为标签序列，其中标签定义如下：
它们必须以字母开头，以字母或数字结尾，并且内部字符仅包含字母，数字和连字符。长度也有一些限制。标签不得超过63个字符。
TLD是其中一个标签。根据上述规则，com1是一个有效的标签，因此也就是TLD，其中3com不会。这直接带给我们以下修正案。
这通过更改一个规则来修改以前的RFC：
RFC-952 [DNS：4]中指定了合法Internet主机名的语法。由此改变主机名语法的一个方面：放宽对第一个字符的限制以允许字母或数字。主机软件必须支持这种更自由的语法。
所以那时：
com1是有效的顶级域名3com也有效42有效1有效a有效对于“数字”TLD的情况，第一份文件中的以下规则适用：
每当用户输入Internet主机的标识时，应该可以输入（1）主机域名或（2）点分十进制（“＃。＃。＃。＃”）形式的IP地址。在域名系统中查找字符串之前，主机应该在语法上检查字符串中的点分十进制数字。
和
如果可以在没有这种识别分隔符的情况下输入点分十进制数，则必须进行完整的语法检查，因为现在允许主机域名的一段以数字开头，并且在法律上可以完全是数字（参见第6.1节）。 2.4）。但是，有效的主机名永远不能使用点分十进制格式＃。＃。＃。＃，因为至少最高级别的组件标签将是字母。
这也谈到了TLD，但给出了
网络主机的完全限定域名，或其IP地址，作为由“。”分隔的四个十进制数字组的集合。完全合格的域名采用RFC 1034 [13]第3.5节和RFC 1123 [5]第2.1节中描述的形式：由“。”分隔的域标签序列，每个域标签以字母数字字符开头和结尾，可能还包含“ - ”字符。但是，最右边的域标签永远不会以数字开头，从语法上区分所有域名和IP地址。
这是引入IDN（国际化域名）所必需的，它有这样的说法：
DNS名称中允许使用任何字符或位组合（以八位字节为单位）。但是，大多数应用程序都需要一种首选形式。此首选表单是顶级域名或顶级域名中唯一允许的格式。一般而言，它也是在TLD中注册的大多数二级域名允许的唯一形式，尽管用户通常看不到的某些名称遵守其他规则。它源于主机命名的原始ARPANET规则（即“主机名”规则），并且在它允许的字符之后可能更好地描述为“LDH规则”。更新后的LDH规则规定，组成域名的标签（由句点分隔的单词或字符串）必须仅包含ASCII [ASCII]字母和数字字符以及连字符。不允许使用其他符号或标点符号，也不允许使用空格。如果使用连字符，则不允许在标签的开头或结尾出现。还有一条规则基本上要求顶级域名不是全数字的。
事实上，只要涉及IDN，它们就是IDN TLD（现在都是ccTLD和gTLD），所选择的编码会生成一个xn--something形式的ASCII字符串，其中某些内容可以包含数字，包括最后的数字，如其他答案中所示。
然而，从最后一句中的“附加规则”来自何处并不是很清楚。
没有定义任何东西，但提供一些有趣的事实：
根名称服务器接收大量A记录查询，其中QNAME看起来像IPv4地址。
和
一种可能的解决方案是将这些数字TLD从根区域委派给一组单独的服务器以吸收流量。
这清楚地表明，在野外，确实存在应用程序，可能是错误的，但它至少表明它在技术上有效，发送查询确实格式化为IPv4地址的名称，因此使用完全数字“TLD”。
实际上有一个启动.42注册表的经验，显然完全在ICANN生态系统之外。你可以在http://www.dotsauce.com/experimental-numeric-tld-42-domain/上看到它的摘要，并在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“当您尝试将基于Windows Vista的客户端计算机加入顶级域名（TLD）时有一个纯数字后缀，基于Windows Vista的客户端计算机无法加入域。[..]这种行为是设计的。“
这最终给出了一些解释，为什么纯数字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地址和主机域名之间的混淆。在任何情况下，有理由相信某些已部署的软件已经采用了这些限制，并且应谨慎对规则进行更改。
因此它提供了这个定义：
traditional-tld-label = 1 * 63（ALPHA）
该草案从未转换为RFC，因为不是每个人都同意它。你可以在https://www.ietf.org/mail-archive/web/dnsop/current/msg08866.html找到一个有不同声音的帖子;基本上不清楚过去是否存在限制，我们现在正试图放松一点，或者如果从未有过限制，并且人们错误地实施了系统。
例如，您可以看到有关此Chromium / Chrome错误报告：https://bugs.chromium.org/p/chromium/issues/detail?id=31405浏览失败，如果使用以数字或纯数字开头的TLD（如果它以带有字母的数字结束之前有效）。这不被视为一个错误，并且没有修复，因为浏览器附带了一个TLD列表，因此除了测试它们的语法之外，它还可以知道哪些不是有效的。
在https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf上可以看到以下内容从第64页开始：
ASCII标签（即，在线路上传输的标签）必须是有效的，如技术标准域名：实施和规范（RFC 1035），以及对DNS规范的澄清（RFC 2181）及其任何更新。
ASCII标签必须是有效的主机名，如技术标准DOD Internet主机表规范（RFC 952），Internet主机要求 - 应用程序和支持（RFC 1123）以及用于检查和转换名称的应用程序技术（RFC）中所指定的3696），应用程序中的国际化域名（IDNA）（RFC 5890-5894）及其任何更新。这包括以下内容：
ASCII标签必须完全由字母（字母字符a-z）组成，或
标签必须是有效的IDNA A标签（进一步限制，如下面第II部分所述）。
特别注意：ASCII标签必须完全由字母组成（字母字符a-z）
这立即禁止任何完整的数字，以及实际上任何数字，包括最后的数字，除了IDN TLD，形式为xn--something的数字。
请注意，有人直接向ICANN询问此事，并得到以下答复，显示在https://domaingang.com/domain-news/icann-applicant-handbook-this-is-why-we-cannot-have-numeric-gtlds/：
请注意，第一轮申请中禁止使用数字TLD。申请人指南（http://newgtlds.icann.org/en/applicants/agb）中对数字通用顶级域名（gTLD）的禁止源于对这些域名正常运行的能力的一些技术问题。域名通常用于可以使用其他类型的标识符（如IP地址）的位置。
TLD全部是字母的这一事实通常是软件识别域名的关键决定因素。如果允许使用诸如“.123”的TLD，则域名“74.125.244.123”可能难以与IP地址“74.125.244.123”区分开来。还有其他一些考虑因素：一些技术标准文档指出TLD将按字母顺序排列，这也已被编成软件假设。
AGB对字母字符的限制旨在限制这些场景，这意味着此类TLD不太可能在软件中很好地工作，并且限制可能由相同问题导致的潜在安全问题。