Archive for the ‘DNS’ Category


Potential Name Space Collision Report’s Impact on Contracting

Posted August 28th, 2013


As ICANN previously announced, we commissioned a study to consider the likelihood and impact of name space collisions between applied-for new gTLD strings and non-delegated TLDs. In light of that study, ICANN proposed to the community several possible mitigation measures, including:

  • Proceeding with contracting and delegation of those strings categorized as “low risk” (80%) but recommending additional mitigation measures which should not materially impact their timeline for delegation.
  • Conducting further study on those strings categorized as “uncalculated risk” (20%) anticipated to take 3-6 months to complete.
  • Delaying contracting and delegation of the two “high risk” strings until mitigation efforts can place them in the “low risk” category.


ICANN has solicited community comment on the mitigation steps outlined in the staff recommendation paper, with a comment close date of 27 August 2013 23:59 UTC. Pending receipt of community feedback on the staff mitigation proposals, ICANN intends to proceed with New gTLD applications as follows:

  • Low Risk – Eligible applicants will be invited to begin contracting and may proceed through contract execution of a Registry Agreement. Delegation of Low Risk strings will be held until we have evaluated community comments and settled on appropriate mitigation measures.
  • Uncalculated Risk – Eligible applicants will be invited to begin contracting. Execution of registry Agreements will be held until we have evaluated community comments and settled on appropriate mitigation measures.
  • High Risk – Applicants will not be invited to begin contracting until we have evaluated community comments and settled on appropriate mitigation measures.

We encourage the community to submit comments on name space collision and appropriate mitigation measures to assist ICANN in considering these matters.


For further information from ICANN on Name Space Collision, go HERE.

Posted in DNS, gTLDS, ICANN by  


Collisions among new gTLDs

Posted August 6th, 2013


As directed by the ICANN Board of Directors on 18 May 2013, ICANN commissioned and today releases the results of a study that considers the likelihood and impact of name space collisions between applied-for new gTLD strings and non-delegated TLDs. Additionally, the study also reviewed the possibility of collisions arising from the use of X.509 digital certificates.

Background: In a study published in January 2013, ICANN’s Security and Stability Advisory Committee (SSAC) identified fact that some certificate authorities issue X.509 certificates for domain names that are not resolvable in the public DNS. Such issues identified in SAC 057, as well as in SAC 045, are symptoms of entities that have local environments that include strong assumptions about the number of top-level domains and/or have introduced local top-level domains in private namespaces that may conflict with names yet to be allocated. These private namespaces sometimes “leak” into the public DNS (either through misconfiguration or the use of old software), meaning that requests for resources on private networks could end up querying the public-facing DNS Root Servers and hence “colliding” with the delegated new gTLD.

See the full skinny including the resulting study and ICANN staff recommendations HERE.

Posted in Compliance, DNS, gTLDS, ICANN by  


“The Design of the Domain Name System, Part VIII – Names Outside the DNS”

Posted September 18th, 2011

As posted to by John Levine: “In previous installments we’ve been looking at aspects of the design of the DNS (see part I, II, III, IV, V, VI and VII). In today’s grand finale we look at the the subtle but very knotty issue of names inside and outside the DNS.

In the early years of the DNS, domain names were typically resolved to A records which were used to identify a host running a service. With the notable exception of e-mail, once the host was identified, the name no longer mattered. Another way to look at it is that for traditional services like telnet and FTP, servers don’t know or care what their names are. If you want to give a Telnet server a new name, just point a new A or CNAME record at it, and it’ll work.”

Click HERE to read more.

Tags: ,
Posted in DNS by  


The Design of the Domain Name System, Part V – Large Data

Posted September 2nd, 2011

John Levine posts his fifth installment on The Design of the Domain Name System: “In the previous four installments, we’ve been looking at aspects of the design of the DNS (see part I, II, III and IV). Today we look at the amount of data one can ask the DNS to store and to serve to clients.

Most DNS queries are made via UDP, a single packet for query and a single packet for the response, with the packet size traditionally limited to 512 bytes. This limits the payload of the returned records in a response packet to about 400 bytes, after allowing for the overhead in a DNS response. Many clients and caches (about half in my experience) support the EDNS0 extension, which lets the client specify the maximum packet size, usually 4096. The length fields in DNS records are 16 bits, so the absolute limit on a packet or a record is 64K bytes. The DNS spec says that if a response is too big to fit in a UDP packet, the server sends a partial response with the truncation bit set, which tells the client to retry the query over TCP.”

Click HERE to read more.

Posted in DNS by  


“The Design of the Domain Name System, Part III – Name Structure and Delegation”

Posted August 26th, 2011

John Levine publishes the third installment of The Design of the Domain System at “In the previous installments, we looked at the overall design of the DNS and the way DNS name matching works.

The DNS gains considerable administrative flexibility from its delegation structure. Each zone cut, the place in the DNS name tree where one set of DNS servers hands off to another, offers the option to delegate the administration of a part of the DNS at the delegation point. But for the delegation to work well, the delegation structure has to match the name structure.”

Click HERE to read more.

Posted in DNS by  


The Design of the Domain Name System, Parts 1 & 2

Posted August 24th, 2011

John Levine explains the design of the Domain Name System on “Over the past 30 years the Domain Name System has become an integral part of the operation of the Internet. Due to its ubiquity and good performance, many new applications over the years have used the DNS to publish information. But as the DNS and its applications have grown farther from its original use in publishing information about Internet hosts, questions have arisen about what applications are appropriate for publication in the DNS, and how one should design an application to work well with the DNS.”

Click HERE to read part 1

Click HERE to read part 2

Posted in DNS by  


ICANN – Report on the Assessment of Security and Stability Implications of the Use of DNAME Resource Records in the Root Zone of the DNS

Posted May 24th, 2011

“ICANN commissioned a technical study into the security and stability implications of using the Domain Name System (DNS) DNAME Resource Record [RFC2672] in the root zone of the DNS. Testing was specified to be carried out in a captive lab environment which provided a functional replica of certain components of the public DNS. The results of that testing are presented in this report for the information of the wider DNS technical community.

This report found no failure in resolution nor in the ability to perform DNSSEC validation when DNAME was used in the root zone to provide isomorphism between two top-level domains (TLD), i.e. when one TLD was provisioned as a DNAME, compared to being provisioned as a distinct delegation. A variety of DNS software was tested as part of this study.”

Click HERE to read the report.

Tags: ,
Posted in DNS, ICANN by  


Deployment of DNSSEC in the Root Zone: Impact Analysis

Posted April 14th, 2011

According to ” In 2010 ICANN commissioned a study from DNS-OARC to examine the impact of DNSSEC deployment in the root zone, and in particular the effects on clients from the large DNS responses resulting from the use of a Deliberately Unvalidatable Root Zone (DURZ).

The DNS-OARC study drew upon the results of a coordinated data collection exercise by root server operators, with each data collection window timed to coincide with a transition by one or more root servers from serving an unsigned root zone to serving the DURZ.

ICANN is publishing this report in order to share its findings with the wider DNS community.”

Click HERE to read the report.

Tags: ,
Posted in DNS, DNSSEC, ICANN by  


Whois, DNSSEC and Domain Security: An Interview With Garth Bruen of Knujon

Posted April 1st, 2011

As we are gearing up for major innovation in the domain space, questions of Internet security loom large.

Whois, DNSSEC and New gTLD issues were on the front burner at ICANN 40, so we sat down with Garth Bruen, Internet security expert and creator of Knujon to discuss these topics and more.


Tags: , , , ,
Posted in cybercrime, DNS, DNSSEC, Enforcement by  


When the Internet Nearly Fractured, And How It Could Happen Again

Posted February 24th, 2011

As reported by the Atlantic:

“When the entire country of Egypt was forced offline by its government last month, it served as a global wake-up call that the Internet is a more fragile medium than we imagine it to be. What happened in Egypt was particularly striking, but other, subtler tests of the Internet’s resilience abound.

Turn your eye to the domain name system, for example. Commonly referred to as DNS, the domain name system is the obscure but almost unimaginably important process whereby memorable names like “” get translated into the numbers that actually pinpoint The Atlantic‘s place on the Internet. There, in the innards of the Internet, there’s controversy brewing. The Department of Homeland Security’s Immigrations and Customs Enforcement division and the Department of Justice have been targeting domain names for takedowns, and the United States Senate is considering a bill that would empower the Attorney General to blacklist website names from the Internet’s directories.

But this isn’t the first time that DNS has been a contested space. In one particularly curious episode from the modern Internet’s early days, a man named Eugene Kashpureff ignited a battle over the future of the global network that brought him face-to-face with the Royal Canadian Mounted Police.”

Click HERE to read the full article.

Tags: , , ,
Posted in cybercrime, DNS by