get ready! New-gTLD Preparedness Project September, 2013 version 0.3

1. get ready!New-gTLD Preparedness ProjectSeptember, 2013version 0.3

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

3. 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 don’t need them for the new-gTLD rollout Namespace collision Internal Name Certificates Dotless domains

4. The need for a new-gTLD preparedness project The maddening thing is, we may not know what’s really going to happen until it’s too late to prepare -- so we’re 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...

5. External & untrusted (known unknowns) Example: Namespace collision .com bar.com Internal system or user asks DNS, “where is this resource?” .org SAP.org .us NetworkArts.us Today Legacy gTLDs DNS • 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 there’s possible trouble ahead… mail.prod server.test accounting.corp router01.cisco shared.pub product.group Internal & trusted (known knowns)

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

7. The need for a new-gTLD preparedness project • Given that we don’t 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 they’re 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 it’s on a personal level or aimed at strengthening our network neighborhoods and communities

8. 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 responseto a new-gTLD induced disruption

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

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

11. 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

12. 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