get ready! New-gTLD Preparedness Project Thoughts August, 2013 © Mikey OConnor (just attribution is fine) version 0.3

Contents Why we need a world-wide new-gTLD preparedness project How well define success What well be doing Where do we go from here?

The need for a new-gTLD preparedness project Impacts of certain new-gTLDs could be very severe for some network operators and their customers There may not be a lot of time to react Progress on risk-assessment and mitigation-planning is poor Fixes may not be identified before delegation Thus, getting ready in advance is the prudent thing to do We benefit from these preparations, even if we dont need them for the new-gTLD rollout Namespace collision Dotless domains Internal Name Certificates

The need for a new-gTLD preparedness project The maddening thing is, we may not know whats really going to happen until its too late to prepare -- so were going to have to make guesses. New gTLD impacts could be very broad and severe, especially for operators of private networks that were planned long before new-gTLDs were conceived of. ISPs may be similarly surprised. Microsoft Active-Directory installations may need to be renamed/rebuilt Internal certificates may need to be replaced Long-stable software and network configurations may need to be revised New attack vectors may arise And so forth...

.com.org.us bar.com SAP.org NetworkArts.us mail.prod server.test accounting.corp router01.cisco shared.pub product.group Internal & trusted (known knowns) External & untrusted (known unknowns) Today DNS Internal system or user asks DNS, where is this resource? Legacy gTLDs Requests from inside a network ask DNS where resources are located DNS distinguishes between resources that are inside and outside the local network If DNS is configured to look for an internal match first, all is well. But if DNS is configured to look for an external match first, then theres possible trouble ahead… Example: Namespace collision

.com.org.us.prod.test.corp.cisco.pub.group bar.com SAP.org NetworkArts.us mail.prod server.test accounting.corp router01.cisco shared.pub product.group Internal & trusted (known knowns) External & untrusted (known unknowns) mail.prod server.test accounting.corp router01.cisco shared.pub product.group External and a surprise (unknown unknowns) Tomorrow DNS Internal system or user asks DNS, where is this resource? Trusted names unexpectedly start routing to external hosts as new gTLDs delegate Legacy gTLDs New gTLDs The Problem: Example: Namespace collision

The need for a new-gTLD preparedness project Given that we dont know what will happen, and we appear to be in a high-risk zone, getting ready is the prudent thing to do – If there are failures, preparedness will be the most effective way to respond – The issues associated with being under-prepared could be overwhelming –Hope for the best, prepare for the worst is a strategy that we often use to guide family decisions -- this rule also applies here – Inaction, in the face of the evidence that is starting to pile up, could be considered irresponsible We benefit from these preparations, even if theyre not needed – We improve security, stability and resiliency of the DNS for all by focusing on building a more nimble, disaster-resistant community – If we are over-prepared we will be in a great position to help others who experience problems – Exercise is good for us -- whether its on a personal level or aimed at strengthening our network neighborhoods and communities

How we define success Here are possible overall objectives for an investment in new-gTLD preparedness efforts: – Minimize the impact of new-gTLD induced failures on the DNS, private and public network infrastructure, and Internet users – Make technical-community resources robust enough to respond effectively in the event of a new-gTLD induced disruption – Maximize the speed, flexibility and effectiveness of response to a new-gTLD induced disruption

AT THE EDGE Identifying needs Organizing, practicing Responding to problems Reporting successes and lessons-learned AT THE CORE Assessing & analyzing risks Developing mitigation tools Providing resources Communicating Coordinating What we should be doing: Connecting, developing and sharing resources ICANN Registries & Registrars Large network operators Businesses Associations Small network operators Governments ISPs Internet users

What we should be doing Overall approach Assessing readiness Determining what we need to do to get ready Forming partnerships Preparing network administrators, large & small Practicing responses Responding Leading - managing - informing Sharing knowledge Identifying resources to share Making and maintaining contact Readiness tracking systems Ongoing conversations with key players Identifying risks and resources Determining priorities Assisting planning efforts Developing coordinated plans Training and outreach activities Acquiring and staging resources Identifying networks with special needs Community of interest gatherings Checking signals between organizations Dry runs Identifying problems Delivering resources/solutions Coordinating efforts Project management Communications Leadership

What we should be doing: Getting started GET STARTED: Share and test different ideas and opinions Discover missed connections Coordinate efforts Identify resources and leaders Build momentum Keep focused GET STARTED: Share and test different ideas and opinions Discover missed connections Coordinate efforts Identify resources and leaders Build momentum Keep focused

Where do we go from here? Right away: Agree that this effort needs attention, support and funding Get started on the organizing Soon: Establish a focal point and resource pool Broaden the partnership base Start tracking what areas are ready and where there are likely to be problems