The new program is designed to enable a broad range of cloud partners, such as Internet service providers, hosting providers, data centers, and information security and consulting firms, to sell or refer Neustar's managed services to their existing customer base. Leveraging Neustar's marketing and sales resources allows partners to offer these services quickly and seamlessly.

The Global Partner Program offers two levels of support. Reseller Partners can manage the sales of Neustar services to their customers. In addition to managing sales, Strategic Alliance Partners can take advantage of Neustar's resources to jointly market and sell the services.

"Enterprises seek a simple but comprehensive way of managing their foundational online services," said Alex Berry, senior vice president and general manager of Enterprise Services at Neustar. "By extending our world-class infrastructure services to those who serve these customers, our partners will be able to create a turn-key, value-add offering for their customers' online presence."

The infrastructure services available to partners include:

• Managed DNS Services to ensure fast, accurate responses to online routing queries so customers reach their online destination without interruption or delay.
• DDoS Protection Services to defend against increasingly sophisticated Distributed Denial of Service (DDoS) attacks that can cripple businesses of any size

"We're focused on boosting return on investment for our partners, helping them create a lucrative new revenue stream while minimizing upfront investment," said Kurt Gastrock, senior vice president of sales for Enterprise Services at Neustar. "We expect partners will find this expanded and newly structured program to be an excellent fit with their business objectives and their customers' needs."

Visit Neustar's Global Partner Program website for more information about becoming a reseller of Neustar's trusted infrastructure services.

Irina Bokova, Director-General, UNESCO

Today, Irina Bokova, Director-General of UNESCO has released a statement concerning the linguistic diversity on the Internet stating: "UNESCO's experience and the 2012 study of the use of internationalized domain names undertaken with EURid show that the main challenges are technical. Obstacles lie with Internet browsers that do not consistently support non-ASCII characters, with limited e-mail functionality, and with the lack of support of non-ASCII characters in popular applications, websites and mobile devices."

Below is an excerpt from the 70-page EURid-UNESCO 2012 report:

This year, the data set for this study is expanded from 53 to 88 TLDs, and includes 90% of all domain names registered as at December 2011, albeit that the data set is not complete for every parameter. The World Report includes case studies on the ccTLDs for the European Union, Russian Federation, Qatar, Saudi arabia, Egypt and the Republic of korea. Where an existing registry has launched an IDN ccTLD (for example, .sa and السعودية.) these are considered as two separate entities for the purpose of the report.

Part 1 of the World Report on IDN deployment sets out a background to IDNs and a timeline. It considers progress in supporting IDNs in email and browsers. It then reviews the IDN applications in ICANN's programmes to create new TLDs. A comparison of growth rates of IDN registrations versus general registrations is made within European registries and usage rates are compared amongst .eu and .рф IDNs and benchmarked with other TLDs. Case studies follow, on the European Union (.eu) ccTLD, and country case studies on the Russian Federation, Qatar, Saudi arabia, Egypt and the Republic of korea.

Also noteworthy is the included foreword in the report by Vint Cerf (excerpt below) on the historical adoption of simple Latin characters in the early days of the Domain Name System (DNS). Cerf writes:

"For historical reasons, the Domain Name System (DNS); and its predecessor (the so-called "host.txt" table) adopted naming conventions using simple Latin characters drawn from the letters a-Z, digits 0-9 and the hyphen ("-"). The host-host protocols developed for the original aRPaNET project were the product of research and experimentation led in very large part by English language speaking graduate students working in american universities and research laboratories. The project was focused on demonstrating the feasibility of building a homogeneous, wide area packet switching network connecting a heterogeneous collection of time-shared computers. This project led to the Internetting project that was initially carried out by researchers in the United States of america and the United kingdom, joined later with groups in Norway, Germany and Italy, along with a few visiting researchers from Japan and France. The primary focus of the Internetting project was to demonstrate the feasibility of interconnecting different classes of packet switched networks that, themselves, interconnected a wide and heterogeneous collection of timeshared computers.

For technical reasons, support for non-Latin scripts was treated as a design and deployment problem whose solution was intended to minimise change to the domain name resolution infrastructure. This was debated in the Internet Engineering Task Force more than once, but the general conclusion was always that requiring a change to every resolver and domain name server, rather than changes on the client side only, would inhibit deployment and utility. This led to the development of so-called "punycode" that would map Unicode characters representing characters from many of the world's scripts into aSCII characters (and the reverse). This choice also had the salient feature of making unambiguous the question of matching domain names since the punycoded representations were unique and canonical in form. This design is not without its problems but that is where we are at present."

IDN introduction timeline – Source: EURid-UNESCO World report on Internationalised Domain Names deployment 2012 (Click to Enlarge)

The full report can be downloaded here in PDF here: EURid-UNESCO World report on Internationalised Domain Names deployment 2012

BIND is the most popular open source DNS server, and is almost universally used on Unix-based servers, including those running on Linux, the BSD variants, Mac OS X, and proprietary Unix variants like Solaris.

A flaw was recently discovered in the regular expression implementation used by the libdns library, which is part of the BIND package. The flaw enables a remote user to cause the 'named' process to consume excessive amounts of memory, eventually crashing the process and tying up server resources to the point at which the server becomes unresponsive.

Affected BIND versions include all 9.7 releases, 9.8 releases up to 9.8.5b1, and 9.9 releases up to version 9.9.3b1. Only versions of BIND running on UNIX-based systems are affected; the Windows version is not exploitable in this way. The Internet Systems Consortium considers this to be a critical exploit.

All authoritative and recursive DNS servers running the affected versions are vulnerable.

The most recent versions of BIND in the 9.8 and 9.9 series have been updated to close the vulnerability by disabling regular expression support by default.

The 9.7 series is no longer supported and those using it should update to one of the more recent versions. However, if that is not desirable or possible there is a workaround, which involves recompiling the software without regex support. Regex support can be disabled by editing the BIND software's 'config.h' file and replacing the line that reads "#define HAVE_REGEX_H 1" with "#undef HAVE_REGEX_H" before running 'make clean' and then recompiling BIND as usual.

At the time of the initial report, ISC stated that there were no active exploits for the vulnerability, but a user reported that he was able to develop and implement a working exploit in ten minutes.

While most of the major DNS providers, including DNS Made Easy, have patched and updated their software, DNS software on servers around the Internet tends to lag behind the most recent version. Because BIND is so widely used and DNS is essential to the functioning of the Internet, knowledge of this vulnerability should be disseminated as widely as possible to encourage system administrators to update.

It should be noted that this exploit is totally unrelated to the widely publicized problems with the DNS that allows criminals to launch DNS amplification attacks. Those attacks depend on a misconfiguration of DNS servers rather than a flaw in the software. However, both problems can be used to create a denial of service attack. Open recursive DNS servers can be used to direct large amounts of data at their targets; effectively using DNS as a weapon to attack other parts of the Internet's infrastructure, whereas the regex vulnerability could be used to attack the DNS itself.

Written by Evan Daniels

RU-CENTER is the largest Russian registrar in a market that is dominated by three companies. RU-CENTER and competitor Reg.Ru both manage around 28% of domains registered in the country's national suffix .RU, whilst a third registrar R-01 (also part of the RU-CENTER group of companies) has 18%.

RU-CENTER is also a figurehead for Russia's drive to make Internet use more palatable for those who are not natural ASCII writers. Because the Latin alphabet has been the only available option to browse the Internet up until now, and because Russian Internet users learn Latin characters anyway, having to use a foreign script has not dampened their drive to get online and reap the Web's many benefits.

But give them a chance to type in Cyrillic, and Russians jump at it. That became evident when the country launched its own Cyrillic country code, Dot RF (Latin script spelling). Pent up demand for full local language web addresses meant Dot RF exceeded all registration expectations as soon as it went online. Now in its third year, the TLD already has almost 800,000 registrations compared to the 4.5 million names in Russia's original (ASCII) ccTLD Dot RU.

That trend could grow as the new gTLD program allows further Cyrillic script suffixes to be created on the Internet. "Even with new gTLDs, it seems the market is underestimating the potential for Cyrillic domains," says RU-CENTER's Marketing Director Pavel Khramtsov. "We've only seen 8 IDN applications in Cyrillic script in this first round."

By initiating the implementation of Dot Moskva, RU-CENTER became one of these Cyrillic IDN pioneers. The domain is one of a pair, the other being the Latin character version Dot Moscow (www.domainmoscow.org). "That's where we expect the highest demand to come from," explains Sergey Gorbunov, head of RU-CENTER's International Relations division. "Because Russians have become so used to Latin characters as the default that the ASCII string "moscow" is likely to be considered the more recognisable brand when they both launch."

But the Muscovite pair may help change that. On top of the hunger for Cyrillic URLs that Russians have shown through Dot RF, the Moscow twins stand to help further the Cyrillic IDN cause because of their geography. The majority of people accessing the Internet in Russia do so from the Moscow area. "On average, around 40% of the total pool of Dot RU and Dot RF domains are registered by people from Moscow area," Gorbunov says. The country as a whole has an Internet penetration rate of around 70%, with up to 50 million Russian going online every day, making Russia the number one source of Internet users in Europe (European economic power-weight Germany is number two). But most of that traffic comes from Moscow.

So having a local script TLD for Russia's Capital may make the rise of the Cyrillic script on the Internet even more of a reality. Both TLDs have been prepared and applied for with the support of the local authorities. The project is being coordinated by a non-profit foundation called the Foundation for Assistance for Internet Technologies and Infrastructure Development (www.faitid.org), or FAITID for short (pronounced "fated"). FAITID's governance structure is based on the multi-stakeholder model and brings together users, local government, business and industry to ensure that Dots Moscow and Moskva serve the local Internet community. As an example, FAITID and Moscow city officials are working on reserving a number of second level domains such as school.moscow or museum.moscow for public service use.

The plan was to launch both TLDs at the same time. "For domains like Dot Moscow and Dot Moskva, it's easier to launch them as one, with a single roll-out and marketing plan," says Gorbunov. "It also means less confusion for the end-user." But ICANN's prioritisation draw put paid to those plans. As an IDN, Dot Moskva was a priority application in the December 2012 draw used by ICANN to determine the processing order for the 1930 applications it has received. Moskva drew number 69, as compared to Dot Moscow's 881. A huge gap which means the only way for both launches to coincide is for one to be put on hold whilst the other can play catch-up. "Because of the draw results, FAITID is now planning a long Sunrise period for Dot Moskva before moving on to initiate the rest of the launch schedule when Dot Moscow gets the green light," Gorbunov reveals.

It's still unclear when that would be. Partly because of general contract negotiations currently going on between ICANN and both the registrars and the registries, which need to be resolved before ICANN can put contracts on the table for new gTLD operators to sign. But even when that happens, Moscow will have to wait for more contract negotiations to be done. This time, it will be direct talks between FAITID and ICANN. "The current registry contract as proposed has clauses which are illegal under Russian law," Gorbunov explains. "We also have problems with the trademark clearinghouse because Russian law requires FAITID to give Russia trademarks priority. So doing a Sunrise where the trademarks registered in the clearinghouse get priority is a challenge."

FAITID is hoping for a November Dot Moskva Sunrise. That assumes 2 months for these specific contract negotiations so that the foundation no longer finds itself between a rock and a hard place, having to decide whether to stand foul of its national law by signing the ICANN contract as-is, or to refuse the contract and risk having to give up on its TLD application.

That would be a pity for the millions of Internet users around the world who want to be able to type their web addresses in their own alphabet. Especially as Russia's innovative and cutting-edge Internet community could push the IDN system as a whole to new heights. "Email use remains limited with IDNs," says Khramtsov. "Most of the systems currently available can only work if both sender and receiver use the same technology provider. But this limited use does have some advantages. Spam is non-existent with Dot RF emails for example, because the technology for doing IDN spam just isn't there."

Imagine an Internet where spam is heavily reduced by applying new techniques first developed for namespaces which are younger and can therefore afford to start afresh and apply new solutions to problems which have plagued the ASCII Internet since its inception. This is just one way in which the development of local-language web addresses could help the Internet as a whole, ASCII namespace included. A true embodiment of one of the new gTLD's program founding goals "to open up the top level of the Internet's namespace to foster diversity, encourage competition, and enhance the utility of the DNS."

Written by Stéphane Van Gelder, Chairman, STEPHANE VAN GELDER CONSULTING

After serving as a consultant for multiple organizations, I have encountered many companies that allow all internal devices to send outbound DNS queries to external DNS servers — a practice that can lead to myriad problems, including cache poisoning and misdirection to rogue IP addresses. For companies that want to enable internal devices to send these types of queries, having the ability to manually or automatically blacklist domains is a very effective way to add a layer of security to a broader security architecture.

DNS & Blacklisting

Companies of all sizes are susceptible to DNS attacks. Depending on the type of external recursive DNS server that is running, there are a number of ways to tighten your outbound DNS recursive service, from manual domain blocking to fully automated updates as threats appear.

I recently worked with a company that was infected by a virus that got ahead of the anti-virus software for a short period of time. The security team knew that approximately 100-150 domains were actively being resolved to aid in the spread of the virus and payload. We resolved the issue by manually blacklisting the affected domains.

Infoblox has created a very compelling solution that allows users to update their blacklist as threats emerge. While we were able to successfully help mitigate the threat with manual updates, the Infoblox solution would have enabled us to be even more proactive.

If your company is small and runs a DNS server in house, using something tried and true, such as BIND can benefit you from this type of added security. Depending on where you prefer to source your list of blacklisted domains, these can be loaded to the external recursive server — causing a DNS firewall effect. The server will need to be updated regularly, removing domains that no longer need to be blacklisted and adding new domains on an as-needed basis.

Ensuring that the DNS firewall architecture is as effective as possible will require reviewing your firewall rules. For example, I recommend restricting outbound port 53, Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) ,to allow only recursive server IP addresses access to the Internet on port 53 UDP/TCP. This rule would need to allow access to ANY IP address on the Internet, as these servers will have to walk the DNS tree and resolve DNS from servers worldwide.

Written by Jesse Dunagan, Senior Professional Services Engineer at Neustar

The two-day event, held Aug. 7-8 at the company's 60,000-square foot Manchester, New Hampshire headquarters, will feature some of the biggest names in tech innovation and web performance.

Announced keynotes thus far:

• Dean Kamen, founder of FIRST, a program that gets students interested in science, technology, and engineering, the inventor of the Segway and founder of Manchester's DEKA
• Cricket Liu, the man who literally wrote the book on DNS (O'Reilly's DNS & BIND) and is SVP, Architecture at InfoBlox
• Joshua Baer, Chief Innovation Officer at email intelligence leaders Return Path and Managing Director of Capital Factory, a seed stage mentoring program for startups
• John Lynch, former four-time New Hampshire governor, former CEO of Knoll Inc. and former Director of Admissions at Harvard Business School
• Mark Imbriaco, VP, Technical Operations at Github, longtime Dyn Thought Leadership Council member

In addition to the keynotes, leaders in companies like Box, Etsy and Red Hat will lead a series of panels on topics covering:

• Innovation
• Speed and Optimization
• Scalability and Redundancy
• Security and DDoS
• Managing/Controlling Infrastructure

Registration is now open, but the number of passes available is limited.

"Internet infrastructure is one of the most exciting spaces currently operating on the web," said Jeremy Hitchcock, CEO of Dyn. "We wanted to bring together some of the key players within the industry to discuss some of the biggest issues of the day. We made it a summer camp because New Hampshire is a great destination that time of year. "

While there will be a lot of information to learn, the conference will stay true to its summer camp name. That is why the first day of the conference will conclude with a Music Meets Tech DynTini. The concert will be headlined by The Parlotones, the multiplatinum-selling South African rock band.

"We have been to hundreds of conferences all over the world," said Kyle York, Dyn Chief Revenue Officer. "But none of them will be like Geek Summer Camp. This is one of a kind and the can't miss event of the summer."

For more information, visit www.geeksummercamp.com.

Advanced Feature Usage – 48% of Dyn's enterprise customers are utilizing a traffic management service for disaster recovery, cloud load balancing, geographic regional routing, latency-based routing, or our granular geographic IP routing services.

If we look even deeper into the actual usage of these advanced features, we see some customers using traffic management on as many as 310 zones. We have some of the data summarized below.

	Active Failover	Traffic Management
Customers using the feature	440	671
Total Zones using the feature	2936	4470
Avg. Zones/Customer	6.66	6.67
Median Zones/Customer	2	2
Highest Advanced Feature Usage	350	310

At this point, a significantly higher portion of our customers in the higher traffic tiers use these advanced services:

Advanced Feature Usage by Traffic Tier – The usage of advanced features is especially high in certain verticals of technology companies.The usage of advanced features is especially high in certain verticals of technology companies. Advertising (74%) and Games/Video/Entertainment (60%) particularly stand out.

Today, our customers are creating an Infrastructure stack with redundant providers of colocation, cloud or managed hosting, content delivery, web acceleration, transit, storage/database servers, routers, switches and more. The amount of money spent behind our content agnostic services makes the investment in what we do a simple one. We help prevent vendor lock-in and allow our customers diversity across and down the stack.

The market has caught up and now we innovate on that top 15% as they drive our product roadmap forging ahead. It's a proven way to do R&D and serve a rapidly growing Internet audience who's end user expectations are higher than ever.

As Dyn evolves from a world leading DNS and email delivery provider to a more rounded provider of Internet performance technologies, we'll continue to expose more stats like this (like we did last month with what hosting providers our clients use) and provide even more insight into your entire external infrastructure — traffic, messaging and more. Your customers' experience is on us to help solve.

While this mobile app was traditionally intended to be a sales/marketing tool, Dyn will now position it as a DevOps tool for its customers.

This move, combined with the acquisition of Verelo in late 2012 and the hiring of Pete Cheslock as Dyn Director of Dev Tools, Donald Layden as Project Manager, Tools, and the promotion of Carl Levine to DevOps Evangelist, is proof that Dyn is committed to being an important voice and part of the DevOps community.

"At the root of Dyn has always been our excellence in engineering," said Kyle York, Dyn Chief Revenue Officer. "We are committed to creating tools that answer the questions of engineers and members of the DevOps community throughout the world. The acquisition of Trendslide is a big step toward that guarantee."

The Trendslide app aggregates data from the websites and apps users already use, and presents a simple graph for a single purpose: to give them a pulse on whether their key metrics are trending up, staying flat, or trending down. Dyn plans to integrate historical DNS and email data into Trendslide, in addition to 3rd party services like Gomez, New Relic, Thousand Eyes, Catchpoint, Keynote, Nagios and more.

In addition to acquiring the IP, co-Founder Benjamin Petrin will join Dyn as a Lead Developer, Tools, with a focus on innovative mobile experiences for Dyn customers.

The acquisition of Trendslide enhances Dyn's commitment to Internet performance, reliability and scalability for more than 500,000 active self sign-up customers, 2500 enterprise customers and over five million users worldwide. This is a firm display that Dyn is diving into mobile technology as Native Push and SMS are two messaging areas the company is considering.

Dyn has a long history with Trendslide as Dyn CTO Cory von Wallenstein was the original investor and helped the company gain early traction and buzz. One of the hottest startups in New Hampshire, the Dyn executives saw an opportunity to acquire Trendslide while an acquisition was still viable as they were poised to raise an additional funding round.

In part, Trendslide's success can be attributed to its strong advisory board, which included Richard Terry-Lloyd, VP of Emerging Markets, Zuora; Eric Hansen, Founder/CEO, SiteSpect; Ryan Burke, VP, Sales, Moontoast; Evan York, Senior Product Manager, Newforma; and Josh Deslisle, VP, Worldwide Sales, Dyn.

"This is a great home for the future of the Trendslide application," added Ron Martin, Trendslide CEO. "As we were looking to raise capital, it was the common opinion of many VCs that this service should stay close to Dyn and focus on Infrastructure — not on marketing and sales analytics. It was good advice, so we decided this was the sensible move. We are happy with this outcome and excited to see the product carry on."

Although this article was first published just a few days ago, on May 8th, there have been several important intervening developments.

First, on May 10th ICANN released a News Alert on "NGPC Progress on GAC Advice" that provides a timetable for how the New gTLD program Committee will deal with the GAC Communique.ⁱⁱⁱ Of particular note is that, as the last action in an initial phase consisting of "actions for soliciting input from Applicants and from the Community', the NGPC will begin to "Review and consider Applicant responses to GAC Advice and Public Comments on how Board should respond to GAC Advice re: Safeguards" on June 20th. This will be followed by a second phase consisting of "actions for responding to each advice given by the GAC", including development of "a GAC scorecard similar to the one used during the GAC and the Board meetings in Brussels on 28 February and 1 March 2011".

In regard to how this may affect the timeline for introduction of new gTLDs, the Alert notes, "Part 2 of the Plan is not yet finalized and, with respect to some of the advice, cannot be finalized until after the review of the Public Comments due to be completed on 20 June." Thus it is impossible to know at this point in time how much delay ICANN's response to the GAC Communique may create for the introduction of new gTLDs, especially for those subject to the additional or further targeted safeguards for stings related to regulated industries and professions — although the outlook seems to generally adhere to the projections made in the article. I would guesstimate that some strings affected solely by the GAC's basic safeguards could launch in the third quarter of 2013, while those encompassed by the additional safeguards probably face delay until the last quarter of the year at a minimum. The next meeting of the NGPC takes place on May 18th in Amsterdam, where "Resolution(s) on GAC Advice" is on the agendaⁱⁱ; any such Resolutions are more likely to be procedural than substantive — with substantive reaction, much less implementation, waiting until after GAC interaction with the Board at the mid-July ICANN meeting in Durban.

Of course, regardless of how ICANN deals with the Communique, no new gTLDs can launch until the standard Registry Agreement (RA) is made final and adopted by the Board (and it may require yet further amendment to implement GAC safeguards and other advice) — and the same steps are completed for the revised Registrar Accreditation Agreement (RAA) if, as seems likely, only registrars adopting the revised RAA will be permitted to provide domain registration services for new gTLDs.

Second, on May 10th ICANN also released a video interview — "GAC Chair Heather Dryden on the Beijing Communiqué and New gTLD Advice"ⁱⁱⁱ — in which Chairwoman Dryden makes some significant assertions:

• The safeguard advice was not an attempt to impose new obligations on registry operators but about pre-existing obligations and applicable law, and should therefore be viewed as implementation rather than new policy.
• The GAC is not suggesting a new global regulatory regime but measures that are consistent with ICANN's existing role. Responding to questions posed by Brad White, ICANN's Director of Global Media Relations, Ms. Dryden explained:
• It's really not intended to impose a new global regulatory regime. It is intended to be consistent with ICANN's existing role and serve as a reminder to those that have applied of what is really involved with implementing if they are successful a string globally as well as really wanting to emphasize that some of those strings raise particular sensitivities for governments
• The GAC believes there must be a good reason to permit exclusive registrations at a generic gTLD and encourages community discussion of the proper "public interest' standard.
• The GAC does not view the Communique as 11th hour advice but as a more detailed reiteration of general advice on gTLD string categorization that was not taken. The Communique is utilization of a standard ICANN mechanism consistent with the GAC's primary role of advising on public policy aspects of ICANN actions.
• On the overarching political considerations that will color ICANN's response to the Communique — If ICANN were to ignore the GAC advice many governments would question the usefulness of the GAC and their continued participation in and support of ICANN. Ms. Dryden stated:

  WHITE: Suppose the [ICANN] board in the end says "thank you very much for the advice, we've looked at it, but we're moving on" and basically ignores a lot of that advice?

  DRYDEN: I think it would be a very immediate reaction, questioning the value of participating in the Governmental Advisory Committee. If it is going to be the place for governments to come and raise their concern and influence the decision making that occurs at ICANN then we have to be able to demonstrate that the advice generated is fully taken into account or to the maximum extent appropriate taken in and in this way governments understand that the GAC is useful mechanism for them.
  ...
  WHITE: What you seem to be saying is there is concern about whether or not some governments might pull out from that multi-stakeholder model?

  DRYDEN: Right, right why would they come? How would they justify coming to the GAC meetings? Why would they support this model if in fact it's there aren't channels available to them and appropriate to their role and perspective as a government?

• The GAC's priorities for the July ICANN meeting in Durban are the fourteen strings specifically identified as requiring further consideration, as well as implementation of the proposed safeguards. Ms. Dryden explained:
  There may well also be aspects of safeguard advice that we would discuss further with the board or with the community or would need to, particularly the implementation aspects of some of the new safeguards that the GAC identified.

Chairwoman Dryden also concedes that the GAC advice may have been misunderstood because it was developed behind closed doors and therefore deprived members of the ICANN community of an opportunity to better understand the GAC's concerns and reasoning, and she appears to pledge that the GAC will operate with greater transparency in the future.

In addition to providing useful background on the GAC's thinking, the interview also reiterates that if ICANN fails to provide adequate response to the Communique it risks disengagement from the ICANN model by GAC member nations. In addition to providing an opportunity for demonstrating effective self-regulation, reasonable implementation of the safeguards can also head off more onerous top-down legislative and regulatory approaches. Imagine, for example, if in the absence of a meaningful response by ICANN to the GAC the European Community (EC) were to adopt legislation that incorporates the safeguards as a prerequisite for the sale of new gTLD domains by registrars operating in the Community as well as for the transaction of online business with EC consumers by their registrants?

Finally, initial public comments on the safeguards have started to be posted.iv Predictably, some support various elements while others urge rejection on the grounds that the Communique consists of tardy and ill-defined changes in policy that are at odds with the multi-stakeholder model.

Notwithstanding some negative comments and related press treatment, the overarching politics of the situation will almost surely result in a very serious ICANN process for considering the proposed safeguards and other components of the Communique, and seeking to implement them in a manner that is effective but does not impose undue or inappropriate burdens on contracted parties while maintaining ICANN's role as technical manager of the DNS in a manner that respects and enforces existing public policy but does not usurp roles that belong to legislators and regulators. New gTLD applicants, other members of the ICANN community, and interested third parties have an opportunity to influence ICANN's further consideration and implementation of the GAC advice over the next several months.

* * *

NEW TOP-LEVEL DOMAINS

(Synopsis) The Governmental Advisory Committee communique and responsive requests for comments provide an opportunity for everyone involved with the Internet Corporation for Assigned Names and Numbers and every interest affected by the new TLD program to submit final input on its proposed framework for the launch of new TLDs, the author writes. The added steps will likely cause delays and impose new duties, but will also provide a blueprint for ICANN and registry operators to work cooperatively with the global public sector in decades to come.

* * *

On the afternoon of April 11, 2013, the last day of ICANN's 46th Public Meeting in Beijing, China, its Governmental Advisory Committee (GAC) issued a long and detailed communique with significant implications for the approximately 1,400 unique applications submitted to ICANN's new TLDs program — and, based upon its implementation response, for ICANN itself.

The communique — the end product of a week of intense work undertaken by more than 100 participants from governments attending and engaging in the Beijing meeting — was foreshadowed by a March 31 GAC announcement¹ that GAC meetings in Beijing would focus on "controversial or sensitive strings and applications," with sessions organized on "safeguard advice on the basis of categories of strings" and "GAC advice/objections on specific applications."

While the GAC has reverted to holding closed door meetings — excessively in our view, within an ICANN organization dedicated to transparency and accountability — during the days before the ICANN meeting and its initial days, the GAC did reach out. The GAC met with many parties, including the GNSO Council charged with TLD policy matters, the Commercial Stakeholder Group, the ICANN Board of Directors, and others.

The GAC was striving to deliver its input before the Beijing meeting concluded. The communique arrived in the middle of the Beijing Public Forum, where individuals directly address the ICANN Board on relevant topics.

The communique elicited immediate outcry from some that its proposals constituted major changes in the rules of the new TLD game after the game had begun, would cause undue delay, fostered internet censorship — and that it should be subject to public comment. But it received support from others who believe that the GAC is best positioned to address public interest issues implicated by ICANN activities. Further, many of the issues addressed by the GAC were not clearly evident until after the sheer volume and relevant specifics of new TLD applications had been fully digested.

ICANN's Unprecedented Move

In a somewhat unprecedented move, ICANN acquiesced to the call for public comments and is even requesting two separate types.

First, on April 19, new TLD applicants were advised that they were being provided with 21 days, until May 10, to respond to the GAC advice.²

That notice, as well as the official "GAC Advice Response Form for Applicants," takes a wide open approach. The notice provides no guidance on how feedback should be structured, such as whether applicants should critique the advice, outline how they intend to comply with it, or both. The attached form asks only for the applicant's name, ID number, and applied for string — followed by "Response:" and a blank space to fill.

Shortly thereafter, on April 23, ICANN published a general notice of request for public comment from any interested party on "New TLD Board Committee Consideration of GAC Safeguard Advice," with an initial comment deadline of May 14 and a subsequent reply period closing on June 4.³

The explanation of the general public comment invitation provides this background:
On 11 April 2013, the Governmental Advisory Committee issued its Beijing Communique´ in which it provided advice on New TLDs. The Board New gTLD Committee, acting on behalf of the full Board, will now consider how to address the GAC Advice. To help inform this process, the Committee has directed staff to solicit comment on how it should address one element of the advice: safeguards applicable to broad categories of New gTLD strings. Accordingly, ICANN seeks public input on how the Board New gTLD Committee should address section IV.1.b and Annex I of the GAC Beijing Communique´.

As can be seen, the scope of comment being solicited from the general public is circumscribed, with requested input limited to the portions of the communique proposing "safeguards" — although many commenters will likely ignore that restriction and address other portions as well.

Again, ICANN has provided no further refinement of the request for comment, giving no indication as to what feedback would be most useful to the Board's new TLD program committee. This unique and noteworthy approach may well result in feedback being received from parties not normally engaged with or active within the ICANN community.

Those most directly affected by the GAC advice, new TLD applicants, may well choose to participate in both their exclusive comment forum as well as this general one — especially as the reply period for the latter extends to nearly four weeks past their own May 10 cutoff date — if they are willing to make their responses public.

Potential Implications

Before getting into the specifics of the GAC safeguard advice, the following are some guesses about the implications and effects that will flow from it.

Timing of New TLD Introductions

From now until the end of the July 14-18 ICANN meeting in Durban, South Africa, the ICANN community will consider and react to the GAC Advice.

The time from Durban until the final meeting of 2013, November 17-21 in Buenos Aires, Argentina, will likely be the period of ultimate determination as to how much of it will be accepted by ICANN's Board, followed by implementation on the part of both ICANN and applicants.

ICANN's new TLD program committee, composed of non-conflicted Board members, has scheduled discussion of a "Plan for responding to the GAC advice issued in Beijing" as the only agenda item for its May 8 meeting.⁴ But substantive reaction is likely to await receipt and consideration of applicant and public feedback as well as staff analysis of both the communique and the comments.

As the GAC wants all new TLD safeguards to be subject to "contractual oversight" by ICANN it is highly probable that additional amendments to the proposed new TLD Registry Agreement (RA) will need to be drafted and put out for public comment prior to final adoption, adding some additional delay to the rollout of new TLDs.

Registry Operator Responsibilities

Acceptance of even portions of the GAC advice will likely impose duties on registry operators to update and strengthen their terms of service.

Registries will also need to submit or update Public Interest Commitments Specifications (PICS), and assume registrant monitoring and coordination duties with regulators and industry bodies that they probably did not envision or price into their business model.

Requirements that registries immediately suspend domains in certain circumstances could re-ignite "domain censorship" due process concerns that last flared during the PIPA/SOPA internet blackout.

Role of Governments at ICANN

ICANN's and key stakeholders' reactions to the GAC communique may well determine whether governments remain engaged in and embracing of the ICANN multistakeholder model — or begin to drift away.

Internet governance options exist outside of ICANN that are generally less favorable to and welcoming of contracted parties, business, and civil society. A multi-governmental shift away from ICANN would connote negative long-term implications for its existence. It could also eventually subject the DNS to a maze of disparate national laws and policies or the more worrisome specter of intergovernmental oversight far more intrusive than GAC advice.

ICANN, with the acquiescence of its multistakeholder community, will ultimately adopt a majority of the GAC recommendations in some form as doing so is in its long-term institutional interest.

Overall, the receipt of the GAC communique and ICANN's solicitation of applicant and public comments on it marks an inflection point for the organization, and the manner in which it assimilates the advice and the responsive feedback will define its working relationships with governments through the end of the decade, and perhaps beyond.

In their video interview at the conclusion of the Beijing meeting, Board Chairman Steve Crocker stated that the communique raised "interesting issues that have to be dealt with, and we'll be quite thorough about it." CEO Fadi Chehade committed that action would be taken only following consideration of public comment from the "entire community" along with staff analysis.

As it is not at all customary to subject GAC advice to direct public comment, this will be politically sensitive, complicated, and highly detailed work invoking multiple judgment calls.

New TLD Advice on Which ICANN Has Not Requested General Public Comment

The April 18 notice to new TLD applicants solicits feedback on every aspect of the GAC communique, with applicant responses to be published and provided to the full ICANN Board.

However, it is not clear whether individual applicant responses will be made public. Should any applicant respond to the GAC by seeking to file a PICS — which raises the collateral question of whether ICANN will waive the previously expired deadline for PICS submissions — those filings are made public at the updated application status page of the new TLDs website.

GAC advice affecting new TLD strings on which applicant feedback is being explicitly solicited, but general public response is not, includes:

Targeted Advice

Targeted advice against proceeding further on a specific application for .africa and one for .gcc, as well as on applications for .islam and .halal; and advice not to proceed beyond initial evaluation for two Chinese Internationalized Domain Name (IDN) strings (.shenzhen and .guangzhou) as well as the applications for .persiangulf, .amazon (and related IDNs in Japanese and Chinese), .patagonia, .date, .spa, .yun, .thai, .zulu, .wine, and .vin.

Written Briefing

The GAC's request for "a written briefing about the ability of an applicant to change the string applied for in order to address concerns raised by a GAC Member and to identify a mutually acceptable solution."

Such a briefing should also be made publicly available, as this is a critical issue for applicants and the general public because it relates to the central question of whether and the extent to which an applicant can amend its application to comply with a relevant GAC safeguard if it is adopted by ICANN.

Community Support

The GAC's view on community support for applications, in which it advises "that in those cases where a community, which is clearly impacted by a set of new TLD applications in contention, has expressed a collective and clear opinion on those applications, such opinion should be duly taken into account, together with all other relevant information."

That seems elementary, yet it fails to resolve ongoing disputes about whether or not certain strings legitimately fall into the "community" category, as well as who can legitimately claim to speak for the impacted community.

Singulars Versus Plurals

The GAC's belief that "singular and plural versions of the string as a TLD could lead to potential consumer confusion" and the consequent advice that the Board should "Reconsider its decision to allow singular and plural versions of the same strings."

This is a reaction to the February 26 decision of ICANN's string similarity panel that singulars and plurals of the same term did not create a probability of visual similarity confusion, a conclusion that many have categorized as clueless, as well as something that is likely to receive general public comment notwithstanding it falling outside the "safeguard' category.

At the Board-GAC interaction in Beijing, the Board advised the GAC that it would not second guess the Panel's conclusion and that "the ball is now in your [the GAC's] court."

The GAC has now forcefully tossed the ball back to the Board. Some ICANN constituencies have already weighed in with the view that singular and plural versions of a string should be placed in the same contention set.

IGO Protections

Reiteration of prior advice that "appropriate preventative initial protection for the IGO [Intergovernmental Organizations] names and acronyms on the provided list be in place before any new TLDs would launch."

The RAA

Advice that "the 2013 Registrar Accreditation Agreement should be finalized before any new TLD contracts are approved' with the notation that "The GAC also strongly supports the amendment to the new TLD registry agreement that would require new TLD registry operators to use only those registrars that have signed the 2013 RAA."⁵

IOC/Red Cross Protections

Strong advice that ICANN should "amend the provisions in the new TLD Registry Agreement pertaining to the [International Olympic Committee/Red Cross-Red Crescent] IOC/RCRC names to confirm that the protections will be made permanent prior to the delegation of any new TLDs.

PICs

A request for "more information on the Public Interest Commitments Specifications [PICS] on the basis of the questions listed in annex II."

These GAC-posed questions may become critical matters to be addressed, especially for applicants seeking strings in categories raising heightened GAC concerns as well as for third parties concerned by those applications. The questions raised in Annex II are addressed later in this article.

Annex I – The GAC's Proposed Safeguards

Annex 1 of the communique addresses "Safeguards on New TLDs" with introductory advice that "The GAC considers that Safeguards should apply to broad categories of strings. For clarity, this means any application for a relevant string in the current or future rounds, in all languages applied for."

The GAC is clearly stating that its advice should be interpreted and implemented broadly, not narrowly. This introduction further advises that all the proposed safeguards should "be implemented in a manner that is fully respectful of human rights and fundamental freedoms," "respect all substantive and procedural laws under the applicable jurisdictions," and "be operated in an open manner consistent with general principles of openness and nondiscrimination."

None of that seems particularly objectionable, but even this hortatory language raises such interpretative questions as to what are the "applicable jurisdictions" for a particular string — and how should operation in an open manner be squared with later admonitions relating to strings related to regulated industries and professions where domain registrations are to be circumscribed?

Safeguards Applicable to All New TLDs

The first detailed section of the advice proposes that six specific safeguards be applicable to all TLDs and "be subject to contractual oversight" by ICANN.

At a minimum, to the extent that ICANN accepts any of this it will then need to review the existing new TLD Registry Agreement (RA) — already the subject of some controversy, especially in regard to whether ICANN should have some unilateral right to amend it — and determine whether further amendments are needed to incorporate any parts of the GAC advice that are adopted.

As ICANN is not a governmental body and all of its powers over registries and registrars are derived via contractual enforcement, this is no small matter.

On April 29, ICANN published the Proposed Final New TLD Registry Agreement for public comment, open through June 11.⁶ Yet, except in the highly unlikely event that ICANN rejects all of the GAC's safeguards proposals, adoption of any of them would seem to inevitably require further amendment of the RA to spell out related, contractually enforceable registry obligations — with such further amendment triggering yet another period of public comment.

Further, as the following analysis illustrates, the question for ICANN's Board is not just whether to accept a particular safeguard but how to implement it in a manner that is effective yet reasonable. Determining the right balance will take time.

Six Basic Safeguards

The GAC's proposed six basic safeguards are:

1. WHOIS Verification and Checks

Registry operators are to conduct statistically significant checks at least twice a year on false, inaccurate, and incomplete WHOIS registrant identification data, and notify registrars of inaccurate or incomplete data.

This appears to impose proactive oversight and enforcement duties that registry operators were probably not contemplating. It also implicates matters addressed by the just-released-for-comment final Registrar Accreditation Agreement, as well as ongoing discussions focused on increasing WHOIS registrant data accuracy. All of these approaches must ultimately be reconciled and coordinated.

2. Mitigating Abusive Activity

Registrant terms of use must "include prohibitions against the distribution of malware, operation of botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law."

No one can be in favor of such activities, but that begs the questions of whether this imposes some affirmative oversight duty on registry operators, and what steps they should take to monitor compliance with and enforce such prohibitions. Also, in some instances the issue of whether a violation has occurred may not be discernible absent other adjudicative processes.

Trademark infringement, for example, is already the subject of the UDRP and national laws. It will also be addressed by the two new rights protection mechanisms — the trademark clearinghouse and uniform rapid suspension system in new TLDs — but all these mechanisms require some judicial or expert determination of where infringement has actually occurred.

Digital copyright infringement is an evolving and muddled area of the law in which courts in the same nation have reached sharply divergent opinions on similar fact patterns. While some "piracy' may be evident from a cursory review of a website, other alleged instances invoke unsettled legal issues. Ultimately, the question is whether registry operators should wait on law enforcement authorities or adjudicative processes to verify legally actionable harm, or take their own initiatives to identify and halt it.

3. Security Checks

In a bow to law enforcement concerns, registry operators are to periodically conduct technical analyses of whether domains are being used to perpetrate security threats "such as pharming, phishing, malware, and botnets," all the while "respecting privacy and confidentiality." Such information is already available from various industry groups, with existing registry operators typically engaged in these initiatives. In addition, the new TLD registry application process already includes security checks.

Nonetheless, this could require registries to take on proactive, quasi-police cybersecurity inquiries. More disturbingly, where security risks posing "an actual risk of harm" are identified, registry operators must notify the relevant registrar. If the registrar fails to "take immediate action" then the registry operator must "suspend the domain name until the matter is resolved."

This recommendation is almost sure to be controversial, as domain suspensions are widely viewed as equivalent to internet censorship. The notion that private parties will do this on their own accord, absent any due process requirements, and with no additional definition as to how or by whom the matter will ultimately be resolved, raises significant questions concerning registrant rights.

4. Documentation

Registry operators are to maintain statistical reports on inaccurate WHOIS records or security threats and provide them to ICANN on request. This advice does not seem particularly burdensome or controversial.

5. Making and Handling Complaints

Registry operators must have a mechanism for other parties to submit complaints about domains with inaccurate WHOIS information or domains being used to facilitate bad acts. This safeguard, motivated by growing concerns in regard to cybercrime, fraud, and abuse, is not particularly burdensome, either.

But questions remain unanswered: What is the registry operator's duty to further investigate such complaints, and what action should be taken if it finds them well-founded? Will ICANN's compliance staff have an intermediary role in this area?

6. Consequences

Registry operators must, "consistent with applicable law" — to the extent it exists or is clear — "ensure that there are real and immediate consequences for "domains with false WHOIS violations or being used in breach of "applicable law," and "these consequences should include suspension of the domain name."

Domain suspension, as was seen during the PIPA/SOPA debate, is viewed by many as synonymous with internet censorship, and the requirement that registry operators assume policing oversight powers may well generate substantial controversy. The requirement may also trigger discussion of the existence and adequacy of due process protections and a defined appeals process for affected registrants.

In sum, the six basic safeguards call for various oversight and investigative responsibilities that many registry operators may not have contemplated when they constructed their business plans.
Their implementation also may imbue registry operators with certain additional domain enforcement powers that in turn raise related due process questions.

To some extent, these recommendations may be an attempt by fiscally-strapped governments to place the costs of policing and subduing negative externalities resulting from new TLDs back onto registry operators, minimizing the need for potential allocation of substantial new public sector resources focused on law enforcement and cybersecurity.

Additional Safeguards for Particular Categories of New TLDs

Beyond those six basic safeguards recommended for all new TLDs, the GAC prescribes additional safeguards for strings related to regulated or professional sectors for which end users generally anticipate targeted protections.

The communique states:

Strings that are linked to regulated or professional sectors should operate in a way that is consistent with applicable laws. These strings are likely to invoke a level of implied trust from consumers, and carry higher levels of risk associated with consumer harm.

The dozen sectors identified by the GAC for application of these additional safeguards, accompanied in the communique by a non-exhaustive list of TLD applications asserted to fall within them, are:

children,
environmental,
health and fitness,
financial,
gambling,
charity,
education,
intellectual property,
professional services,
corporate identifiers,
generic geographic terms, and
inherently governmental functions.

One may certainly question why certain TLD applications made the GAC's nonexclusive list or have been placed in particular categories.

For example, .free, .gratis, .discount and .sale are all placed in the intellectual property category even though they might attract domains with no relationship to goods and services of a primarily IP nature. And .law is given its own separate listing rather than being placed in the professional services category along with .abogado, .attorney, .lawyer and .legal.

But, for the present purpose of this analysis, all the specifically listed applications are potentially subject to the additional safeguards depending on follow-up ICANN action. Other applicants with any possible relationship to the identified sectors should presume that they may be similarly affected before this process concludes. Those applicants, along with parties with concerns about or opposed to specific strings, should thoroughly review this advice.

Proposed Additional Safeguards for Regulated, Professional Sectors

The additional safeguards proposed for regulated and professional sectors — accompanied by some observations — are:

1. Applicable Use Policies.

Registry operators will include in their acceptable use policies a requirement that registrants comply with all applicable laws, including those that relate to privacy, data collection, consumer protection, fair lending, debt collection, organic farming, disclosure of data, and financial disclosures.

It seems axiomatic that registry operators must be in compliance with applicable laws of all types.

However, the questions raised again by such general use policies is to what extent a registry operator will be expected to proactively police and directly enforce them, and what are the applicable laws for a particular domain registrant?

What is a registry operator expected to do, for example, if a registrant is accused of operating in violation of a particular nation's laws and the registrant responds that under applicable principles for determining jurisdiction it is not subject to those laws? These are roles and decisions that have traditionally been delegated to law enforcers, regulators, and judicial forums, not to private parties lacking adjudicative expertise under contract to a nonprofit corporation.

2. Notifications.

Registry operators will require registrars at the time of registration to notify registrants of this requirement.

This is a relatively straightforward requirement to implement, although it will require registrars to identify and separate out affected TLDs and provide additional disclosures at or in close proximity to the time of domain registration.

It also highlights the fact that it is registrars, not the registry operators of new TLDs, who have direct contact and contractual relations with registrants. To the extent that registrars of particular TLDs are tasked with going beyond offering a simple domain purchase interface to registrants, and must provide and obtain acceptance of particular disclosures — much less ascertain that registrants satisfy relevant registration eligibility criteria — this will both complicate the domain registration process and generate costs that must be reflected in compensation arrangements with the registry operator as well as in the prices charged to registrants.

The only exception to the registrar standing as a separate intermediary between the registry operator and the registrant will be those instances in which the registry operator has directly affiliated with a registrar, now that ICANN has relaxed the former prohibition against such relationships — although, even then, for all but ".brand" or whatever other "closed generic" TLDs are permitted, there will likely be many unaffiliated registrars offering identical domain registration and renewal services for the TLD.

3. Security for Sensitive Data.

Registry operators will require that registrants who collect and maintain sensitive health and financial data implement reasonable and appropriate security measures commensurate with the offering of those services, as defined by applicable law and recognized industry standards.

While clearly having direct bearing on registrants at strings falling within the health and fitness and financial categories, this safeguard may also implicate others — as an example, at such professional services strings as .accountant(s), .doctor, and .realtor, where registrants will likely collect and maintain confidential health and financial data.

Again, the more difficult issues are what are the "reasonable and appropriate security measures" that registrants should implement to safeguard such data, what monitoring and enforcement duties are expected of registry operators to assure compliance, and what constitutes the "applicable law and recognized industry standards' that should be looked to in establishing relevant security measures?

The proper standards for protection and disclosure of sensitive digital data remain one of the most hotly debated matters of 21st century cyberlaw and policy, with sharp disagreements between governments and with and within affected industries — yet registry operators are being asked to require the implementation of responsive security measures by their registrants.

4. Working Relationships.

Establish a working relationship with the relevant regulatory, or industry self-regulatory, bodies, including developing a strategy to mitigate as much as possible the risks of fraudulent, and other illegal, activities.

For registry operators of TLDs falling within the listed sectors this would require an ongoing, perpetual establishment of a "working relationship" — but with whom? As one example, with what financial regulatory authorities and industry self-regulatory bodies located in which nations must the operator of .retirement establish a working relationship?

Is it to be based upon the nations to which .retirement registrants direct their activities, or must it involve global outreach so that any potential future registrant and its customers will be accommodated by an already existent working relationship? And what would comprise an effective strategy to mitigate potential fraud or other illegal activities by registrants — would this require proactive engagement, monitoring, and enforcement by registry operators, who may well be asked by regulators to establish such frontline risk mitigation activities?

Overall, this safeguard must be read in conjunction with the others, with the expectation that regulators will likely seek proactive registry operator involvement in the development and implementation of risk mitigation strategies.

Further, registry operators must take into account that a TLD is a global DNS resource. A registrant eligibility policy or regulatory engagement approach too narrowly focused on a specific nation(s) or region may well and rightly be criticized by potential registrants, consumer groups, and other public and private sector entities.

5. Single Point of Contact.

Registrants must be required by the registry operators to notify them of a single up-to-date point of contact for the notification of complaints or reports of registration abuse, as well as the contact details of the relevant regulatory, or industry self-regulatory, bodies in their main place of business.

Single points of contact are already standard practice for ISPs and web hosting companies. This safeguard again places a duty upon registry operators to obtain information from registrants with whom they otherwise likely have no direct dealings or contractual relationship. While the actual information that must be obtained — the unitary contact point for urgent notifications of reported abuse at a website — is relatively simple, the question again arises regarding whether the registry operator has a duty to validate this data on an initial or continuing basis.

Further, since this safeguard relies on the registrant to designate the contact details for what it claims to be its relevant regulatory and industry self-regulatory bodies in its main place of business, is there any duty for the registry operator to investigate whether the registrant has accurately done so? And does "main place of business" just cover the jurisdiction in which the registrant is domiciled — or all the additional jurisdictions in which it conducts or may seek to conduct substantial volumes of business with customers (e.g., a Bahamas-based .insurance registrant soliciting and conducting business in the U.S., E.U., and certain Latin American nations)?

Miscellaneous 'Gripe Site Registry Advice

In related GAC advice, applicants for the .fail, .gripe, .sucks, and .wtf TLDs are singled out to "develop clear policies and processes to minimize the risk of cyber bullying/harassment."

Such "criticism" TLDs could be particularly susceptible to such abuses — though they already exist today, often centered in "closed garden" social media platforms.

Further Targeted Safeguards

In addition to the six basic safeguards and the five additional ones for regulated and professional sectors, the GAC has also proscribed three additional safeguards for at least seven of the twelve sectors listed above — financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity.

These additional safeguards are aimed at "market sectors which have clear and/or regulated entry requirements in multiple jurisdictions," and are applicable to some of the strings in the listed sectors — although the GAC provides no guidance as to which strings might be exempt and on the basis of what criteria exemptions might be granted or denied.

These further targeted safeguards consist of:

1. Added Checks

At the time of registration, the registry operator must verify and validate the registrants' authorizations, charters, licenses, and/or other related credentials for participation in that sector.

This verification and validation duty is placed on the registry operator, rather than the registrar who interfaces with the registrant at the time of registration. While the registry operator night prefer to delegate such responsibilities to registrars with which it has established business relationships, doing so as a thousand-plus diverse TLDs launch could prove infeasible.

Thus, there are questions of how such a process would be coordinated and the status of a registrant's registration until such time as the verification/validation duty is completed. It clearly places significant new responsibilities on registry operators — although one that is already managed by many ccTLD operators — that will entail the use of in-house or outside compliance counsel and staff.

2. Consultations With Regulators

In case of doubt with regard to the authenticity of licenses or credentials, registry operators should consult with relevant national supervisory authorities, or their equivalents.

This would require each registry operator to develop policies relating to how authenticity of credentials will be evaluated, as well as establish relationships with relevant supervisory authorities in all nations in which registrants may be domiciled or otherwise have significant jurisdictional contacts.

Again, this creates additional significant new compliance responsibilities likely to require increased staffing by both registries and ICANN.

3. Post-Registration Checks

The registry operator must conduct periodic post-registration checks to ensure registrants' validity and compliance with the above requirements in order to ensure they continue to conform to appropriate regulations and licensing requirements and generally conduct their activities in the interests of the consumers they serve.

This would place a continuing, post-registration duty on registry operators to not just confirm the regulatory compliance and licensing validity of registrants but to make a subjective judgment on whether they are conducting their activities in consumers' interests.

This raises the issue of whether it is reasonable and appropriate to place such subjective judgment responsibilities on what are primarily providers of technical DNS services. On the other hand, TLDs aiming to serve specialized communities associated with regulatory and licensing requirements may wish to accept this GAC advice and address it via responsive PICs as well as cooperative engagement with ICANN compliance staff to develop reasonable yet effective enforcement mechanisms.

Restricted Registration Policies — Limited or Exclusive Strings

In addition to the above proposed safeguards, the GAC provided advice regarding restricted or exclusive access to strings.

First, as "an exception to the general rule that the TLD domain name space is operated in an open manner registration may be restricted," with such restrictions being particularly applicable for strings subject to the extra safeguards for regulated and professional sectors — especially including those with entry requirements.

However, the GAC advice proposes that such registration restrictions be administered by registry operators "in a transparent way that does not give an undue preference to any registrars or registrants, including itself, and shall not subject registrars or registrants to an undue disadvantage."

In other words, registrant entry can be restricted, but the restrictions must be geared to the relevant risks associated with the TLD. The restrictions must also be transparent and neutral under the subjective standard of not providing an "undue preference [or] disadvantage."

What this means in practice will likely be a subject of some debate, and certainly provides an opening for any party who believes that a TLD's proposed registration restrictions seek to advance goals other than legal/regulatory compliance and consumer protection — such as granting an undue competitive advantage to a subset of potential registrants, or seeking to advance policy goals within the TLD program that more properly should fall to legislators or regulators.

The second and final bit of GAC advice in annex I addresses the controversial subject of "closed generic" TLDs, for which ICANN recently conducted a public comment period which attracted one of the largest numbers of comments in recent years.⁷

That extensive public feedback has so far resulted in no formally announced ICANN policy or position. Amazon, Google, and other business applicants from both the United States and abroad have applied for generic word domains in which they hold no trademark rights yet for which they have proposed to be the sole registrant.

Critics of "closed generic' TLDs have charged that they are fundamentally incompatible with the new TLD program's stated goal of fostering innovation and competition. Google, for one, has responded to such criticism by proposing significant alterations for four of its most controversial applications.

On this hot button subject, the GAC simply states, "For strings representing generic terms, exclusive registry access should serve a public interest goal." That statement is followed by a non-exhaustive list of strings identified by the GAC as constituting generic terms.

Registry Operator Code of Conduct

It appears that this is one bit of GAC advice that ICANN may have already taken into account.

The revised RA released by ICANN on April 29 proposes to strike the phrase "that are reasonably necessary for the management, operations and purpose of the TLD" from Section 1b of Specification 9, otherwise known as the "REGISTRY OPERATOR CODE OF CONDUCT" (COC). The proposed changes would replace the provision with authorization for the registry operator to allocate up to 100 domain names for its own exclusive use.

That deleted phrase constituted the prior parameters of the exception to the general rule that a registry operator will not register domain names in its own right — and some closed generics applicants had argued that the word "purpose" permitted avoidance of seeking a sole registrant exemption under Section 6 of the COC.

Presuming that deletion carries through the public comment and Board approval process for the revised RA, it would seem that closed generic applicants may now have no way to avoid seeking a formal exemption from ICANN.

ICANN staff provided no comprehensive explanation of the intended purpose of these proposed amendments to the evolving contractual documents, so there may well be parties who interpret this alteration differently.

The exemption language of Section 6 remains unchanged in the revised RA, and allows ICANN to grant an exemption in its "reasonable discretion" if a registry operator demonstrates to ICANN's reasonable satisfaction that:

• all domain name registrations in the TLD are registered to, and maintained by, registry operator for its own exclusive use,
• registry operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an affiliate of registry operator, and
• application of the code of conduct to the TLD is not necessary to protect the public interest.

Thus, the GAC's admonition that closed generics must "serve a public interest goal" dovetails well with the Section 6 requirement that ICANN must determine that permitting closed generic operation is not adverse to the public interest — if all TLDs that propose to have the registry operator as sole registrant are indeed required to affirmatively seek an exemption.

The matter is not fully settled, as ICANN must still determine general principles to decide when application of the code of conduct is not necessary to protect the public interest. ICANN must then apply those principles on a case-by-case basis for those proposed closed registries that can still muster a convincing rationale for exemption.

It is quite possible that ICANN might find a public purpose in protecting trademarks at the top level of the DNS for non-generic, trademarked term ".brand" TLD applications.

The revised RA contains multiple, extensive additional revisions beyond the code of conduct changes that may also be highly controversial.

For example, on May 1 VeriSign Inc. filed an aggressive comment letter on the registry agreement,⁸ complaining that:

ICANN has broadened its unilateral amendment rights even further under a new and never before disclosed Section 7.7 which permits ICANN to make changes to the registry agreement on subjects that even the consensus policies are explicitly prohibited from considering — and beyond ... Under its bylaws, ICANN is to serve the Internet community based on bottom-up, transparent decision making. Sections 7.6 and 7.7 are the antithesis of lCANN's core values. They should not become part of registry agreements.

The Governmental Advisory Committee and Commerce Dept. should rein in any such unprecedented expansion of ICANN's powers. In the Affirmation of Commitments, the DOC affirms its commitment to a private sector led, bottom-up policy development process. Sections 7.6-7.7 seek the opposite.

As one example of what VeriSign purports ICANN could do unilaterally, "without governmental oversight and over the objections of registry operators," the letter states that:

ICANN unilaterally determines that no new TLDs should be operated in a closed manner and amends the agreement to require all TLDs to be open, endangering established registry business model.

However, as discussed, governments represented on the GAC have already given consensus advice that closed registries must further public interest goals — and many parties who filed public comments on "closed generics" wanted ICANN to ban them outright.

Regardless of the final provisions of the RA relevant to closed generics, the GAC's position is now clear — a string in which the registry operator is the only permissible registrant must serve a public interest goal. As for the overall RA, the new TLD program cannot go forward until all remaining disputes are resolved and it is made final, as there must be a standard contract document for registry operators to sign before their new TLDs can go forward.

Annex II – The GAC's PICs Questions

As noted earlier in this article, in the main body of the communique the GAC requests additional information on eight PICs-related questions contained in Annex II.

These questions relate to such matters as:

• Third-party and governmental intervention and objections;
• Availability of a PICs amendment process;
• Registry and public awareness of their commitments;
• Remedies for failure of a registry operator to submit PICs;
• Enforceability of PICs, whether by contract compliance or additional means; and
• ICANN criteria for acting on the recommendations of the PICs Dispute Resolution Provider (DRP).
• Remediation methods for registration policies resulting in harm.

While PICs were originally put on the table as an optional means for applicants to demonstrate their commitment to and recognition of responsibility to operate a particular TLD in a beneficial and non-abusive manner, many applicants did not file them because the self-imposed obligations result in no offsetting application award benefit.

The new TLD program rules encourage applicants for the same string in contention sets to resolve matters among themselves. Failing that, contention sets will be settled by auction where the highest bid settles matters irrespective of PICs or other qualitative applicant commitments.

Now the GAC communique may well be pushing PICs toward the status of mandatory and enforceable guarantees. Indeed, a few months ago the United States suggested that all TLD applicants should submit PICs — especially for categories of strings for which the GAC has requested additional safeguards.

If that is the case, then ICANN will eventually need to reopen the PICs submission window. Once filed, PICs are made available for public inspection — although not direct public comment — at the new TLD current application status page.⁹

Enforcement of Accepted GAC Advice

ICANN's Board consideration of the GAC communique is now clearly underway. The process raises threshold questions of whether and how various categories of GAC recommendations will be accepted, as well as multiple subsidiary issues of consideration of public comments, modification and implementation.

While we don't yet know which of the GAC advice will be accepted by ICANN, or with what modifications or implementation details, the realpolitik's of the current situation appear to dictate that a substantial number will find themselves into the final requirements for the first round of new TLDs.

That raises the question of how the safeguards and other accepted elements of GAC advice can be implemented in a manner that is "subject to contractual oversight by ICANN."

The standard approach would be to amend the RA so that the requirements for all similarly situated registry operators are uniform. But that could well require substantial additional delay in the new TLD program — first to draft concrete expressions of broad and subjective requirements and devise appropriate enforcement criteria, and then to republish the amended RA for further public comment.

The apparent controversy being generated by the April 29 RA revision drives home the possibility of extended delay.

The alternative approach would be to reopen the PICs window and require all applicants to submit initial or revised PICs that address the GAC's safeguards and other accepted advice.

But that would place an enormous review and feedback/revision burden on ICANN staff, as well as result in significantly disparate approaches and commitments from applicants seeking to operate in the same sector categories.

If a standard approach to consumer protection and harm mitigation are the main goals then a uniform approach through RA modification would seem the best route to assuring consistent implementation of safeguards.

Realpolitik 101: Substantial Portions of the GAC Communique Will Be Accepted and Implemented

Critics of the Beijing GAC communique may well assert that it comes two years too late, imposes inappropriate and vague burdens on registry operators that negatively impact their business models, gives governments an inappropriately enhanced role in ICANN's multistakeholder process, offloads governmental responsibilities onto the private sector, and will cause further delay in the new TLD program, among other complaints.

While there is some justification for those assertions, they are also beside the point.

ICANN is a unique and inherently fragile entity — a standalone nonprofit corporation imbued with authority to manage the addressing system of the most powerful global telecommunications network ever devised, dealing with issues that routinely intrude on legal and policy decisions normally the province of national governments or multinational organizations.

While freed of formal U.S. oversight in 2009, ICANN lacks the mass and velocity to escape governmental oversight of some type. Further, with ICANN no longer under the clear protective wing of a superpower, it must forge a rapprochement with the multi-governmental GAC to assure long-term viability.
Despite its CEO's articulation of "the multi-equal stakeholder model," in ICANN world, as in Orwell's Animal Farm, some stakeholders are more equal than others.

The Beijing communique can be regarded as the completion of a four-year governmental journey within ICANN since the termination of formal U.S. oversight and its replacement by the Affirmation of Commitments (AOC). There should be no surprise that it took so long — governments are by nature reactive and risk-averse entities, and the scale of the TLD program and the unexpected issues that developed added to the response time.

GAC members arrived early in Beijing and labored long hours over the course of an entire week to produce the communique. In a way, that commitment of time and effort, and the delivery and content of the document, signaled a broad multi-governmental embrace of the ICANN model and of the new TLD program. Imagine if, instead of proposing safeguards, the GAC had announced that the perceived threats to consumer protection, intellectual property, online competition and innovation, DNS stability and security, and other potential negatives generated by the program simply outweighed the potential benefits — and that therefore it should be halted. ICANN and applicants would now be in a crisis state if that had occurred.

If ICANN were now to reject the bulk of the GAC safeguards and other recommendations there might be no immediate dire consequences. What there likely would be is a collective decision by many governments that ICANN involvement is not worth the time and expense, and a drifting away of government involvement.

If, on the other hand, ICANN now adopts, with reasonable modifications, the bulk of the GAC advice it will provide the feedback that participating governments need to justify continued engagement — as well as to defend ICANN's model within other forums.

Continued Threats From ITU

The threat to ICANN's role and existence is far from dissipated — the International Telecommunication Union (ITU) will hold its World Telecommunication Policy Forum (WTPF) in Geneva this month, and the UN Internet Governance Forum is preparing for its next meeting in Bali, Indonesia. ICANN must continue to befriend governments, not alienate them.

A general embrace of the GAC communique can help ensure ICANN's long-term support from governments and thereby its survival — and, as for most organizations, self-preservation is a high priority. The survival of ICANN, whatever its flaws, is also better for business, civil society, and other constituencies than ICANN's replacement by a DNS manager in which governments have control rather than just substantial influence.

The GAC communique and responsive requests for comments provide an opportunity for everyone involved in ICANN and every interest affected by the new TLD program to submit final input on its proposed framework for the launch of new TLDs. Yes, it will likely cause some delay; and yes, it will impose unanticipated duties and responsibilities on all registry operators, particularly those seeking to operate strings related to sensitive sectors. But it also provides a blueprint for the means by which ICANN and registry operators can work cooperatively with the global public sector in decades to come.

ⁱ http://www.icann.org/en/news/announcements/announcement-2-10may13-en.htm

ⁱⁱ http://www.icann.org/en/groups/board/documents/agenda-new-gtld-18may13-en.htm

ⁱⁱⁱ http://www.icann.org/en/news/press/kits/video-gac-advice-10may13-en.htm

^iv http://forum.icann.org/lists/comments-gac-safeguard-advice-23apr13/

¹ https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee

² http://newgtlds.icann.org/en/announcements-and-media/announcement-18apr13-en

³ http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en.htm

⁴ http://www.icann.org/en/groups/board/documents/agenda-new-gtld-08may13-en.htm

⁵ The Proposed Final 2013 RAA was issued for public comment on April 22, with the initial and reply comment periods ending on June 4 — see http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm

⁶ http://www.icann.org/en/news/public-comment/base-agreement-29apr13-en.htm

⁷ http://forum.icann.org/lists/comments-closed-generic-05feb13/

⁸ http://forum.icann.org/lists/comments-base-agreement-29apr13/msg00000.html

⁹ https://gtldresult.icann.org/application-result/applicationstatus

Copyright © 2013 by The Bureau of National Affairs, Inc.

Reproduced [or Adapted] with permission from Electronic Commerce & Law Report, Vol. 18, No. 20 (May 7, 2013). Copyright 2013 The Bureau of National Affairs, Inc. (800-372-1033) www.bna.com.

Written by Philip S Corwin, Founding Principal of Virtualaw LLC, a Washington, DC Law and Public Policy Firm

But what the industry shouldn't overlook, especially in the face of the expected critical responses this week and next, is that the Governmental Advisory Committee's (GAC's) formal advice from the ICANN Beijing meeting represents an opportunity for the domain name industry to lock-in self-regulation at a critical point in its evolution.

IFFOR has been focused for some time on the question of what registries will need to do in a world where domain names can end in any word. As such, we see the GAC advice as a simple reflection of genuine, and understandable, concerns from a body whose main job is to identify public policy issues.

It is also nothing new: IFFOR went through this exact process to find policy solutions to questions raised by GAC over the dot-xxx top-level domain. Many of the same issues are present in this most recent advice — something we highlighted at the beginning of the year.

So here is the good news: it is perfectly possible to find a simple, effective and lightweight solution that will meet the concerns of governments — including that it be contractually binding — while keeping ICANN firmly out of content regulation.

It is also possible to do it right now without compromising business plans, redrawing financial projections, or seeking hundreds of thousands of dollars in new investment.

So what is this solution?

As part of the process for reaching agreement with both ICANN and the GAC over the dot-xxx top-level domain, a set of "baseline policies" was created (by IFFOR) to demonstrate a clear commitment to resolving concerns.

Those baseline policies covered issues such as:

• Scanning domains for malware, spam and phishing
• Audit and compliance systems
• Enhanced trademark protections
• Handling complaints
• Registrant verification
• Tackling child abuse images
• Disqualifying applicants that consistently break the policies

The implementation of those policies was then left up to the registry operator — ICM Registry — and IFFOR was also given the role of auditing the subsequent systems.

In response to the GAC advice in Beijing, IFFOR is close to completing a new set of "Safeguard Policies" designed specifically to encompass the six most broad safeguards that the GAC wishes to see apply to all new gTLDs.

In so doing, we have drawn on our original "baseline policies" to develop policies for the gTLD market as a whole, and have used our experience as a registry policy body to ensure all six GAC safeguards are fully addressed.

In an effort to make this work as widely accessible as possible, we plan to simply license these policies for a low annual fee. As well as the right to use, publish and reference the Safeguard Policies, each license will come complete with documentation to help registries implement each policy in the way most suited to their circumstances. We will also extend IFFOR's internal information service that provides ongoing information on related policy and regulatory topics to all licensees. Again, for one, low annual fee.

We believe this approach solves a number of issues:

• It provides applicants with a simple, swift and low-cost answer to government concerns
• It answers government calls for new safeguards
• It builds on a contractual solution that has already been shown to work within the ICANN system
• It removes the need and cost for applicants to develop their own policies
• It keeps the new gTLD program on track

Perhaps most importantly, adopting such an approach will give the industry a chance to demonstrate that it is committed to be a good actor while retaining the flexibility to develop the right systems for the right markets in the right way.

The mark of a self-regulated market is how well it responds to issues identified by a third party. With the right mix of creative pragmatism, the GAC safeguard advice can act as a catalyst for this industry.

If you are interested in learning more about IFFOR's Safeguard Policies, please visit our website at http://iffor.org/safeguard.

Written by Kieren McCarthy, Executive Director at IFFOR; CEO at .Nxt

Here are some of our key takeaways:

• The top 15 hosting providers together accounted for under 35% of where our customers are hosted.
• This means the remaining 65% are either self-hosted or are using smaller hosting providers.
• These numbers go further when we look at a wide cross-section of Alexa websites: 25% for the Alexa 10K and 21% for the Alexa 100K.

Amazon AWS, Rackspace and Softlayer clearly hold the top three spots for market share.

Here's what we found, thanks to some great insight from our friends at Datanyze:

DynECT Customers

About 22% of our 2000+ DynECT enterprise level customers are hosted at either Amazon AWS, Rackspace and Softlayer with Amazon ranking No. 1.

Alexa 10K and Alexa 100K

Next up: Alexa 10K and 100K segments. Did we see any interesting patterns?

• AWS and Softlayer seem to have the highest market share in the Alexa 10K segment.
• Softlayer has the largest share in in the broader & lower traffic Alexa 100K segment.
• As expected, lower-priced hosting sites like GoDaddy, Ovh, and Hetzner had relatively higher market share in the Alexa 100K than in the Alexa 10K websites.

Large Enterprises

For this study, it was important for us to review websites with high traffic. However, we also wanted to look at where the large enterprises were hosted, defined as any company with more than 1000 employees. We looked at a total of 25K such enterprises globally for this analysis.

The total penetration for this segment is about 11.3%, with the graph below showing Rackspace with thrice the market share as the next largest provider. This will be an interesting market segment to keep an eye on.

Our conclusions

We'll use this unique to Dyn customer hosting data to improve DynECT Managed DNS and Traffic Management services, prospect more joint accounts, and forge strong hosting partnerships with shared vendors of our esteemed clients. Amazon AWS, Rackspace and Softlayer prove to be glaringly obvious collaborative partners, but the opportunity for lower cost or specialized hosting providers to layer on a premium DNS services is equally apparent (see our favorites and host of Dyn.com, Firehost).

Using Managed DNS and DNS-based Traffic Management (load balancing) services as a performance facilitator, traffic controller, hosting redundancy enabler and overall abstraction layer for content delivery is on the rise. Contact us if there are any other interesting studies you'd like us to research and share.

Michael Boustridge joins Dyn's Board of Directors

Boustridge is the former President of BT Global Services, a company that delivers a combination of communications and IT services to customers organizations and governments worldwide. He joined BT Global Services in April 2007, assuming responsibility for all aspects of their operations and performance in the United States and Canada and Financial Services and finally running all of the Global MNC (MultiNational Customer) business.

"Michael brings a long-term view of technology and insight into how larger companies operate that will help us navigate our future," said Jeremy Hitchcock, Dyn CEO.

The addition of Boustridge to Dyn's board is another nod toward the company's continued focus on international expansion and the development of new enterprise channels — two specialties of the Texas-based tech legend.

"When joining a board, I want to associate myself with companies that are applying innovative approaches to technology and solving real world problems," Boustridge said. "I have found both of those with Dyn. This is a company with an amazing track record and an even brighter future. I am happy to be playing a small role in helping guide that future."

Prior to the BT run, he was the Chief Sales and Chief Marketing Officer at EDS, an information technology equipment and services company founded by Ross Perot, where he led the company's $22 billion global revenue sales engine.

In addition, Boustridge is member of the Board of Trustees for XPRIZE Foundation, an educational nonprofit organization with the mission to bring about radical breakthroughs for the benefit of humanity, as well as other high tech companies. He also sits on the board of Riverbed Technology, Inc., Ciber, Contact Solutions LLC, Presidio and Cyan.

Boustridge joins a board that already includes:

• Jeremy Hitchcock, Dyn CEO and co-founder
• Jason Calacanis, founder and CEO of Mahalo, co-founder of ThisWeekIn, co-founder and former CEO of Weblogs, Inc. (acq. by AOL) and a respected angel investor
• Ric Fulop, General Partner at North Bridge and co-founder of A123 Systems
• Russ Pyle, General Partner at North Bridge
• Scott Dussault, Executive Vice President and Chief Financial Officer of Demandware

Until recently, ICANN, which is responsible for maintaining the root domain servers at the heart of the DNS system, had no specific guidelines for the reporting of vulnerabilities, leaving responsible disclosure protocols up to the researchers who discovered the bugs. With the release of the Coordinated Vulnerability Disclosure Reporting [PDF] document they hope to instigate a more unified and consistent process for disclosure.

The guidelines are intended to:

"define the role ICANN will perform in circumstances where vulnerabilities are reported and ICANN determines that the security, stability or resiliency of the DNS is exploited or threatened. The guidelines also explain how a party, described as a reporter, should disclose information on a vulnerability discovered in a system or network operated by ICANN."

The document outlines procedures that ICANN will follow in various roles, including as an affected party, where the vulnerability directly impacts ICANN's operations; as a reporter, when ICANN researchers discover vulnerabilities; and as a coordinating party.

Security vulnerability reporting is a controversial topic, with some researchers advocating immediate full disclosure, and others opting for responsible disclosure where vendors and stakeholders are notified privately before a full release is made only following the patching of relevant software. There is also a thriving black market for security vulnerabilities, where the information is disclosed only to the highest bidder for use in hacking attacks.

As an essential and ubiquitous part of Internet's infrastructure, the security of the Domain Name System is of particular interest to hackers and those engaged in industrial or state-sponsored espionage. ICANN is advocating a system of responsible disclosure with ICANN itself acting as a coordinator in some cases. Bugs that impact DNS can be reported directly to ICANN, who will then inform affected vendors or service providers.

Public disclosure is strongly discouraged until vendors have been informed of the vulnerability and have fixes in place. However, the methodology recommended by ICANN makes it clear that in the case of vendors who fail to respond to attempts at coordination, researchers may choose to disclose vulnerabilities.

None of these recommendations is binding, and researchers are still free to choose how to react to discovered vulnerabilities. However, the creation of these guidelines is a positive move towards a unified and coordinated system for handling security vulnerabilities in the DNS.

Written by Evan Daniels

http://beijing46.icann.org/

and the full schedule of events can be found at:

http://beijing46.icann.org/full-schedule

A great aspect of ICANN meetings is that most of the meetings have some mechanism for you to view the meeting remotely. If you go into any of the sessions on the schedule, you will see remote participation links — often for both high and low bandwidth connections. In my experience, many sessions are also recorded for later viewing.

Do keep in mind that all times are local to Beijing which is UTC+8 and may not work with your viewing schedule. For instance, there is a 12-hour difference from the eastern US where I live and as a result a session that starts Monday at 9am will be starting Sunday night at 9pm for people in the eastern US..

In the midst of all the more business-focused discussions around domain names and governance questions, there are also some excellent technical tracks. I will be in Beijing specifically for the excellent DNSSEC Workshop and related sessions, as well as attending the IPv6 workshop.

I'm looking forward to the ICANN 46 event — if you will be there, too, please do feel free to say hello. You can pretty much expect to find me in any sessions related to DNS security.

P.S. If you are interested in the views of my employer, the Internet Society, on the events happening at ICANN 46, a few of my colleagues prepared the "Internet Society's Rough Guide to ICANN 46's Hot Topics” that outlines what the organization will be watching and participating in over the next week.

Written by Dan York, Author and Speaker on Internet technologies

While 1) is unavoidable simply due to the additional data that DNSSEC produces, and 2) "should" be practised as part of any provider's network configuration, it is 3) that requires "you and I" ensure that systems are adequately configured.

The fact is open DNS resolvers are nothing new and the open resolver project is tracking approximately 27 million open DNS resolvers. What I find interesting is that their database can be queried for an IP range to see how many open resolvers are listed.

Out of curiosity, I entered the /24 prefix that my personal IP address resides on, 81.174.169.0/24. This range belongs to Plusnet, a popular ISP located within the UK. I was quite surprised that a list of 9 IP addresses came back, I wasn't really expecting any, and fortunately, none of them were mine!

Out of further curiosity, I started using dig to fire off a DNS query for "www.bbc.co.uk" to each of the IP's. Most of them timed out, but as I worked down the list, sure enough, one of them returned an answer. I ran a port scan but couldn't detect any well known open ports other than DNS. So within a few minutes, I had found an open resolver being run on an IP address within the same /24 as my own. This ISP has hundreds of thousands, if not millions of customers, so if extrapolated, there could be thousands of open resolvers present via this one ISP. (Having said that, this list of open resolvers vs AS numbers only lists 7 open resolvers against Plusnet, so maybe I was just (un)lucky...) I would like to think my ISP has implemented BCP-38, but what if they haven't? And how many other ISPs out there haven't?

I have no idea whether CPE routers are providing this open resolver capability or whether people are genuinely running a poorly configured DNS server. The Measurement Factory perform regular surveys for open resolvers and network providers can get them to email a list of open resolvers. They have a useful page here.

I guess it's unfair to place the blame solely at sysadmins when the default setting for BIND up until 9.4 was to allow queries from anyone, and I am sure there are many *nix/*BSD distros that shipped with BIND versions <9.4 (RHEL 5 anyone?) — although you could argue "Why haven't they upgraded?" as we are talking pretty old code here. No, I think more culpable are the network operators who route spoofed traffic out from their network; it is inexcusable that they have not implemented BCP-38 (also known as RFC2827).

However, looking at that list of open resolvers vs ASNs again, the top offender is Brazil, followed by a big block in Asia-Pac, HINET is Taiwan, then Chile, Korea etc. To go to each of these providers, figure out which local networks are the offenders, and communicate all this in a meaningful, constructive way to the end customers, well, it's a gargantuan task!

Unfortunately I do not see a simple solution to this problem, and I fear that with the publicity the Spamhaus attack generated, we will ultimately see more of these kinds of attacks.

If you are curious like me, why not check your local ISP range and see if you can find any open resolvers? You never know what you might find! I'll buy a pint for the person who can find the most… at a date/time/location of my choosing… provided it's in the UK… in the South somewhere… near Reading or Basingstoke! ;-)

Written by Paul Roberts, CEO, Calleva Networks