This particular session also marked the posting of the Proposed Final 2013 Registrar Accreditation Agreement (RAA) for which ICANN is seeking public comment. Getting to this stage, after eighteen months of intense negotiations, is a tremendous collective accomplishment and I would like to convey my sincere appreciation to the Registrar Negotiating Team for their significant contributions and collaborative dialogue throughout the process.

As part of the summit agenda, participants briefed each other on efforts to raise the profile of the DNS sector, provided status reports on various DNS initiatives, and delved into mechanisms that can be utilized to further demonstrate the value of the Internet. For instance, discussions centered on topics such as info graphics for depicting the domain name value chain; philanthropic vehicles to support DNS entrepreneurship in the developing world; industry conferences and consumer awareness forums; and proposals to codify ethical standards for DNS businesses. What I found to be particularly beneficial during our interactive brainstorming sessions were the perspectives and experiences of the ccTLD operators.

We emerged with a timeline for completing our work to be showcased to the broader community at ICANN 47 in Durban in July. I want to emphasize this work was conducted entirely by the CEOs, with ICANN serving as facilitator, and it was truly exciting to see this diverse group of leaders in action.

In addition, a sub-group of participants presented their plans to form a Domain Name Industry Association, entirely independent of ICANN, designed to further the interests of a range of organizations within the ever-evolving DNS sector.

During the latter part of our meeting, we focused on ICANN’s future through an interactive session, one of many conversations to take place in the coming months. As I explained in Beijing, we will begin a process in June toward creating a new vision and a five-year strategic plan for ICANN, and all stakeholders are invited to participate. More information: Video and Strategy Conversation.

I am extremely grateful to everyone who could be there, including ICANN Board Members Cherine Chalaby and Bruce Tonkin, and for their deep insights on how ICANN can continue to achieve its goal of becoming a mature, inclusive and efficient organization. ICANN’s Engagement Team is already at work organizing comparable events and is planning a CEO Roundtable for leaders from academia, civil society and nonprofits in the near future.

Our work, however, is only just beginning as we look ahead to the bright horizon. The New gTLD Program Timeline [PDF, 488 KB] is reflective of these important endeavors, and I remain invigorated by the forward steps that we are all achieving together.

DDoS attacks are serious problems. While ICANN’s role in mitigating these threats is limited, the Security Team offers these insights to raise awareness on how to report DDoS attacks

Distributed Denial of Service attacks have increased in scale, intensity and frequency. The wide range of motives for these attacks – political (hacktivism), criminal (coercion), or social (malice) – makes every merchant or organization with an online presence a potential target. The shared nature of the Internet infrastructure – whether hosting, DNS, or bandwidth – puts many merchants or organizations at risk of becoming collateral damage, as well. If you find that your site or organization is under attack, it’s important that you report such attacks quickly to parties that are best positioned to help you mitigate, weather, and restore normal service.

I’m under attack. What should I do? Whom should I call?

Any Internet service – web, DNS, Internet voice, mail – can be the target of a DDoS attack. If your organization uses a hosting provider for a service that is attacked, first contact the hosting provider. If your organization hosts the network or Internet service that is under attack, first take measures to contain or dampen the attack. Next, call the service provider that provides Internet access for your network. Most hosting providers and ISPs post emergency contacts on their web sites and many include at least general contact numbers on bills. If you only have a general contact number, explain that you are under attack and ask the customer care agent to escalate (forward) your call to operations staff with the ability and authority to investigate.

Helping Hands

Traffic associated with a single DDoS attacks may originate from hundreds or thousands of attack sources (typically compromised PC or servers). In many cases, your hosting provider or your Internet access provider should act on your behalf (and in self-interest). They will contact “upstream” providers and the ISPs that route traffic from the DDoS attack sources to notify these operators of the nature and suspected origins of the attack. These operators will investigate and will typically revoke routes or take other measures to squelch or discard traffic close to the source.

If you cannot find contacts, or if the contacts you find are unresponsive, try contacting a Computer Incident, Emergency, or Security Incident Response Team (CERT/CIRT/CSIRT), or a Trusted Introducer (TI) team. CERT/CIRT organizations (find a national list here) or TI teams will investigate an attack, notify and share information with hosting providers or ISPs whose resources are being used to conduct the attack, and work with all affected parties to coordinate an effective mitigation.

Should I contact Law Enforcement?

Contact your national law enforcement agency if you believe that a crime is being committed; for example, you should contact law enforcement if your organization received a threat prior to the attack, or received a demand for money in return for not being attacked, or if you believe that critical infrastructure or delivery of a critical service (such as Emergency 911) is threatened.

Contact law enforcement to report a crime, not to mitigate an attack. DDoS attacks are criminal acts in many jurisdictions. By filing a report, you and other victims provide valuable information that may be relevant in any subsequent investigation or prosecution of the attackers.

Provide Good Intel

At an operational level, you, your hosting provider or ISP should gather as much information related to the attack as possible. The Operations Security Trust Forum recommends collecting the following kinds information:

1. Provide as much time information as possible: identify the start of attack, end of attack, whether the attacks are repeated, and whether there are observable patterns or cycles to the attacks.
2. Share any insights or suspicions you have regarding the nature of the attack. Does it appear to correlate with a geo-political event? Did you receive threatening correspondence prior to or during the attack and if so, what was the nature of the threat?
3. Provide detailed traffic information including: type of traffic (ICMP, DNS, TCP, UDP, application), source and targeted IP addresses and port numbers, packet rate, packet size, and bandwidth consumed by the attack traffic.
4. Describe any unique traffic or packet characteristics you observe. Is the attack targeting a particular virtual host or domain? What have you observed from application protocol headers? Have you observed any unusual patterns of flag settings in underlying protocols (TCP, UDP, ICMP, IP)?
5. Identify any changes you observe in the attack over time (i.e., to packet sizes, rates, unique IPs seen per epoch, protocols, etc.). These may be indications that the attacker is reacting to mitigation efforts you or others have implemented.
6. Provide your assessment of the impact; for example, explain whether you are managing the attack using mitigations and assistance, or that your services or performance is {moderately, severely} affected, or that your services have been disrupted entirely.

Don’t Wait Until You Are a Victim

If you have not already prepared a plan to respond to a DDoS attack, please consider doing so. The article Preparing for the (Inevitable) DDOS Attack offers a checklist of contacts, information, and mitigation strategies. Some helpful resources to better understand different kinds of DDoS Attacks, mitigation techniques and how your organization can help reduce the overall threat of these attacks are included below:

• SAC004, Securing The Edge
• SAC008, DNS Distributed Denial of Service (DDoS) Attacks [PDF, 963 KB]
• BCP 38, Network Ingress Filtering
• BCP 140, Preventing Use of Recursive Nameservers in Reflector Attacks
• Protecting the World from YOUR Network
• Mitigating DNS Denial of Service Attacks
• The Worrisome Threat of DNS DDoS Amplification Attacks
• Do More to Prevent DDoS Attacks
• Firewall Best Practices – Egress Traffic Filtering
• Distributed Denial of Service (Attacks/Tools)

In the Security team [https://www.icann.org/security], we see this technical engagement with the community as a key part of delivering on ICANN’s mission to facilitate the security, stability and resiliency of the Internet’s unique identifier systems through coordination and collaboration.

We do this with community partners across the globe, at the request of operators and universities in the Caribbean and the Middle East, in Africa, Asia-Pacific and South America. We have increasing interest among the law enforcement community for this training. The Security team recently conducted DNS training at Europol, at the International Criminal Law Network in the Netherlands, and with other agencies in the United Kingdom. We are exploring opportunities with the Commonwealth Cybercrime Initiative, and have upcoming DNSSEC training in Tunis, Tunisia next week.

The community has an opportunity to tell us what you think of this training, and on ICANN’s security activities by commenting on the FY 14 Security, Stability and Resiliency Framework. The document has been translated into 7 languages, and is open for comment through 20 April 2013 (with a reply comment period to 20 May 2013, 23:59 UTC). Please take some time to read this document, and provide comments.

Here is some testimony from Rick Lamb, one of our team members and a lead on DNSSEC adoption and engagement:

I consider myself fortunate to be able to participate in this space, following in the footsteps (and the beneficiary of the experience pool) of other seasoned ICANN trainers.

Although I have taught in the past, I had forgotten about the heady mixture of fear, happiness and exhilaration that comes from interacting with a classroom full of intelligent, interested students. After typically spending the better part of an intense week together, trusted relationships are forged, giving the students not just technical knowledge, but a sense of being part of the larger Internet community. These relationships clearly benefit everyone involved.

I know that these are familiar sensations for my seasoned colleagues, but I think that sometimes we should be reminded about the not-so-obvious value of training efforts and the importance of these personal interactions toward building and maintaining the international network of trust that keeps the international network we call the Internet running.

Dr. Richard Lamb
Sr. Program Manager, DNSSEC, ICANN

If you are interested in more information on these trainings, our partners at NSRC maintain excellent wiki pages providing past training agendas and materials. An example from the Lebanon training can be found at https://nsrc.org/workshops/2013/nsrc-isoclb-dnssec/.

Photo Credit – Phil Regnauld, NSRC

Photo Credit – Phil Regnauld, NSRC

In recent weeks, numerous high profile organizations and financial institutions have been targets of massive service disruption attacks. Several of these attacks are characteristically similar to attacks against top level domain name servers in 2006. ICANN’s Security and Stability Advisory Committee published an Advisory, SAC008 [PDF, 963 KB]: Distributed Denial of Service (DDoS) Attacks, shortly after the 2006 incidents. Recommendations from that Advisory remain relevant today.

We encourage private organizations, service operators and governments to carefully consider the recommendations from SAC 008, which describe the best known means to mitigate DDoS attacks.

“the most effective means of mitigating the effects of… numerous DoS attacks is to adopt source IP address verification” – SAC008

DDoS attacks commonly use IP addresses that are not allocated to the subscriber or IP addresses from reserved/private space to make it difficult to identify sources of attack traffic. This is called IP address spoofing. Access service providers or corporations should apply network ingress filtering (described in SAC004 and recommended by the Internet IAB in BCP038) to prevent spoofing. Squelching attack traffic close to its origins has the added benefit of relieving ISPs from forwarding malicious or criminal traffic. Everyone benefits when every operator filters spoofed source addresses, except would be attackers.

“Document operational policies relating to countermeasures… to protect [your] name server infrastructures against attacks that threaten [your] ability to offer service, give notice when such measures are implemented, and identify the actions affected parties must take to have the measures terminated.” – SAC008

I recently wrote an article, Preparing for the (Inevitable) DDoS Attack, that describes how to develop policies and prepare a response should your organization come under attack.

“disable open recursion on name servers from external sources and only accept DNS queries from trusted sources to assist in reducing amplification vectors for DNS DDoS attacks – SAC008

When open recursion is enabled on a DNS server, that server will accept DNS queries from any client (any IP source address). Attackers exploit open recursive servers in DDoS attacks and amplification attacks. US-CERT Alert TA13-088A recommends that all DNS operators:

• Disable recursion on authoritative name servers
• Limit recursion to authorized clients, and
• Rate limit responses of recursive name servers

Alert TA13-088A also identifies ways for every organization to test whether any of its name servers are open resolvers, and lists sources that describe how to do so for major operating system and name server software. (Note: TA13-088A does not have a resource for Microsoft DNS server, try here.)

The ICANN Security Team encourages you to help mitigate this increasing threat to security, stability, and resiliency.

This roundtable served as a forum for the ccTLDs, from a diverse set of countries, to provide insights about the unique and influential role they play in the DNS ecosystem. I was thankful for the rich dialogue that resulted and which explored the quality of the operational and security functions ccTLDs perform to serve their users and citizens, all within the framework of policies and requirements of their own countries. In addition, the roundtable allowed for valuable feedback and for us to explore ways to enhance our relationship.

Another objective was to consider DNS developments, such as the introduction of new gTLDs, and the rapid pace of innovation within the sector and how this will influence ccTLDs. We also addressed potential challenges to the multistakeholder model of Internet governance in the context of the needs of the next billion Internet users who are scheduled to come online.

I briefed them on a number of ICANN’s operational priorities, as well as the work being undertaken by the registry and the registrar CEOs who participated in last month’s roundtables. Other topics included: 1) the reputational risks and opportunities for ccTLDs and the domain name industry from a media perspective; 2) statistical trends and the interplay between gTLD market changes and ccTLDs over the years; and 3) options for using infographic tools to depict and explain the role of the ccTLDs in the DNS sector.

Something of tremendous importance, which I stressed in my conversations with the ccTLD CEOs, and that I would like to ensure is communicated more broadly: ICANN’s focus should not be on the amount of ccTLD financial contributions, rather emphasis needs to be placed on areas where we can collaborate, as true partners. Working together must take priority over financial considerations that have been stumbling blocks in the past. We share a common goal of bringing value to the Internet and its users – individuals, businesses, citizens and organizations – that is possible through cooperation, alignment of our technical and operational performance, and support of the multistakeholder model.

While the drivers of ccTLD performance cannot be entirely decoupled from the performance of gTLDs, and the DNS sector as a whole, they do have many areas of differentiation. Among the issues we explored is ccTLDs’ focus on the public interest through their role as national entities and in relation to larger, more global economic and social trends.

I am grateful to the CEOs for their participation and look forward to continuing our efforts at a DNS Summit, which will take place next month and will serve as the culminating event for this roundtable series.

Roundtable participants (as pictured) include:

Back Row (from left to right):

David Olive, Vice President, Policy Development Support, ICANN
Frederico Neves, CTO, NIC.br
Roelof Meijer, CEO, SIDN
Xiaodong Lee, CEO, CNNIC
Mathieu Weill, CEO, AFNIC
Chris Disspain, CEO, auDA
Bart Boswinkel, Senior Director, ccNSO Policy Development Support, ICANN
Byron Holland, CEO, CIRA
Richard Wein, CEO, nic.at

Front Row (from left to right):

Sally Costerton, Senior Advisor to the President, Global Stakeholder Engagement, ICANN
Rosalía Morales A., Executive Director, NIC Costa Rica
Sabine Dolderer, CEO, DENIC eG
Lesley Cowley, CEO, Nominet
Lim Choon Sai, General Manager, SGNIC
Marc Van Wesemael, CEO, EURid
Fadi Chehadé, President and CEO, ICANN

This event was part of an ongoing series of small roundtable gatherings with CEOs that will continue in the future. For this particular roundtable, participants represented members and nonmembers of the ccNSO, and were from both smaller and larger-sized ccTLDs. Unfortunately, not all of the invitees could attend. Yet, we were fortunate to be joined by leaders from Latin America, Asia-Pacific, Europe, North America, and the Caribbean.

Over the course of a day and a half the meeting discussed issues of interest to the region, and came up with a number of action items to be undertaken by various related parties. Participants engaged in constructive and open discussions around a range of issues including Internet governance multi-stakeholder model, DNS industry development, ICANN Middle East engagement strategy, and capacity building in related Internet governance areas.

Participants shared views on fostering multi-stakeholder Internet governance mechanisms in the region, and agreed that all stakeholders should be involved. It was noted that stakeholders’ roles should be complementary rather than competitive. Leaders of Internet organizations who were present at the meeting talked to the distinctive roles of their organizations in the global governance ecosystem, and highlighted the community bottom-up participation in the relevant processes. Participants noted that engagement in global policy fora should be two-way as community members have a role to play, and so are the relevant global and regional bodies such as ICANN, ISOC, IETF and the RIRs. Participants also emphasized the importance of capacity building in stimulating engagement and talked to several different activities in that regard.

The meeting was an opportunity for discussing ICANN engagement strategy in the Middle East. A working group of community members was put together early this year to develop a 3-year strategy. Representatives of the working group presented a draft strategy highlighting the overall goals and the strategic focus areas, along with more specific objectives and actions suggested under each area. Strategic areas identified for the Middle East included DNS security and stability, DNS industry development, and Internet Governance ecosystem. The draft strategy document should be available for public comments before end of March, and final strategy should be finalized by May.

Developing domain name markets in the Arab world was another topic on the agenda. Statistics showed that the region was far lagging behind in this sector in comparison to other parts of the world. The meeting noted the slow uptake in IDNs despite the deployment of IDN ccTLDs in almost a dozen countries. Participants shared insights regarding the challenges in this sector and highlighted issues pertaining to awareness, cost, policy and legal frameworks, infrastructure and hosting services, lack of localized content as the main barriers to entry. Participants agreed that stimulating innovation and entrepreneurship is one key pillar for success in this industry.

In the closing session, participants wrapped up discussions that had taken place throughout the course of the meeting, and agreed on a number of actions to be taken forward.

Regarding the Arab IGF, it was agreed that the Arab IGF should play a key role in stimulating multi-stakeholder Internet governance mechanisms at national and regional levels, through working with various stakeholders from governments, business, academia, as well as ISOC chapters. Participants noted that the Arab IGF should have a sustainable funding mechanism to ensure stability and continuity. Internet organizations together with UN ESCWA reiterated their commitment to support the Arab IGF.

ICANN emphasized its commitment to work with Arab Internet stakeholders, and confirmed that issues addressed during the meeting in relation to DNS industry and IDNs will take priority in the ICANN Middle East strategy. ICANN also sought partnership of Internet organizations and stakeholders from the region in the implementation of the strategy. Likewise, TRA UAE confirmed its commitment to work with ICANN and Internet organizations.

ISOC, RIPE NCC and AfriNIC reiterated that they would continue to promote capacity building in the region through workshops and support of activities such as MENOG and the building of IXPs.

Participants acknowledged that engaging in Internet policy development processes requires efforts by all parties involved. They commended that this meeting had brought all stakeholders around the table, and agreed that they would come back later this year at the Arab IGF meeting to report on progress made and follow up on takeaways from this meeting.

Event pictures: http://www.flickr.com/photos/icann/sets/72157632937238878/

Over the course of a day, we discussed the evolution of the DNS sector from a number of perspectives and explored the opportunities and risks that these changes pose. The group provided constructive ideas about creating a platform for growth, innovation, and greater consumer and investor awareness. Research analysis, the creation of an infographic depicting the DNS ecosystem, and mechanisms to educate the media and public about the DNS sector were also highlighted.

In short, we addressed common goals, shared responsibilities and the value of raising awareness among consumers worldwide of the DNS sector, affirming our commitment to the public interest. I also expressed my hope and vision for a strengthened and streamlined business contracting framework between ICANN and its contracted parties.

While the topic of the roundtable was not the new gTLD program, I was asked to clarify recent comments I made at the ICANN Registry and Registrar meeting in Amsterdam. I took the opportunity to reassure everyone that:

• ICANN remains focused on the new gTLD timeline, and I am confident that we can do so without comprising ICANN’s deep, immovable commitment to the stability of the DNS.

• We do not foresee any delays of the new gTLD program, we are working to assure that none occur, and the entire organization is pressing forward to comply with deadlines.

• We have assembled a team of qualified professionals, experienced in making complex programs fully operational, and they have my full confidence. Staff is working hard and it is important for the community to be aware of the intense demands placed upon them by the schedule.

• We will continue to increase the volume of communications pertaining to operational details of the new gTLD program, addressing both the technical and political risks encountered at various decision points.

• I will also endeavor to explain, to the extent possible, the trade-offs and various considerations being balanced during each implementation milestone of the new gTLD program.

I am grateful to the registry leaders for their candid, constructive feedback and look forward to continued dialogue as we host more CEO roundtables through the spring. Finally, I have asked past roundtable participants to consider participating in a DNS Summit meeting to serve as the culminating event for this series.

Roundtable participants (as pictured) include:

Top Row (from left to right): Fadi Chehadé, Edmon Chung, Raymond King, Paul Stahura, Adrian Kinderis, Khashayar Mahdavi, Thomas Embrescia, Santi Ribera and Cary Karp

Bottom Row (from left to right): D. James Bidzos, Antony Van Couvering, Stuart Lawley, Byron Henderson, Brian Cute and Frank Schilling

To the ICANN Community,

I believe The Domain Name System — and the Industry that has grown up around it — are at an inflection point.  With the impending introduction of new gTLDs and the vertical integration of the DNS value chain, we, as leaders within the DNS ecosystem, must be ready to meet the challenges ahead.

I am writing to tell you about my plans to meet with leaders of this marketplace to exchange ideas and information about the forthcoming challenges that this sector is likely to face.  Sharing this information will help me gain a better understanding of what to expect, and how best to lead ICANN in partnering effectively with all stakeholders as this sector grows and matures.

To achieve this, I am organizing a series of CEO Roundtables throughout 2013 to engage directly with leaders of the DNS industry.  Our talks will focus on macro trends affecting the DNS sector, the impact of new gTLDs, and the need to evolve the frameworks that govern relationships among DNS industry participants.

The first roundtable is to be held in mid January with registrars.  Other roundtables will follow, including with the registries and other key players in the DNS ecosystem.  Throughout the year, I plan to share the content of these discussions and engage across the spectrum of ICANN stakeholders.

My aim, as always, is to ensure that ICANN is serving both the DNS sector and the broader global public interest – fulfilling our mandate to enable competition and choice, while remaining a responsible steward of the DNS.

I look forward to these events and to sharing the insights we gather with all of you in the coming months.

Sincerely,
Fadi

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

The new IPv4 address for this authority is 199.7.91.13.

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

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

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

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

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

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

Diigo is a social annotation and bookmarking service that millions of individuals, educators, and students use daily to manage and share information, conduct research and collaborate. On October 24th, an attacker gained control of Diigo’s domain registrar account. Domain was hijacked away from Diigo’s control, into the hands of an attacker and Diigo’s services were lost to an estimated five million users for more than two days. TechCrunch has published a detailed account of the incident which should serve as a sobering reminder for everyone who registers a domain: your domain name is a critical component of your online presence and you must take measures to monitor and safeguard against attacks that can disrupt the services you offer, impede research, cause you material loss or reputational harm.

Domain hijacking is not new. ICANN’s Security, Stability and Advisory Committee (SSAC) began raising awareness of the threat in 2006 in its first Domain Hijacking Report. Since 2006, SSAC and members of ICANN’s Security Team have recommended measures registrants can take to protect their domain name registration accounts and ways that registrars can assist them (SAC040, SAC044).

The Diigo incident is a case involving user account compromise, extortion, and unauthorized transfer of domain. Among other measures recommended, these reports emphasize the importance of protecting accounts with credentials (usernames and passwords) that are not easily guessed or obtained through social engineering. Remember: any party who has access to your credentials – you, staff you contract with to host your web site, or registrar staff – can be a target and victim of a social engineering attack.

The reports also explain the importance of using “locks” to prevent unauthorized transfers. Another SSAC reports explain how a domain name can be hijacked by a phishing attack: here, a registrar-impersonating phisher lures a registrar’s customer to a bogus copy of the registrar’s customer login page, where the customer may unwittingly disclose account credentials to the attacker who can then modify or assume ownership of the customer’s domain names.

Our “short list” of measures all registrants should take to protect against domain hijacking or other domain name attacks includes:

1. Protect domain name account credentials. Most registrar account portals are password protected, so create strong passwords, and safeguard them. You may also want to shop for a registrar that offers multi-factor authentication (e.g., token).
2. Use SSL (HTTPS) when you access your domain name registration account.
3. Use ICANN accredited registrars. Ask about the reputation and service record of registrars. If you’re not entirely comfortable with a registrar, you can and should consider transferring your domain to a party you trust.
4. Ask your registrar to apply registrar locks on your domain names. Locks (formally, status codes) prevent changes to your domain name registrations, and block attempts to transfer or delete your domain names (see SAC044, pp 22-23). A number of TLD registry operators offer registry lock to prevent unintended changes to registry accounts. This service is offered in addition to lock services offered by registrars, and often includes manual support (1, 2).
5. Pay attention to “routine” registrar correspondence, as these may be phishing emails. In these email messages, phishers often use HTML to embed malicious links in seemingly innocuous or “safe” links. Don’t click on a hyperlink; instead, type the link in manually.
6. Monitor your domain’s WHOIS and DNS information. Check both routinely so you can detect any unauthorized or suspicious changes (see SAC044, pp 20-22).
7. Keep your domain name registrant account information private, secure, and recoverable.

For more information, you may also find these articles helpful:

Measures to protect (University) domain registrations and DNS against attacks
http://securityskeptic.typepad.com/the-security-skeptic/2011/07/measures-to-protect-university-domains-against-attacks.html

Podcast: How to protect your domain registration accounts against attack or misuse
http://securityskeptic.typepad.com/the-security-skeptic/2011/02/podcast-how-to-protect-your-domain-registration-accounts-against-attack-or-misuse.html

Why You Need To Add “Protect Domain Name” To The Security Checklist
http://www.networkcomputing.com/data-protection/why-you-need-to-add-protect-domain-name/229616011

How To Protect Yourself Against Domain Name Hijackers
http://www.informationweek.com/how-to-protect-yourself-against-domain-n/170000337

Want to Register a Domain Name? Easy Consumer Advice
http://blog.consumerwebwatch.org/2007/12/want_to_register_a_domain_name_1.html

Top Ten Things to Consider when Registering A Domain Name
http://www.consumerwebwatch.org/pdfs/domainname.pdf