From the category archives:

Technical

ICANN Website Update

by Chris Gift on May 22, 2014

For some time now, we’ve been building a new website for ICANN in a process we’ve documented elsewhere on this blog. That site went live a few weeks ago and we’ve been directing an increasing number of users from the old ICANN site to the new one over the last few weeks. We proceeded cautiously […]

{ 2 comments }

“.. and I’ve seen it before .. and I’ll see it again .. yes I’ve seen it before .. just little bits of history repeating“ History Repeating, Propellerheads featuring Shirley Bassey As the Internet began to grow rapidly in the early 1990s it became clear that the classful approach to routing, which had been introduced […]

{ 0 comments }

Do you know IANA?

by Elise Gerich on March 26, 2014

If you ask people what IANA is, you could get a range of answers. Some would say the IANA is Jon Postel, a pioneer of the early Internet.. Others might ask, “Could you spell that for me?” We hear “IANA” thrown around a lot these days and it’s clear most people aren’t clear at all. […]

{ 0 comments }

Laying the Groundwork for the IANA Transition

by Theresa Swinehart on March 26, 2014

We started dialogue this week at ICANN’s 49th meeting in Singapore on the next steps to take following the United States government’s announcement on 14 March that it would transition key Internet domain name functions to the global multistakeholder community. I’ve heard some people call it "a process to begin a process": yes, it is […]

{ 0 comments }

First Middle East DNS Forum Overwhelmingly Successful

by Baher Esmat on February 11, 2014

by Baher Esmat and Fahd Batayneh There are a plethora of untapped opportunities in the Middle East’s domain name sector, both in existing domain names and new ones. Last week’s Middle East DNS Forum, held in Dubai, confirmed just that. These opportunities lie in not only new gTLDs, but also in the regional ccTLDs that […]

{ 7 comments }

Managing Name Collision Occurrences

by Dave Piscitello on December 6, 2013

The topic of name collisions has received considerable attention in the DNS and Internet communities over the past several months. A name collision occurs when an attempt to resolve a name that is used in a private name space (e.g., a non-delegated Top Level Domain, or a short, unqualified name) results in a DNS query […]

{ 0 comments }

管理域名冲突事件

by Dave Piscitello on December 6, 2013

过去几个月间,域名冲突这一主题已经在域名系统和互联网社群中引起了广泛关注。在尝试解析用于私营域名空间中的一个域名时(例如:非授权顶级域名或短小的不合格域名),导致对公共域名系统进行DNS查询,且在公共域名系统中存在一个相符合的域名,此时即出现了域名冲突。 域名冲突事件并非是个新问题,此前在对域名系统根域下的非授权顶级域名的查询 [PDF, 507 KB]一文中也曾经观察到这一问题并对此进行了汇报。鉴于已经申请的新顶级域名字符串与一些在私营网络中已经使用的域名标签发生了重合,因此域名冲突事件又再次引起了人们的关注。 ICANN已经针对该问题对互联网用户带来的潜在影响进行了多项调查研究 [1 (PDF, 3.34 MB), 2]。通过这些调查研究,我们得以观察到出现错误域名导向查询的一些症状,确认这些查询的大致来源和成因,并提出参考补救(缓和)措施。 针对域名冲突问题需要治本不治标 不论是在医药学或是互联网安全方面,常识告诉我们需要治本不治标。拦截或吸纳域名或URL来防止设备上的恶意软件同一个僵尸网络命令或控制中心相联系的方式实际上是治标的一种方式 [3 (PDF, 386 KB), 4]。这种对策能够缓和并减少风险,但问题的影响和威胁依然存在。确认受到影响的设备、删除恶意软件、同时卸除僵尸网络则是治本的范例[5],这种措施更受青睐,并可能是一劳永逸。 在应对域名冲突方面,拦截或延缓对已经申请的顶级域名的授权属于治标,但同样忽略了一个重要的内容:域名冲突是无意中对公共域名系统根域空间进行的顶级域名查询。有时,对域名的访问可从其私营域名空间中”渗透”出来。 因此,私营域名空间和简短的不合格域名的使用是导致域名冲突的主要原因。这种使用方式有许多原因,包括:协议选择、用户便利、申请设计或实施假设。配置混淆、选择或错误也是人们常提到或观察到的导致无意间对根域进行查询的几种原因。这些原因持续存在也有好几个理由。不论原因如何,许多企业也许都希望从其指定私营域名空间中减少域名查询渗漏的问题。 ICANN也正在采取措施缓解域名冲突的症状。这些措施已经发布在《新gTLD域名冲突事件管理计划》一文中,并有意为各企业提供一定时间完成以下工作: 调查其内部域名,确认其所提交的查询内容中是否包含公共域名系统根域下的非授权顶级域名 评估这些查询是否对其企业构成了不可接受的风险,和 确定将如何缓和风险。 ICANN和新顶级域名申请人将要推行的框架措施属于诊断性和遏制性措施,并不能够解决根本性的原因。而使用私营域名和/或简短的不合格域名的企业则有责任做出决定来根治这一问题。在域名冲突讨论的过程中经常忽略这一事实:只有那些将查询错误导入公共域名系统的企业才能正确认定其是否面临着风险,也只有他们才能够采取措施来缓和风险,满足其自身的需求。 ICANN已经咨询了一批主题问题专家,以针对简短不合格域名的使用问题编制一份缓和措施报告。这份报告的主要结论和建议请参见《针对IT人士提出的域名冲突认定和缓和措施指南》 [PDF, 372 KB] 一文,其具体内容包括: 若导致域名冲突的原因是对简短不合格域名的解析,则通过公共域名系统对完全合格域名的解析就是–种适当的推荐解决方式。 本报告描述了当内部域名渗入到全球域名系统中时,各企业可能遇到的问题,并为许多企业提出了实际可行的参考补救措施。本报告将从域名系统中分出来的私营域名空间视作使用自有顶级域名的私营域名空间和使用搜索清单而创建的私营域名空间。 本报告建议,任何尚未使用公共域名系统中的FQDN的企业应当考虑采取以下战略措施。简而言之,本报告向您提出的建议如下: 监控域名服务,编制一份私营顶级域名或您在内部使用的简短不合格域名的清单,并将这份清单与新TLD字符串清单进行比对。 制定一份计划减少渗漏的原因;例如,若您需要使用在全球域名系统中已经注册的一个域名,您则需要变更您的私营域名空间的根域,或将受到影响的系统转换成为使用FQDN。 一旦域名使用即将发生变化,则应提前告知用户,或提供相关培训。 实施您的缓和计划。 在域名服务器处和您的网络边界处持续监控旧私营域名和新FQDN的使用情况,利用这些数据对您可能发现的问题进行及时处理,缓解任何渗漏现象。 这类缓和措施是十分必要的,且对于IT管理人员来说也并不陌生。正如我们有必要在边缘网络中发现受到影响的电脑,并移除恶意软件一样,我们也有必要在边缘网络中找到并消除导致内部域名缺陷的原因。另外一个比较重要的内容是:注意已经使用公共域名系统中FQDN的企业无需考虑这些措施。不论哪些新顶级域名获得授权,或是授权数量如何,这些企业将发现其对域名系统下的域名的使用不会发生任何变化。 尽管可能存在中期或临时解决方案,但启用FQDN仍旧有着持续的意义—一旦您采取了这一措施,您在新顶级域名授权方面可谓是无须担忧、一劳永逸。

{ 0 comments }

В последние несколько месяцев в сообществах DNS и интернета теме совпадения имен уделяется много внимания. Имена совпадают когда, при попытке разрешить имя, использующееся во внутреннем пространстве имен (т.е. в неделегированном домене верхнего уровня или в коротком, неопределенном имени) запрос, адресуется глобальной системе DNS, и в глобальной системе DNS существует имя, полностью совпадающее с именем, использующемся […]

{ 0 comments }

Gestion de l’occurrence de collisions de noms

by Dave Piscitello on December 6, 2013

La question des collisions de noms a fait l’objet d’une attention considérable dans les communautés du DNS et de l’Internet au cours des derniers mois. Une collision de noms se produit lorsqu’une tentative de résolution d’un nom utilisé dans un espace de noms privé (par exemple, un nom de domaine de premier niveau non délégué […]

{ 0 comments }

Gestión de incidentes de colisiones de nombres

by Dave Piscitello on December 6, 2013

El tema de las colisiones de nombres ha sido objeto de la considerable atención de las comunidades del DNS e Internet en los últimos meses. Una colisión de nombres se produce cuando se intenta resolver un nombre en un espacio de nombres privado (por ejemplo, un dominio de alto nivel no delegado, o un nombre […]

{ 0 comments }