Skip to main content

新gTLD冲突事件管理计划常见问题解答

ICANN的使命和核心价值要求ICANN维护并加强互联网唯一标识符系统(域名、IP地址和协议参数)的运营稳定性、可靠性、安全性和全球互用性。ICANN在寻求实现这些目标,遵守董事会指示的同时,还需考虑安全和稳定咨询委员会提出的建议,ICANN已授权一项研究调查已提交申请的新gTLD字符串可能带来的潜在安全隐患。该项研究旨在找出已申请的新gTLD字符串和私营域名空间中现在使用的域名("未授权的顶级域名")之间是否可能出现域名冲突问题。该研究还将用来审核已经获得X.509数字证书的内部域名的使用是否可能会导致域名冲突事件。

当用户希望访问私营网络空间中的某一域名的资源时,却在不知情的情况下访问了在公共域名系统中获得授权的同一域名资源,此时即出现了域名冲突。这种私营域名空间和公共域名空间出现管理重叠的现象以及对域名问题的解决可能导致出现无意间造成的后果、带来担忧,因此如有可能应当避免出现这种现象。但,域名冲突事件本身并不会给人带来忧虑,令人担忧的是,这种冲突事件是否可能导致无法预料的行为或损害;以及这种无法预料的行为或损害的本质到底如何;以及这种情况所造成的后果的严重性如何。

2013年8月5日,ICANN发布了一份有关域名冲突调查研究的文件:<http://www.icann.org/en/about/staff/security/ssr/name-collision-02aug13-en.pdf> [PDF, 3.34 MB] (以下简称"本调查")。本调查通过观察从DNS-OARC的"互联网一生中的一天"(以下简称"DITL")的项目中搜集的根服务器日志抽样数据,根据查询的情况对字符串进行分类。本调查使用的数据包括:1)DNS请求传输至根服务器(通过DITL项目)的抽样数据,和2)发放内部域名证书的认证机构信息(例如:针对非授权域名提供的TLS/SSL认证)。有关本调查的方法论详细介绍请参见本调查的第3.4节。

本调查还包含缓和风险所用的各项措施;但该调查并未针对每个类型的字符串提出具体的建议。根据本调查结果,ICANN员工已将管理域名冲突风险的提案发布到了网上,并在2013年8月5日至9月17日之间征询公众意见,具体链接为: <http://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf> [PDF, 166 KB]。

2013年10月7日,ICANN董事会新gTLD项目委员会采纳了一份修订案<http://www.icann.org/zh/groups/board/documents/resolutions-new-gtld-07oct13-zh.htm#1.a>,该修订案描述了管理新gTLD和同样字符串在现有私营网络中使用所导致的域名冲突事件的管理计划。

以下是针对这一计划的常见问题和ICANN给出的解答。

  1. ICANN如何编制一份需要在授权替代路径中拦截的二级域名(SLD)清单呢?

    对于每个顶级域名旗下需要拦截的二级域名清单是由在2006年至2013年中"DITL"项目抽样中该顶级域名中被查询的二级域名和2010年DNSSEC扩展数据集中的信息所组成。

  2. 认定新gTLD不符合授权替代路径资格的标准是什么?

    新gTLD中,每年旗下被查询的二级域名清单数量持续增加的、出现异常值的情况则被视作不合格。换句话说,ICANN认为,新gTLD旗下的二级域名清单频繁而广泛地出现变更时,则认定该新gTLD不符合获得授权替代路径的资格。

    编制二级域名变体清单所使用的数据源将由2006年至2012年间搜集的域名系统查询数据构成。2013年数据集并未包含其中,因为这一年的字符串数据在当时已经公开了(对已知字符串展开各项活动或研究则可能导致分析偏差)。与(a)至少一次年环比和(b)2012年(显示目前出现的问题)的拟定gTLD数量相比较,二级域名查询数量呈年度递增的情况被视为异常值。

    例如,若一个顶级域名仅在2006-2007年期间的比较中出现异常值,则应仍旧被视为符合资格。但若一个顶级域名在2009-2010年和2011-2012年的比较中均呈现出异常值,则不符合获得授权替代路径的资格。

  3. 在域名冲突事件管理框架中使用其他数据库时,是否需要对二级域名(SLD)拦截清单进行修订?

    鉴于本框架的编制情况,暂时对新gTLD的二级域名拦截清单尚未制定修订计划。然而,若在框架编制过程中有了新的发现,则可能对这一问题加以考量。

  4. 生成拦截清单的源代码是否可用?

    每个授权替代路径报告将针对每个已经签署协议的合格新gTLD的情况,对生成拦截清单的流程进行详细描述。如需参考范例,请参见:http://www.icann.org/en/about/agreements/registries/luxury/luxury-apd-report-12nov13-en.htm

    生成清单的代码则基于以下页面中发布的代码:https://github.com/JASdevteam/dns-oarc

  5. 拦截清单中的二级域名需要被拦截多长时间?

    在相应的《域名冲突事件评估》中确定的缓和措施实施之前,该域名应当持续处在被拦截状态。

  6. 对于某一具体的顶级域名,若二级域名"nic"出现在了DITL的数据中(显示此处可能出现了域名冲突),为什么"nic"仍旧允许在gTLD中出现?为何这一风险比其他域名冲突的风险显得更易被接受呢?

    根据合同规定,唯一可用该字符串的域名为"whois.nic.<顶级域名>",旨在用于提供注册局WHOIS服务,即"whois.nic.<顶级域名>"。为了平衡该域名的使用风险和WHOIS服务在熟知的地址上的可用性,ICANN决定在任何新gTLD的二级域名清单中不拦截"nic"这一字符串。然而,域名冲突回应机制<http://www.icann.org/zh/help/name-collision>则用于受到影响的相关方针对该域名所构成的严重损害而提交报告。同样还需注意的是,该域名仅限于注册局运营商自身使用,即意味着注册局对这一二级域名拥有完全控制权。

  7. 域名被查询的当年,ICANN是否需要对二级域名拦截清单进行更新?

    ICANN暂无计划对二级域名拦截清单进行更新,或将二级域名被查询的当年添加进来。然而,若社群对此有意,则ICANN将考虑在资源可用时将这些数据添加进来。

  8. 若二级域名拦截清单中的域名在商标信息交换中心(TMCH)的日升期和索赔期被释放,应当作何处理?

    根据注册局的一贯政策,日升期和索赔期中必须包含某个顶级域名的二级域名拦截清单中的域名,但直到缓和措施施行之前,这类域名不得被激活。若一名注册局运营商在日升期或索赔期将二级域名拦截清单中的域名分配了出去,则必须告知注册人该域名不得被激活,且根据该顶级域名的《域名冲突事件评估》,该域名也许永远也不能被激活。

    此处是对《域名冲突事件管理计划》第3.2节内容的澄清。编制拦截清单旨在防止在新gTLD授权之前出现不当行为(例如:NXDOMAIN对域名系统的响应);而实现这一点则需要不对清单中的域名进行激活,不论该域名是否已被分配。

  9. 什么危害可能导致中止对构成冲突的二级域名的使用?

    可能出现这种情况,即某些尚未出现在二级域名拦截清单数据集中的二级域名发生了域名冲突事件,且该冲突事件可能在已申请的gTLD启动运营之后出现。为了缓和这一风险,ICANN已经推行了一项流程,使得在近期激活的域名出现域名冲突后导致严重损害时,所有相关方都能汇报并请求对该域名采取临时拦截的措施。

    ICANN将做为这类报告的唯一初始联系人,并协调与相关注册局运营商的通知程序,以确保对该报告的内容尽快采取行动。ICANN将根据每个案例的情况进行初始损失评估,直至本框架确定统一标准为止。

  10. 是否需要设置域名冲突端口?

    ICANN将计划使用一个端口来显示有关这一主题的可用信息。

  11. 《域名冲突事件管理框架》的范围中是否存在各种不同类型的试授权?

    是的,本框架的编制过程中将同时考虑顶级域名(不符合授权替代路径的顶级域名)和所有新gTLD旗下的二级域名的试授权问题。本框架一旦得以采纳,则预计将对某一特殊冲突类型指定适用的试授权流程。

    此外,ICANN董事会在布宜诺斯艾利斯会议上通过了一项决议,指示员工对安全和稳定咨询委员会(SSAC)的《SAC 062号报告》进行评估,该报告明确请求ICANN考虑采用试授权的制度。

  12. 如何确认《域名冲突事件管理框架》的编制工作已经完成?如何确认是否应当采纳这一框架?

    首席承包商将预计与社群一起合作,制定一份《框架》草案文件,详情请参见:<http://www.icann.org/zh/news/announcements/announcement-2-11nov13-zh.htm>。这份《框架》草案文件将发布到网上征询公众意见。公共评议期结束之后,所有评论将被集合成一份总结文件,且这份《框架》草案文件也将根据公众的建议进行修订。最后,ICANN董事会的新gTLD项目委员会将确定是否采纳《框架》终稿。

  13. 人们该如何参与《域名冲突事件管理框架》的编制?

    欢迎任何人参与到《框架》文件的编制工作中来。本《框架》文件将在以下的公共邮件清单链接中展开讨论: <https://lists.dns-oarc.net/mailman/listinfo/collisions>。

  14. 域名冲突管理是否还将被用于ccTLD?

    域名冲突问题首次向ICANN汇报时是针对新gTLD项目而提出的。鉴于新gTLD的数量是可以预计的,因此目前首要的工作主要关注在新gTLD方面。但我们也认识到这一问题并不仅限于gTLD;因此ICANN将把这一问题提交至董事会风险委员会,以确认该如何处理这一问题。


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."