This is advance notice that there is a scheduled change to the IPv4 address for one of the authorities listed for the DNS root zone and the .ARPA TLD. The change is to D.ROOT-SERVERS.NET, which is administered by the University of Maryland.

The new IPv4 address for this authority is 199.7.91.13.

The current IPv6 address for this authority is 2001:500:2d::d and it will continue to remain unchanged.

This change is anticipated to be implemented in the root zone on 3 January 2013, however the new address is currently operational. It will replace the previous IP address of 128.8.10.90 (also once known as TERP.UMD.EDU).

We encourage operators of DNS infrastructure to update any references to the old IP address, and replace it with the new address. In particular, many DNS resolvers have a DNS root “hints” file. This should be updated with the new IP address.

New hints files will be available at the following URLs once the change has been formally executed:

• http://www.internic.net/domain/named.root
• http://www.internic.net/domain/named.cache

The old address will continue to work for at least six months after the transition, but will ultimately be retired from service.

The Internet has boomed in the intervening years and exceeded all our expectations. It now has a fundamental place in the economies of nations around the globe. The boom has gone so far that on February 3rd I allocated the last five blocks of IPv4 addresses from IANA’s central pool to the Regional Internet Registries (RIRs). The RIRs will allocate those IPv4 addresses to the networks in their regions in the coming months and maybe years.

The Internet uses IP addresses for its infrastructure, for the content we access and for the connections of ordinary Internet users. Recent studies indicate that approximately 2 billion people around the world have access to the Internet. And many of those 2 billion people may use 2 or more devices (computers, mobile phones, cable modems) that require an Internet address to deliver the service they want. The few billion addresses in IPv4 are barely enough for the services offered to 2 billion people much less for a world with a population of almost 7 billion.

There will be a period of transition and it will take time for the primary IPv4 infrastructure of the Internet to be replaced by IPv6 infrastructure. That transition will happen though because using the Internet has become an economic driver in all parts of the world.

I want to repeat the call I made in 1995 today because unique addresses are still good. And I urge everyone who anticipates building new Internet services, equipment and connections to provide support for globally unique IPv6 addresses. Having the wealth of unique addresses that IPv6 offers removes constraints that were placed upon innovation by the restricted availability of essential Internet addresses. IPv6 will enable the Internet’s future growth and there will be new opportunities for those already using the Internet as well as for those who will soon begin using it.

What you should be seeing is something like the following:

It even works on a mobile phone:

The three new top-level domains are السعودية. (“Al-Saudiah”), امارات. ( “Emarat”) and مصر. (“Misr”). All three are Arabic script domains, and will enable domain names written fully right-to-left. Expect more as we continue to process other applications using the “fast track” methodology.

ICANN staff are still finishing the processing of these domain’s delegations, but now that they are visible in the root zone it is fair to say these are mostly formalities. The remaining tasks include final technical verifications, updating the IANA WHOIS database and publishing the delegation reports.

Now the hard work happens in the countries which have their new IDN ccTLDs. They will now commence their own processes to launch the domains in a way that gives their communities access to put them to day-to-day use.

The problem is that the unofficial usage makes it more difficult for ISPs to bring these addresses into use when they are officially allocated and so less desirable. But we have to allocate IPv4 addresses to the RIRs as long as we still have them and they still request them. We just need to implement a mechanism to select which /8 is allocated to which RIR.

The mechanism we have implemented reserves two of the /8s showing the least unofficial use for each of the newest RIRs. AfriNIC and LACNIC have fewest IPv4 /8s and service the regions with the most developing economies. We decided that those RIRs should have four of the easiest to use /8s reserved for them.

The other /8s are split between two pools and when APNIC, ARIN or the RIPE NCC qualify for additional IPv4 address space they will be allocated one /8 from each pool, with the /8 being chosen using a verifiable random selection mechanism. The mechanism is based on the “Publicly Verifiable Nomcom Random Selection” mechanism described in RFC 2777.

The sources of randomness used are the prices of the FTSE 100, Dow Jones Industrial Average and Hang Seng Index from midday at the exchange site the day after the request is received, as published on the Yahoo! Finance web site.

The pool of /8s which have been used to number IP networks in an unofficial and improper way is larger than the other pool. So when the smaller pool runs out, all allocations to APNIC, ARIN and the RIPE NCC will come from the larger pool until it too is empty. Then, if any of the /8s reserved for AfriNIC and LACNIC have not been allocated they will become part of a single pool used for all RIRs.

Of course, when all of this is done, there are still five /8s set aside for the implementation of the Global Policy for the Allocation of the Remaining IPv4 Address Space. Very little use of those /8s was detected in our 2008 research.

As has been discussed a lot lately, the DNS does not have much in the way in inherent security mechanisms. DNSSEC is a newer technology designed to remedy that by adding a layer of cryptographic verification to the DNS. By using DNSSEC, DNS data can be checked and verified to make sure it has not been tampered with in transit over the unprotected Internet.

Key to deploying DNSSEC is deploying it at the root zone level. The root zone is the upper most level in the DNS hierarchy, and is managed under a complex arrangement involving not only ourselves, but also VeriSign and the US Government. Right now, consultations are being made on how best to secure the root zone using DNSSEC, and that discussion is expected to carry on for some time. It is a somewhat political debate, as well as a technical discussion on how to maintain the robustness of a service that is the cornerstone of Internet stability.

The community has recognised that discussion will undoubtedly carry on for some time, but that there is an immediate need to support nascent DNSSEC deployment efforts. To do this a trust anchor repository was proposed, with ICANN requested to operate the service. A trust anchor repository would be a place to hold the security information that would be in the root zone if it were signed. For example, the Swedish country code top-level domain .SE has already implemented DNSSEC, and their trust anchors can be found in the repository. This allows for early adopters who have suitably configured DNSSEC software to obtain that security information independent of the DNS, without waiting for the root zone to have DNSSEC implemented.

Today we have released the first public version of the trust anchor repository after some initial experimentation with some of the core DNSSEC engineering community. We have prepended the word “interim” to its name, just to emphasise that this isn’t permanent, and is only designed to be a stepping stone to the ultimate goal of a DNSSEC-signed root zone.

We do not recommend it for use other than by expert administrators. It is experimental and requires some understanding of DNSSEC to be helpful. We think it will be useful in giving everyone involved better operational experience with DNSSEC, as well as being a helpful nudge on the way toward more universal DNSSEC deployment on the Internet. As a temporary solution, it has its caveats, and we recommend not treating it as an ultimate solution. But with that in mind, we look forward to those who are feeling adventurous to give it a try and provide us with feedback on how we can improve the service.

Last year, we shared some concepts with the community on how we’d like to improve it. First and foremost was making IANA’s purpose clear, and its key information easy to find. Based on the initial feedback, we are almost ready to launch a completely new IANA web site.

We have literally begun from scratch. All web pages have been rewritten, and their place on the website rethought. We are working towards fully standards compliant pages that work in many different browsers. We have also tried to lay a foundation so we can much more easily add new materials and features to the IANA website once it is launched.

So now that we have almost finished the conversion of the site, it is a great opportunity to offer a sneak peek and gather feedback on the almost final product. Our aim is to integrate your feedback, as well as tidy up the remaining rough edges, over the next few weeks. Once we are confident everything is working, we will then replace the existing IANA site.

The new site is at http://beta.iana.org/. Take a look and tell us what you think in the comment area below.