DOCSLIB.ORG

Africa Domain Name System Market Study Report, 6Th June 2017, SACF

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

THE 2016 AFRICAN DOMAIN NAME SYSTEM MARKET STUDY FINAL REPORT 6th June 2017 Acknowledgements The authors would like to thank the many people who made this report possible. They include our many country leaders (who between them spoke Arabic, English, French, Portuguese and a number of other languages), our researchers and our contributors and editors. In particular we would like to mention William Stucke who served as the SACF Project Leader and chief editor, Anriette Esterhuysen, Lucky Masilela, Mark Elkins, Mike Jensen, and Sami Salih. Afilias, EyeDomain, ISOC-SD, ZACR and ZISPA, were particularly helpful in providing data for analysis. Africa Domain Name System Market Study Report, 6th June 2017, SACF Page 2 of 214 AFRICA DOMAIN NAME SYSTEM MARKET STUDY Table of Contents 1 EXECUTIVE SUMMARY ................................................................................................ 10 1.1 Methodology ...................................................................................................... 10 1.2 The African Ecosystem ........................................................................................ 11 1.3 African DNS Market ............................................................................................. 12 1.4 Success factors................................................................................................... 15 1.5 Recommendations .............................................................................................. 17 1.5.1 Infrastructure ............................................................................................... 17 1.5.2 Internet Service Demand ............................................................................... 17 1.5.3 Policy and Regulation .................................................................................... 18 1.5.4 Local Content ............................................................................................... 19 1.5.5 Inhibiting Factors .......................................................................................... 19 1.5.6 Registry Specific Recommendations ................................................................ 19 2 INTRODUCTION ........................................................................................................ 20 3 PROJECT BACKGROUND ............................................................................................. 23 3.1 Project Objectives ............................................................................................... 23 4 METHODOLOGY ......................................................................................................... 25 4.1 Development of Targets for Data Gathering ........................................................... 25 4.2 The Online Survey Tool ........................................................................................ 29 4.2.1 Interface Design ........................................................................................... 29 4.2.2 Question Development .................................................................................. 30 4.2.3 Language and Translation .............................................................................. 30 4.2.4 Questionnaire Statistics ................................................................................. 31 4.3 Data Gathering Strategy and Preparation ............................................................... 31 4.3.1 Training ....................................................................................................... 31 Africa Domain Name System Market Study Report, 6th June 2017, SACF Page 3 of 214 4.4 Data Analysis Procedures ..................................................................................... 32 5 THE AFRICAN DNS ECOSYSTEM .................................................................................. 35 5.1 Africa Rising ....................................................................................................... 35 5.2 The African Domain Name Space .......................................................................... 36 5.3 Internet Use ....................................................................................................... 38 5.3.1 Digital Literacy ............................................................................................. 40 5.3.2 Language Literacy and Impact of Local Content ................................................ 42 5.3.3 Access to Smart Devices ................................................................................ 43 5.3.4 Cost to Communicate .................................................................................... 45 5.4 Internet Infrastructure ........................................................................................ 47 5.4.1 Backbone Infrastructure ................................................................................ 48 5.4.2 Local Access Infrastructure - the Retail/Local Loop ............................................ 51 5.4.3 IXPs and Data Centres .................................................................................. 58 5.4.3.1 IXPs .......................................................................................................................................... 59 5.4.3.2 Data Centres ............................................................................................................................ 75 5.4.4 IP Infrastructure ........................................................................................... 80 5.4.5 ISP Associations and IXPs .............................................................................. 83 5.5 Content and the African DNS ................................................................................ 84 5.5.1 Types of Content Hosted ................................................................................ 84 5.5.2 Digital Entrepreneur Development .................................................................. 85 5.5.3 SMEs and E-Commerce ................................................................................. 86 5.5.4 Volumes of Content by Country ...................................................................... 87 5.5.5 Offshore and On-Continent Hosting ................................................................. 92 5.5.5.1 Afilias gTLD Domains ............................................................................................................... 92 5.5.5.2 EyeDomain gTLD Domains ....................................................................................................... 98 5.5.5.3 gTLD Summary ....................................................................................................................... 102 5.5.5.4 Comparison of ccTLD and gTLD domains .............................................................................. 104 5.5.5.5 African Zone Files ................................................................................................................... 104 5.5.5.6 Lesotho .................................................................................................................................. 106 Africa Domain Name System Market Study Report, 6th June 2017, SACF Page 4 of 214 5.5.5.7 Sudan ..................................................................................................................................... 106 5.5.5.8 Zimbabwe .............................................................................................................................. 107 5.5.5.9 South Africa ........................................................................................................................... 108 5.5.5.10 City gTLDs: .CAPETOWN, .DURBAN & .JOBURG................................................................. 108 6 KEY FEATURES OF THE AFRICAN DNS MARKET ........................................................... 110 6.1 Internet Services - Institutional Roles .................................................................. 110 6.1.1 Regional and National ICT Policy, Strategies and Regulatory Authorities ............ 110 6.1.1.1 ICANN ..................................................................................................................................... 110 6.1.1.2 AfriNIC .................................................................................................................................... 110 6.1.1.3 The African Union (AU) .......................................................................................................... 110 6.1.1.4 The Regional Economic Communities (RECs) ........................................................................ 111 6.1.1.5 National Policy and Regulatory Bodies .................................................................................. 111 6.1.2 DNS Governance ........................................................................................ 114 6.1.3 The Influence of Politics on Telecommunications and the Internet ..................... 115 6.2 The ccTLD Address Space in Africa ...................................................................... 117 6.3 The Demand for African Domain Names ............................................................... 118 6.3.1 Local Entities .............................................................................................. 118 6.3.2 Offshore Entities ......................................................................................... 119 6.3.3 Domain Hacks
Recommended publications
  • Whisperkey: Creating a User-Friendly URL Shortener

    Whisperkey: Creating a User-Friendly URL Shortener

    WhisperKey: Creating a User-Friendly URL Shortener Eunice Lin, Flora Tan, Linda Wang May 12, 2016 Abstract of links. Unlike other popular URL shorteners such as Tinyurl or Bitly that map the original URL to a URL shorteners convert long, unwieldy URLs into random string of letters and numbers, ShoutKey was shorter ones and redirect all requests to the short- designed to be user-friendly by using keys that are ened URL to the original website. In this project, standard English words that are easily pronounced we investigate the security flaws of ShoutKey, an or spelled. This makes it easy for users to share easy-to-use temporary URL shortener that maps a link to those in close proximity, for example, by simple dictionary words to a given URL of interest. verbally telling the key to a friend across the room or writing it on a whiteboard at the front of class. We first conduct a security analysis of the vulnera- Anyone who goes to the ShoutKey link can access bilities encompassed by Shoutkey. Then, we conduct the corresponding URL. a standard dictionary attack to access private URLs, storing the successful dictionary words in a separate database to conduct a second, more optimized dic- tionary attack, and analyzing the successful redirects to determine if there is any leakage of private user data. Finally, we propose a more secure implementa- tion of ShoutKey called WhisperKey and empirically analyze how WhisperKey is designed to be less prone to security attacks than ShoutKey is. 1 Introduction 1.1 URL Shorteners Figure 1: A ShoutKey with "laugh" as its key.
  • Phishing Detection Using Machine Learning

    Phishing Detection Using Machine Learning

    Phishing detection using machine learning MSc Research Project MSc Cyber Security Suraj Wandhare Student ID: 18157432 School of Computing National College of Ireland Supervisor: Ben Fletcher www.ncirl.ie National College of Ireland Project Submission Sheet School of Computing Student Name: Suraj Wandhare Student ID: 18157432 Programme: MSc Cyber Security Year: 2019 Module: MSc Research Project Supervisor: Ben Fletcher Submission Due Date: 03/02/2020 Project Title: Phishing detection using machine learning Word Count: 3500 Page Count: 11 I hereby certify that the information contained in this (my submission) is information pertaining to research I conducted for this project. All information other than my own contribution will be fully referenced and listed in the relevant bibliography section at the rear of the project. ALL internet material must be referenced in the bibliography section. Students are required to use the Referencing Standard specified in the report template. To use other author's written or electronic work is illegal (plagiarism) and may result in disciplinary action. I agree to an electronic copy of my thesis being made publicly available on NORMA the National College of Ireland's Institutional Repository for consultation. Signature: Date: 3rd February 2020 PLEASE READ THE FOLLOWING INSTRUCTIONS AND CHECKLIST: Attach a completed copy of this sheet to each project (including multiple copies). Attach a Moodle submission receipt of the online project submission, to each project (including multiple copies). You must ensure that you retain a HARD COPY of the project, both for your own reference and in case a project is lost or mislaid. It is not sufficient to keep a copy on computer.
  • Longitudinal Study of Links, Linkshorteners, and Bitly Usage on Twitter Longitudinella Mätningar Av Länkar, Länkförkortare Och Bitly An- Vänding På Twitter

    Longitudinal Study of Links, Linkshorteners, and Bitly Usage on Twitter Longitudinella Mätningar Av Länkar, Länkförkortare Och Bitly An- Vänding På Twitter

    Linköping University | Department of Computer and Information Science Bachelor’s thesis, 16 ECTS | Link Usage 2020 | LIU-IDA/LITH-EX-G--20/001--SE Longitudinal study of links, linkshorteners, and Bitly usage on Twitter Longitudinella mätningar av länkar, länkförkortare och Bitly an- vänding på Twitter Mathilda Moström Alexander Edberg Supervisor : Niklas Carlsson Examiner : Marcus Bendtsen Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer- ingsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko- pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis- ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker- heten och tillgängligheten finns lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman- nens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/. Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to down- load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose.
  • Draft 7-17-11 an EMPIRICAL ANALYSIS of FAIR USE

    Draft 7-17-11 an EMPIRICAL ANALYSIS of FAIR USE

    Draft 7-17-11 AN EMPIRICAL ANALYSIS OF FAIR USE DECISIONS UNDER THE UNIFORM DOMAIN-NAME DISPUTE-RESOLUTION POLICY David A. Simon INTRODUCTION ................................................................................................................................................ 1 I. THE UDRP AND ITS PROBLEMS ............................................................................................................... 7 II. METHODOLOGY ..................................................................................................................................... 12 A. Sample Selection: Method of Selection .......................................................................................... 13 B. Types of Cases Selected for Sample............................................................................................... 14 III. FINDINGS ................................................................................................................................................ 17 A. U.S. Respondents Win Twice as Many Fair Use Cases as Other Respondents ............................. 17 B. U.S. Law Dominates UDRP Decisions .......................................................................................... 21 C. U.S. Panels Decide Mostly Cases Involving U.S. Respondents ..................................................... 23 IV. IMPLICATIONS ........................................................................................................................................ 25 A. Explaining U.S. Favoritism
  • Afilias Limited Request 28 January 2020

    Afilias Limited Request 28 January 2020

    Registry Services Evaluation Policy (RSEP) Request January 17, 2020 Registry Operator Afilias Limited Request Details Case Number: 00941695 This Registry Services Evaluation Policy (RSEP) request form should be submitted for review by ICANN org when a registry operator is adding, modifying, or removing a Registry Service for a TLD or group of TLDs. The RSEP Process webpage provides additional information about the process and lists RSEP requests that have been reviewed and/or approved by ICANN org. If you are proposing a service that was previously approved, we encourage you to respond similarly to the most recently approved request(s) to facilitate ICANN org’s review. Certain known Registry Services are identified in the Naming Services portal (NSp) case type list under “RSEP Fast Track” (example: “RSEP Fast Track – BTAPPA”). If you would like to submit a request for one of these services, please exit this case and select the specific Fast Track case type. Unless the service is identified under RSEP Fast Track, all other RSEP requests should be submitted through this form. Helpful Tips • Click the “Save” button to save your work. This will allow you to return to the request at a later time and will not submit the request. • You may print or save your request as a PDF by clicking the printer icon in the upper right corner. You must click “Save” at least once in order to print the request. • Click the “Submit” button to submit your completed request to ICANN org. • Complete the information requested below. All fields marked with an asterisk (*) are required.
  • Outcomes Report of the GNSO Ad Hoc Group on Domain Tasting

    Outcomes Report of the GNSO Ad Hoc Group on Domain Tasting

    GNSO Outcomes Report on Domain Tasting Doc. No.: Date: 2007/02/04 4 October, 2007 OUTCOMES REPORT OF THE GNSO AD HOC GROUP ON DOMAIN NAME TASTING 4 October 2007 Group Chair: Mike Rodenbaugh ICANN Staff: Olof Nordling, Patrick Jones STATUS OF THIS DOCUMENT This is the final version of the Outcomes Report from the GNSO ad hoc group on Domain Name Tasting, submitted to the GNSO Council on 4 October, 2007. GNSO Outcomes Report on Domain Tasting v1.6 Authors: Mike Rodenbaugh, [email protected] , Olof Nordling, [email protected] , Patrick Jones, [email protected], Page 1 of 144 GNSO Outcomes Report on Domain Tasting Doc. No.: Date: 2007/02/04 4 October, 2007 TABLE OF CONTENTS 1 EXECUTIVE SUMMARY 3 2 OBJECTIVE 5 3 BACKGROUND 7 4 OUTCOMES 10 5 NEXT STEPS 32 ANNEX 1 - SUBSCRIBERS TO THE DT LIST 33 ANNEX 2 - RFI RESPONSES 34 ANNEX 3 - EXPERIENCES FROM CCTLDS 97 ANNEX 4 - COMMENTS FROM UDRP PROVIDERS 104 ANNEX 5 – IPC CONSTITUENCY SUPPLEMENTAL RFI116 ANNEX 6 – REQUEST TO VERISIGN 144 GNSO Outcomes Report on Domain Tasting v1.6 Authors: Mike Rodenbaugh, [email protected] , Olof Nordling, [email protected] , Patrick Jones, [email protected], Page 2 of 144 GNSO Outcomes Report on Domain Tasting Doc. No.: Date: 2007/02/04 4 October, 2007 1 Executive summary 1.1 Background Following a request from the At-Large Advisory Committee in spring 2007, the GNSO Council called for an Issues Report on Domain Tasting from ICANN Staff in May 2007. This Issues Report, available at http://gnso.icann.org/issues/domain- tasting/gnso-domain-tasting-report-14jun07.pdf was discussed at the ICANN San Juan meeting, where the GNSO Council on 27 June 2007 (minutes at http://gnso.icann.org/meetings/minutes-gnso-27jun07.shtml) resolved to establish an ad hoc group for further fact-finding on the practice of domain tasting.
  • The Secondary Market for Domain Names”, OECD Digital Economy Papers, No

    The Secondary Market for Domain Names”, OECD Digital Economy Papers, No

    Please cite this paper as: OECD (2006-04-12), “The Secondary Market for Domain Names”, OECD Digital Economy Papers, No. 111, OECD Publishing, Paris. http://dx.doi.org/10.1787/231550251200 OECD Digital Economy Papers No. 111 The Secondary Market for Domain Names OECD Unclassified DSTI/ICCP/TISP(2005)9/FINAL Organisation de Coopération et de Développement Economiques Organisation for Economic Co-operation and Development 12-Apr-2006 ___________________________________________________________________________________________ _____________ English - Or. English DIRECTORATE FOR SCIENCE, TECHNOLOGY AND INDUSTRY COMMITTEE FOR INFORMATION, COMPUTER AND COMMUNICATIONS POLICY Unclassified DSTI/ICCP/TISP(2005)9/FINAL Working Party on Telecommunication and Information Services Policies THE SECONDARY MARKET FOR DOMAIN NAMES English - Or. English JT03207431 Document complet disponible sur OLIS dans son format d'origine Complete document available on OLIS in its original format DSTI/ICCP(2005)9/FINAL FOREWORD This report was presented to the Working Party on Telecommunications and Information Services Policies (TISP) in December 2005 and was declassified by the Committee for Information, Computer and Communications Policies (ICCP) in March 2006. This report was prepared by Ms. Karine Perset, with the participation of Mr. Dimitri Ypsilanti, both of the OECD's Directorate for Science, Technology and Industry. This report is published on the responsibility of the Secretary-General of the OECD. 2 DSTI/ICCP(2005)9/FINAL © OECD/OCDE 2006 3 DSTI/ICCP(2005)9/FINAL
  • The People Who Invented the Internet Source: Wikipedia's History of the Internet

    The People Who Invented the Internet Source: Wikipedia's History of the Internet

    The People Who Invented the Internet Source: Wikipedia's History of the Internet PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 22 Sep 2012 02:49:54 UTC Contents Articles History of the Internet 1 Barry Appelman 26 Paul Baran 28 Vint Cerf 33 Danny Cohen (engineer) 41 David D. Clark 44 Steve Crocker 45 Donald Davies 47 Douglas Engelbart 49 Charles M. Herzfeld 56 Internet Engineering Task Force 58 Bob Kahn 61 Peter T. Kirstein 65 Leonard Kleinrock 66 John Klensin 70 J. C. R. Licklider 71 Jon Postel 77 Louis Pouzin 80 Lawrence Roberts (scientist) 81 John Romkey 84 Ivan Sutherland 85 Robert Taylor (computer scientist) 89 Ray Tomlinson 92 Oleg Vishnepolsky 94 Phil Zimmermann 96 References Article Sources and Contributors 99 Image Sources, Licenses and Contributors 102 Article Licenses License 103 History of the Internet 1 History of the Internet The history of the Internet began with the development of electronic computers in the 1950s. This began with point-to-point communication between mainframe computers and terminals, expanded to point-to-point connections between computers and then early research into packet switching. Packet switched networks such as ARPANET, Mark I at NPL in the UK, CYCLADES, Merit Network, Tymnet, and Telenet, were developed in the late 1960s and early 1970s using a variety of protocols. The ARPANET in particular led to the development of protocols for internetworking, where multiple separate networks could be joined together into a network of networks. In 1982 the Internet Protocol Suite (TCP/IP) was standardized and the concept of a world-wide network of fully interconnected TCP/IP networks called the Internet was introduced.
  • Registry Operator's Report

    Registry Operator's Report

    REGISTRY OPERATOR’S REPORT July 2007 Afilias Limited Monthly Operator Report – July 2007 As required by the ICANN/Afilias Limited Registry Agreement (Section 3.1(c)(iv)) this report provides an overview of Afilias Limited activity through the end of the reporting month. The information is primarily presented in table and chart format with text explanations as deemed necessary. Information is provided in order as listed in Appendix 4 of the Registry Agreement. Report Index Section 1 Accredited Registrar Status Section 2 Service Level Agreement Performance Section 3 INFO Zone File Access Activity Section 4 Completed SRS/System Software Releases Section 5 WhoIs Service Activity Section 6 Total Number of Transactions by Subcategory by Month Section 7 Daily Transaction Range Copyright © 2001-2007 Afilias Limited Page 2 of 9 Afilias Limited Monthly Operator Report – July 2007 Section 1 – Accredited Registrar Status – July 2007 The following table displays the current number and status of the ICANN accredited registrars. The registrars are grouped into three categories: 1.Operational registrars: Those who have authorized access into the Shared Registration System (SRS) for processing domain name registrations. 2.Registrars in the Ramp-up Period: Those who have received a password to the Afilias Operational Test and Evaluation (OT&E) environment. The OT&E environment is provided to allow registrars to develop and test their systems with the SRS. 3.Registrars in the Pre-Ramp-up Period: Those who have been sent a welcome letter from Afilias, but have not yet executed the Registry Confidentiality Agreement and/or have not yet submitted a completed Registrar Information Sheet.
  • Deploying DNSSEC: from Content to End-Customer

    Deploying DNSSEC: from Content to End-Customer

    Deploying DNSSEC: From Content to End-customer InterOp Mumbai 2012 11 October 2012 [email protected] Terminology Registrant (Content)ßàRegistrarß àRegistryßàRootß àISPßàEnd User (Eyes) Example: tata.in (TATA)ßànet4.in (Net4)ß ànixi.in (NIXI)ßàicann.org (ICANN)ß àAirtel, Sify, etc..ßàISP Customer Creang a Chain of Trust • Registrant generates, signs their records with and publishes key to Registrar. • Registrar manages key at the Registry on behalf of the Registrant. • Registry generates, signs Registrant key with and publishes its own key in root. • The root generates, signs Registry key with and publishes its own key to public. • ISP/End User validates Registrant DNS record with Registrant key then Registrant key with Registry key and finally Registry key with root key. • This creates the chain of trust from content provider (Registrant) to end user. RegistrantàRegistraràRegistryàRootàISPàEnd User DNSSEC: We have passed the point of no return • Fast pace of deployment at the TLD level • Deployed at root • Supported by soUware • Growing support by ISPs • Required by new gTLDs à Inevitable widespread deployment across core Internet infrastructure DNSSEC: Plenty of Mo;va;on • DNSChanger aack, calls for deployment by governments, etc… • Technology and standards built on DNSSEC* – Improved Web TLS and certs for all – Secured e-mail (S/MIME) for all – SSH, IPSEC, … • …and new applicaons – VoIP – Digital iden^ty – Secured content delivery (e.g. configuraons, updates) – Smart Grid – A global PKI – Increasing trust in e-commerce A good ref hp://www.internetsociety.org/deploy360/dnssec/ *IETF standards complete or currently being developed DNSSEC interest from governments • Sweden, Brazil, Netherlands and others encourage DNSSEC deployment to varying degrees • Mar 2012 - AT&T, CenturyLink (Qwest), Comcast, Cox, Sprint, TimeWarner Cable, and Verizon have pledged to comply and abide by US FCC [1] recommendaons that include DNSSEC.
  • A Long Time Ago, in a Meeting Room Far, Far Away...Or Maybe 17 Years

    A Long Time Ago, in a Meeting Room Far, Far Away...Or Maybe 17 Years

    A long time ago, in a meeting room far, far away.... ... or maybe 17 years ago, in Houston, Texas... ...work in the IETF began on... DNSSEC For their efforts with DNSSEC, the IETF wishes to thank: Joe Abley - Danny Aerts Alain Aina - Mehmet Akcin Jaap Akerhuis - Mark Andrews Roy Arends - Derek Atkins Rob Austein - Roy Badami Alan Barrett - Doug Barton Rickard Bellgrim - Ray Bellis Steve Bellovin - Dan Bernstein David Blacka - Stéphane Bortzmeyer Eric Brunner-Williams - Len Budney Randy Bush - Bruce Campbell Vint Cerf - K.C. Claffy Alan Clegg - David Conrad Michelle S. Cotton - Olivier Courtay John Crain - Dave Crocker Steve Crocker - Alex Dalitz Joao (Luis Silva) Damas Hugh Daniel - Kim Davies John Dickinson - Vasily Dolmatov Lutz Donnerhacke - Mats Dufberg Francis Dupont - Donald Eastlake Anne-Marie Eklund-Löwinder Howard Eland - Robert Elz Patrik Fältström - Mark Feldman Ondrej Filip - Martin Fredriksson Alex Gall - James M. Galvin Joe Gersch - Demi Getchko Miek Gieben - John Gilmore Steve Goodbarn - James Gould Michael Graff - Chris Griffiths Olafur Gudmundsson - Gilles Guette Andreas Gustafsson Jun-ichiro Itojun Hagino Staffan Hagnell Phillip Hallam-Baker Ilja Hallberg - Bob Halley Cathy Handley - Wes Hardaker Ted Hardie - Ashley Heineman Jeremy Hitchcock - Bernie Hoeneisen Alfred Hoenes - Paul Hoffman Scott Hollenbeck - Russ Housley Geoff Houston - Walter Howard Bert Hubert - Greg Hudson Christian Huitema - Shumon Huque Johan Ihren - Stephen Jacob Jelte Jansen - Rodney Joffe Simon Josefsson - Daniel Kalchev Andris Kalnozols - Dan
  • Case Study Transfer of Domain Name Registered

    Case Study Transfer of Domain Name Registered

    YOUR PARTNER FOR GLOBAL GROWTH CASE STUDY TRANSFER OF DOMAIN NAME REGISTERED WITH A DORMANT REGISTRAR BACKGROUND OF THE CASE Our client had registered their website domain name with Domain Name Registrar - Net4 Network Services Limited (Net4), with latest renewal for 3 years done in 2018. Our client wanted to transfer their domain from Net4 to another registrar to facilitate email migration. Upon logging onto their Net4 account, our client realised that no option was provided by Net4 for initiating transfer and few other important details necessary for email migration were also missing. This unusual omission prompted them to seek Octagona India’s assistance for completing domain transfer. HOW DID OCTAGONA INDIA HELP? Our team undertook the following actions: The very first step was to establish contact with Net4. We called their help line and office numbers but most calls did not go through and the ones which did, went unanswered. We also raised complaints and sent several emails. On not receiving any response on phone or email our team then decided to conduct physical due diligence. We visited Delhi, Noida and Pune Office of Net4 to establish contact. At Delhi and Noida, we were informed by the security guard that Net4 offices were taken over and sealed by a bank in India on account of Net4’s failure to pay their loan. The Pune office was not in existence. Understanding the complexity of the problem, we undertook preliminary inspection of Net4’s records present on the website of the Ministry of Corporate Affairs and noted that current status of the Company was ‘Under process of Striking-off’.