CentralNic Ltd






D2       Full legal name:          CentralNic Limited


Principal address:      163 New Kings Road


                                                SW6 4SN

                                                United Kingdom


                                                Tel:       +44 (0)20 7751 9000

                                                Fax:      +44 (0)20 7751 0958




D3.      Other business locations: there are no other business locations of the registry operator.



D4.      Business entity: Centralnic Limited (referred to in this document as CentralNic) is a private limited company incorporated in England on 17th May 1999 under the Companies Act 1985. The company’s registered number is 3771833.



D5.      URL of registry operator's principal world wide web site:



D6.      Dun & Bradstreet D-U-N-S Number: None



D7.      Number of employees: 19



D8.      Registry operator's total revenue in the last-ended fiscal year: $1,176,567[1]



D9.      Registry operator's directors, other officers, relevant managers and owners of five per cent or more of registry operator.


(i) Directors:


Stephen Gerard Crispin Dyer (Chairman)

Cathy Bosworth Horton (Director)


                        Advisory Board members:


Dr Rob Blokzijl (Chairman of RIPE, member of ICANN Board[2])

Dr Willie Black (Head of Nominet UK)


(ii) Other officers:


Simon Joel Rowbottom (Chief Technical Officer)

Laszlo Hasenau (Director Elect, East Europe Operations)

Anil Patel (Company Secretary)

Diana Loveday Dyer (Assistant Secretary)


(iii) All relevant managers:


            Camilla Jane Coxe (Operations Manager)

            Susan Lusia Malec (Sales and Marketing Manager)

            Peter Noel David Corlett (Technical Operations Manager)

            James Adam Samuel (Global Network Operation Manager)


(iv) Persons or entities owning five percent or more of registry operator:


            Stephen Gerard Crispin Dyer

            Diana Loveday Dyer

            Theresia Hasenau

            Cathy Bosworth Horton

            Christian Philips

            Robert Pooke


D10.    Name, telephone and fax number, and e-mail address of person to contact for additional information regarding this proposal:


            Enquiries on technical information should be directed to:


            Joel Rowbottom (Chief Technical Officer)

Tel:       +44 (0)20 7751 9000

                        Fax:      +44 (0)20 7751 0958



            All other enquiries regarding this proposal should be directed to:


Stephen Dyer (Chairman)

                        Tel:       +44 (0)20 7751 9000

                        Fax:      +44 (0)20 7751 0958




D11.    The full legal name, principal address, telephone and fax numbers, e-mail address, and Dun & Bradstreet D-U-N-S Number (if any) of all subcontractors: There are no subcontractors.






D13.1. Detailed description of the registry operator's capabilities.


CentralNic describes in detail its capabilities as a registry operator in the following sections of this application:


·        Technical   D13.1.4, D15


·        Marketing – D13.2.4


·        Operational and Management – D13.1.2, D13.1.6, D13.1.7


·        Legal – CentralNic considers that its ability to draw upon the specialist legal expertise of one of its founders and directors, Cathy Horton, and the firm of Squire, Sanders & Dempsey, of which she is an equity partner, is of very considerable value. Further information on Cathy Horton is under D13.1.6. In addition, the creation of CentralNic-led legal forums is an integral part of CentralNic’s marketing strategy (D13.2.4).



D13.1.1. Company information: CentralNic


CentralNic is a private limited company based in London, United Kingdom. The company is 70% owned by the founders and drivers and 30% held by passive investors. CentralNic was legally formed on 17th May 1999.


CentralNic’s operations, together with its predecessor company, NomiNation, date back to 1995. CentralNic has a full-time staff of nineteen based at CentralNic’s headquarters in Fulham, London.


A copy of a letter of reference from Mr Clive Hammond, CentralNic’s bank manager at HSBC is under 13.4.2 at the end of this document.


CentralNic is a company limited by shares. It has an authorised share capital of 1,000,000 ordinary £1 shares of which 11,758 are issued. There are no other classes of shares.


The company has no formal alliances.



D13.1.2. Current business operations.


CentralNic corporate profile

Originally founded in 1995 as NomiNation, CentralNic was established in April 2000 as an independent global domain name registry committed to making it easier for Internet users to establish new and distinctive domain names with regional and country-specific identities.


Headquartered in London, CentralNic currently has a portfolio of more than 17 domain names available to users world-wide, including (Europe), (United Kingdom),, (United States), (China) and (Russia). Additional domain names will be added this year.


CentralNic uses the .com and .net standard domain name structure to offer additional regional and country-specific domain names, ensuring a secure, inexpensive solution for creating easily identifiable Internet addresses world-wide.


CentralNic's registry service is particularly useful for Internet users in countries where domain names are difficult to obtain due to restrictive domain regulations. However, the CentralNic portfolio also has wide appeal to individuals and companies seeking to define an Internet identity in a region or country where they intend to establish or expand their business, or for any other reason establish a geographically distinct identity.


Users often turn to CentralNic when a conventional Top Level Domain (TLD) such as .com, or a country TLD such as .uk address has already been claimed by another party. CentralNic customers include such well-known companies as Creative Labs, Gucci and Sharp.


Registration of a new domain name of choice costs approximately $99 for a two-year period, after which it can be renewed. CentralNic has a world-wide network of more than 350 resellers that provides customers with efficient local access for registration. The company also provides extensive customer support, including legal expertise on such issues such as country specific regulations and individual vs. corporate ownership of domain names.


The company is currently experiencing growth rates of more than 50 per cent a month and has currently more than 50,000 registered domain names (as of June 2000).


To serve its customers without interruption, CentralNic operates an international network of Domain Name Servers running on the latest versions of Solaris and Linux to ensure maximum reliability and performance. The servers are co-ordinated and controlled from the company's network operations centre in London, United Kingdom.


The company plans to install four additional operation centres in various locations around the world to form a global network. This network will be enhanced to support the new TLD.



D13.1.3. Past business operations/entity history.


In the early days of the UK Internet, NomiNation, the first private Internet Registry Company, was launched to handle the domain name


The idea came about as a direct result of conversations between the late Jon Postel ("Father of the Internet") and Stephen Dyer (Chairman of NomiNation) in 1995. Jon suggested the use of to compete with at a time when the proposed price of the name was £200 (about $300 US).


Subsequently, with the launch of the domain name, was offered at £80 and Nominet, the registry, did not hold a monopoly position. The two domain names continue to function in harmony, and the addition of, and provides the UK Internet community with the widest choice of local domain names.


Around the world, the Internet is experiencing phenomenal growth and this results in a scarcity of suitable domain names. The provision of a global domain name registry is a valuable service to organisations and individuals who want to have a presence in different countries but experience difficulty in registering a domain name because of local qualifying rules.


CentralNic offers an efficient and speedy registration service in a number of countries around the world and further countries will be added to the portfolio. Its world-wide network of resellers provides efficient local access for registration and assistance for registrants.



D13.1.4. Registry/database/Internet related experience and activities.


Stephen Dyer and Joel Rowbottom are both directors of Mailbox Internet as well as CentralNic.


Mailbox Internet is a fully functional Internet Service Provider. It has a reputation for being a technically advanced ISP which has developed NEWTOS, a database system enabling complete Web-based automation of ISP operations.


Although a separate company, Mailbox Internet is one of the connectivity providers for CentralNic and its co-location with CentralNic provides a useful buffer of technology and expertise to help cope with the highly unpredictable volumes encountered in the domain name environment.


CentralNic is in negotiation to acquire an existing registry of the .com, .net and .org names.



D13.1.5. Mission.


CentralNic’s mission is to become a globally recognised supplier of domain names and a major registrar of the existing standard global domain names. CentralNic aims to be recognised as a international brand for quality, security and confidence and a recognised centre of excellence.


CentralNic is able to call upon the considerable expertise of its director Cathy Horton at Squire, Sanders and Dempsey, to assist with any legal, regulatory or governance matter that may arise out of the operation of the registry.


CentralNic intends to become a major player in the fields of Domain Name Law and Internet Governance.



D13.1.6. Management.


Stephen Dyer

Co-Founder, Chairman and Managing Director, CentralNic


Stephen Dyer, co-founder, chairman and managing director, is an entrepreneur, Internet pioneer and systems designer whose 30-year career has spanned a broad range of industries from banking to airlines to scientific research.


Dyer co-founded CentralNic in April 2000 with the vision of building an independent global domain registry and marketing company that will make it easier and less expensive for Internet users to establish new and distinctive domain names with regional and country-specific identities. CentralNic is a successor organisation to NomiNation, which Dyer founded five years earlier, in 1995.


In addition to CentralNic, Dyer is currently chairman of two other successful companies. In the early 1980s, he and his wife Diney, founded Mailbox Partnership, a fulfillment house providing creative, back office and other services to public relations companies, and in 1993 he formed Mailbox Internet Ltd., one of the first and most profitable business-to-business Internet Service Providers in the UK.


Prior to these positions, Dyer served as Manager of Organisation and Methods for Rediffusion Group, a 108-company multinational conglomerate comprised of electronic media, financial services, computer manufacturing, flight simulation and other groups. As manager of O&M, Dyer ran Rediffusion's internal consulting organisation, with responsibilities that included integrating customer support and other customer needs with the company's computer systems across all groups.


As a consultant, Dyer's experience in systems design and implementation covers many industries. For example, he performed systems analysis and programming for the first global online ticket reservation and cargo scheduling system for BOAC, the predecessor to British Airways, and later provided systems advice for the merger of BOAC and BEA when British Airways was formed in the early 1970s.


Dyer also designed and implemented systems for on-line analysis of human brainwaves for the Burden Neurological Institute in Bristol, UK. Other engagements included design and implementation of computerised banking and accounting systems for the Bank of Greece, and systems design for car control and rental billing systems for Hertz Rent-a-Car.


As a pioneer in the Internet industry, Dyer is a well-known figure and participant at meetings of ICANN, RIPE and other industry groups. Dyer also volunteers on working groups for the Council of European Top Level Domain Name Registries, the Policy Advisory Board of Nominet UK and the Private Registries Working Group, which he founded.


Dyer began his career as a consultant at Arthur Andersen, after studying computer science, psychology and chemistry at Keele University. Dyer is married and has two sons, the oldest of whom runs his own media design company, Spook New Media.



Joel Rowbottom

Chief Technical Officer, CentralNic


Joel Rowbottom, 26, Chief Technical Officer, is a computer expert and a published Linux author who can write code in 15 dialects of 10 programming languages. He specialises in database design and implementation on PC and Unix development platforms.


As CTO for CentralNic, Rowbottom is responsible for implementing and ensuring the flawless reliability of the company's Internet Domain Name Registry, which is capable of accepting more than 3,000 new registrations a minute.


In addition to his role as CTO for CentralNic, Rowbottom is Managing Director and former Technical Director for Mailbox Internet Ltd., one of the first and most profitable business-to-business Internet Service Providers in the United Kingdom.


Rowbottom, began programming computers at age 8 and at age 9 wrote his first computer game entitled "Invasion" which he sold to game publisher Gold. At age 12, he sold software applications and utilities that he wrote to fellow grammar school students, and by 17 was programming for Coca-Cola and Schweppes Beverages, Ltd..


He holds a BSc degree in Special Computer Science with Information Engineering from the University of Hull, and has numerous professional qualifications including Cisco CCIE, and Microsoft CSE. He is a registered Sun Solaris and Java developer and a registered Oracle8i developer.


Rowbottom is co-author of Professional Linux Deployment (Wrox Press, 1999), and is currently working on a second Linux book. He has also published articles for several Linux publications including LinuxUser and LinuxFormat.


In addition, he is a member of a working group with CENTR (Council of European Top-Level Domain Registries) and RIPE (Reseaux IP Europeens) that aims to create an industry-wide XML template for registering domain names. He also works with several other groups on IPv6, the next-generation Internet Protocol.


Through his published work and participation in various Internet forums, Rowbottom is well-known throughout the UK's Internet community, and he has been written about in several national British newspapers.


Prior to CentralNic, Rowbottom was a software engineer for Gemstar Europe where he provided software support and programming for publishing clients throughout Europe, frequently using C for Unix and DOS-based machines, and ThinkC and CodeWarrior for Apple machines. He also had sole responsibility for analysis, design and installation of in-house client-server databases using Visual Basic, Microsoft Access and MySQL. He worked on the European implementation of the digital TV system, StarSight EPG, and was one of only eight qualified OpenTV programmers in the UK.


Before Gemstar, Rowbottom was a Webmaster and programmer for Rabbit Solutions, where he designed Web sites for companies throughout the UK, and developed application software for small businesses using C, Visual Basic, and Pascal. He was also responsible for marketing and operations.


In addition to his love of computers, Rowbottom is a jazz and pop pianist, and performs with seven other musicians in a band called "Obvious Pseudonym."

He is married, and lives in London.



Cathy Horton

Legal Director, CentralNic


Cathy B. Horton, Legal Counsel and one of CentralNic’s Founding Directors, is an international M&A attorney and business consultant with extensive experience in developing Internet business models and value propositions, and in cross-border and cross-cultural business transactions.


Along with CEO Stephen Dyer and other directors, Horton co-founded CentralNic in May 2000 with the goal of making it easier and less expensive for Internet users to establish new and distinctive domain names with regional and country-specific identities.


As legal counsel for CentralNic, Horton played a key role in creating a legal and financial structure that will enable the company to grow internationally. Among other tasks, she is currently working to improve codes of conduct for naming and addressing systems used on the Internet, and participating in forums conducted by such international Internet organizations as CENTR and RIPE (Réseaux IP Européens).


Horton, who is American, has practised law in Europe for the past 11 years. In addition to her role at CentralNic, Horton is an equity partner in the London office of Squire, Sanders & Dempsey, an international law firm. As senior partner for information technology, she represents global technology companies and start-ups in mergers and acquisitions, complex systems and web infrastructure projects, technology licensing and protection, venture capital and other financing, value structuring and eBusiness modelling for corporate rebirth and web ventures.


Her clients include Hewlett-Packard, for whom she is lead counsel to the consulting group for all eBusiness-related work in the UK.  Horton also represents Aris and Neon, two publicly traded US technology companies.  She also led the team that recently represented a leading developer of banking, treasury and risk management in a reverse triangle merger on the French stock exchange.  Prior to Squire, Sanders & Dempsey, she was a lawyer with English firm Clyde & Co., where she was UK counsel for several global technology companies.  During her time at Clyde, Horton developed her expertise helping companies involved in international financial transactions to bridge cultural, business, legal and other differences.  It was here that she also began to develop her expertise in Internet business modelling and valuation.  Her clients ranged from Web design companies, to complex systems integrators, to Internet retailers, to backend systems players.


Prior to Clyde & Co., she was an equity partner at Bryan Cave where, as a young provider of legal services, she trained in the art of cross border deals. It was here that she came to understand client desire for proactive advice given with commercial savvy, and honed the art of service, service, and service.


Horton sits on the board of numerous Internet companies, and has produced a number of articles on eBusiness. She regularly trains senior and project management teams from HP in systems and eBusiness contracting.


Horton has a Juris Doctorate degree from Ohio State University, a Bachelors degree in History from the University of Michigan, and recently graduated from the University of Kent, Canterbury in Theology.



Susan Malec

Marketing and PR Manager, CentralNic


Susan Malec, joined NomiNation Limited, the predecessor to global domain name registry, CentralNic in March 1999 as Sales and Marketing and New Business Development Manager.


The company has expanded ten fold since her joining.  Previously Susan worked for international public relations counsel, Hill and Knowlton as Account Group Director.


With a career spanning over 15 years in public relations, she has worked closely with numerous major organisations such as NCR, Pepsi, Gallaher, William Grant & Sons, Tunstall Telecom etc.  She has considerable experience of the Middle East working on behalf of the American government, the Australian Tourist Board and the Queensland Government Office.   While in the Middle East, she worked on behalf of Batelco, the Bahrain Telephone Exchange and Cable and Wireless.




Laszlo P Hasenau

Director Elect, East Europe Operations


Laszlo Hasenau is the general manager of CNE Corporate Network in Essen, Germany and has also worked on the IS -Steering Committee in the City of Essen and with the strategic use of telecommunications technologies. He has accomplished a city-wide synergy in telecommunications, collective use and design of Gigabit Ethernet backbone based on the latest fibre-optic technologies.


He managed the deployment of a Unified Messaging System, a combined operating centre for TK, Telefon and LAN/WAN operation of the utility in Essen and City of Essen, scalable for use of other companies in the city.



Camilla Coxe

Sales and Operations Manager, CentralNic


After graduating in 1997 Camilla Coxe joined Rapidsite as Sales and Marketing Manager. Within 18 months Rapidsite had increased their client base from 500 clients to 25,000.  At this point Verio a US leader in the field of Internet services and Webhosting acquired Rapidsite and funded a Marketing budget of £1.2 million per year.


Camilla joined CentralNic at its launch in April 2000.  With the arrival of Camilla  has assisted in achieving a  sales growth of over 300% during these first four months.  Camilla Coxe over the years has gained a wide understanding of Commerce and Management, this awareness has continually developed during pre university posts as resort managers within the tourism industry in Europe and latterly through Rapidsite and Verio UK.



D13.1.7. Staff/employees.


The motivation and commitment of all employees continues to play a major part in the success of CentralNic.


CentralNic’s policy is to promote equal opportunity in employment regardless of gender, race, colour or disability, subject only to capability and suitability for the task and legal requirements. Employee ownership in the CentralNic will be encouraged and CentralNic is actively exploring a share option programme for employees.


CentralNic places great emphasis on the training and development of its employees and is always receptive to the individuals’ aims and career development through internal and external training and qualification.


A substantial amount of skills training is also carried out in all areas. CentralNic has a comprehensive internal communications programme to ensure employees are well informed about the business and the industry in general.


As an indication of CentralNic's current expansion and recruitment programme the following staff vacancies are open:


·        Pan European Marketing Manager

·        UK Sales and Marketing Director

·        US Business Development Manager

·        Customer Service Representatives (second language preferred)

·        Domain Name Administrator

·        Receptionist

·        PR Assistant

·        Webmaster

·        Technical Developer/Programmer.


CentralNic is also actively seeking a Human Resources Manager, emphasising the company’s commitment to its staff and to good employment practice. A standard CentralNic employment contract is included in the annex at the end of this document.


CentralNic is in negotiation to acquire substantially larger premises to accommodate new staff to meet the present growth rate of the company. These premises are undergoing refurbishment and CentralNic will relocate in Autumn 2000.


These premises will be sufficient to handle the anticipated growth in CentralNic to 56 staff by January 2001.



D13.1.8. Commercial general liability insurance.


Amount of insurance policy: $14,000,000


Provider of insurance policy: Zurich Insurance Company


Plans for obtaining additional insurance: CentralNic is a named company in a group policy with related companies. CentralNic is arranging to have an entirely separate policy solely covering CentralNic. At that stage CentralNic will review its insurance needs and is confident that they can be adequately matched to an appropriate insurance policy.



D13.2. Business plan for the proposed registry operations.


D13.2.1. Services to be provided.


CentralNic will be providing registry services to the TLD applicant which are functionally close to those it is already familiar with providing in its existing registry business.


These registry services are:


1)      Direct registration.



2)      Reseller registration.


CentralNic provides resellers and registrars with traditional registration and whois interfaces which can be integrated with registrars’ local systems.


D13.2.2. Revenue model.


It is anticipated that there will be two distinct stages for the revenue model, which apply to different levels of maturity for the TLD applicant’s proposal.


1)      Start-up phase. In this phase the revenues that CentralNic will receive reflect both the immaturity of the new operation and the heavy, pre-operational investment which CentralNic will make in capital equipment. The revenues which CentralNic receives at this stage will be in the order of $7 per annum for a two year registration and $4 per annum for each subsequent re-registration.


2)      Intermediate/mature phase. At this stage there will be detailed evidence of the demand and the likely demand for registrations, allowing more accurate projection of future revenues to be made. At this stage it is anticipated that CentralNic will agree a ‘cost plus’ revenue formula, which will fall considerably below the assumption of revenue in stage 1 as demand is seen to be increasing substantially.


The revenues are incorporated into the pro-forma financial projections at D13.3, below.


D13.2.3. Market.



CentralNic’s existing business addresses the following key groups directly:


·        Internet Service Providers.

·        Web Hosting specialists.

·        Web design agencies.

·        Domain Name Brokers.

·        Small to medium sized business consultants.

·        Brand protectors.

·        The press.


And indirectly:


·        All Internet users.



In the event of the award of the TLD to Telnic Limited (“Telnic”) , CentralNic anticipates addressing the following groups:



Telco's resellers.

New VoIP operators.


The market can be potentially any IP enabled device and there will be no restriction on access.



D13.2.4. Marketing plan.


CentralNic’s marketing plan under this registry operator’s proposal will be finalised in conjunction with Telnic.


However, as an indication of CentralNic’s existing marketing strengths and abilities, the following gives a detailed picture of CentralNic’s marketing programme for the next twelve months.


CentralNic’s Marketing Objectives


·        Provide a premium customer support service

·        Expand the marketing team

·        Continue to further develop a world-wide reseller network

·        Appointment of Global PR Consultancy

·        Exhibit at relevant Internet exhibitions

·        Become a recognised authority on legal issues relating to domain names and Internet governance.



Activities to fulfil CentralNic’s marketing objectives


Expanding the Marketing Team

CentralNic’s current business plan includes a Marketing Director and a staff of six and funding for Marketing of $1.8 million.


One of CentralNic’s shareholders, US/Austrian-based Romanian Mariana Bozesan has significant marketing experience with Oracle and brings that strength to the company. Despite this expertise CetralNic is currently searching for a full-time Marketing Director.


Further immediate personnel requirements include:


·        UK Sales and Marketing Director

·        European Business Development Manager

·        US Business Development Manager

·        PR Executive/Exhibition Assistant

·        Customer Support staff x 2 for 24 hours cover


Continue the Development of the World-wide Reseller Network

CentralNic’s current activities address the continued growth of our reseller base, with a focus on recruiting and assisting a backbone of European and US resellers.


It becomes increasingly easy to penetrate a national market when there is a core of recognised resellers already in existence (currently 350+ resellers in the UK).  This activity is helped by PR back-up and the maintenance of a high profile campaign in international domain name circles to consolidate CentralNic’s profile.


The future consists of a much more aggressive marketing strategy.


One such area of activity includes the establishment of partnerships with industry heavyweights. CentralNic therefore seeks relationships with companies such as Yahoo and Verio, where there is positive two-way supportive activity and CentralNic can gain from the huge traffic generated from such sites. These companies are mostly US-centric, but we feel that we can bring a strength in the European arena that they may find a compelling argument for joining forces with us in their pushes into Europe.


Activities currently being carried out include the following:


·        Direct mail campaign, involving individually addressed key personnel.  The French market is currently being targeted.


·        Immediate response to requests for information plus follow-up telephone calls.


CentralNic is recruiting resellers internationally and we already have in place a discount structure and a joint marketing development plan for these resellers.  This effectively rebates five per cent of revenues back to the largest resellers for use in advertising or other activities.


CentralNic is aiming to support local resellers, not only through the Global Branding activities described above, but also through locally focused activities.   Here we will work with the resellers.   We cannot hope to fully understand the diversity of cultures and markets into which we are selling, neither do we wish our resellers to perceive us as remote and arrogant.  By working with our reseller channel and taking a sensitive approach to each market we intend to maximise the effectiveness of our marketing and PR spend in each marketplace.


Premier Customer Support Service

Domain name registries are renowned for poor customer service.


CentralNic is putting in place a 24 hour multi-lingual customer support system. A current CentralNic policy is that all customer queries are dealt with by the end of each business day.


Notwithstanding the fact that registrars will typically be the first point of contact for customers, CentralNic will itself be supporting every major language from its London base.


CentralNic already has the reputation of providing good quality customer care in the UK and plans to mirror this image to other parts of the world.


Appointment of Global PR Consultancy

To strengthen its marketing position and aid the transition to a fully global marketing company CentralNic has engaged Hill and Knowlton - one of the world’s biggest global public relations consultancies - to advise the company. Hill and Knowlton has a huge portfolio of blue chip clients and has a world-wide business, split approximately 40% in Europe and 40% in the US. Hill and Knowlton's advice is likely to impact the plans described in this section.


CentralNic is particularly keen on appointing this agency due to several factors:


·        The Hill and Knowlton Board Director responsible for IT clients has a particular key understanding of our market, having already purchased a number of CentralNic’s names prior to our approach.


·        The consultancy has a strong lobbying team, including representation in Brussels to the European Community - an emerging player in the domain name environment.


·        The consultancy also has an impressive US network, with offices in most cities including 2 in San Francisco.


·        For stage 2 of the marketing rollout, the consultancy has offices in China.


Hill and Knowlton will play an integral part of assisting CentralNic in achieving one of its objectives which is to position CentralNic as a global brand for quality, security and confidence.


CentralNic’s experience in the UK market has been that a critical factor in this business is trust.  We have to be a Trusted Third Party  (“TTP”) because companies that use our names are entrusting their IP to us and investing money in branding their company with our name.  It therefore follows that growth in the use of a particular name is much easier if that name is seen to be backed by a TTP and to this end we wish to position CentralNic as a global brand.


This is not an overnight activity, and our current marketing plan does not contain the sort of sums normally associated with the roll-out of a global brand.   We envisage the gentle growth of this position through our strong presence in the area of domain name law, our international profile, and the more nationally-based marketing activity.  All these activities will be supported by Hill and Knowlton.


Internet Exhibitions

CentralNic recently exhibited at the Internet World Show in London. This forum has been very valuable for meeting and signing up overseas resellers and for making further potentially valuable contacts.


CentralNic plans to exhibit at Internet World Shows in the following countries: Paris – November 2000, New York, Russia, possibly Berlin in November, UK 2001.


Organisation of Legal Forums

One of CentralNic’s great strengths is to have as a board director and shareholder a prominent corporate lawyer.  Cathy Horton, Senior Partner and Head of Global IT of Squire, Sanders and Dempsey.


Cathy and her team are pioneering CentralNic’s legal centre of excellence for the domain name industry, bringing a knowledge base and order to an area which needs stability and leadership. This activity will provide also project the company into the global arena.

D13.2.5. Estimated demand for registry services in the new TLD.


The estimated demand for new registrations is:


Year 1:            1,090,000

Year 2:            1,625,000

Year 3:            3,500,000

Year 4:            6,120,000

Year 5:            9,780,000



D13.2.6. Resources required to meet demand.


The resources required to meet the estimated demand levels shown under 13.2.5 have been considered in detail in the following sections of this proposal:


Financial – 13.2.13


Technical and physical plant – D15


Staff – 13.1.7


Customer service – 13.2.4


Legal – 13.1.6


It should be noted that the estimated demand levels noted under 13.2.5 are mid-case estimates and CentralNic is very confident that it will be able, with a wide ‘comfort’ margin, to satisfactorily service demand.


Variance significantly above these demand levels would clearly lead to CentralNic being required to deploy financial and staffing resources quickly to meet these demands.


However, CentralNic’s experience of huge growth over the most recent period of its operational history means that it already has the systems in place to meet demand levels even if they are significantly in excess of those shown at 13.2.5.


CentralNic is capable of reacting successfully to the 'quantum leap' growth situations often encountered in the domain name market.



D13.2.7. Plans for acquiring necessary systems and facilities.


The current systems that are in place allow for easy expansion, with the simple of addition of more units configured to perform the same job as the existing ones. However, new equipment will be coming from Network Engines Inc. and Sun Microsystems - the prices for which are detailed below.


UK Part Code











Sun Enterprise 4502 Server with 2 power/cooling modules, 2 S-BUS I/O boards Solaris Licence





2 x CPU/Memory Boards, 4Gb RAM, 4 x 400Mhz processors, 1 power/cooling module





Empty CPU/Memory Board





400Mhz CPU/8Mb Cache





Disk Board w 2 x 18Gb disks





PCI I/O Board with FW SCSI, 1 x 10/100 Ethernet, 2 x PCI slots





S-BUS Quad Ethernet Card





Power Supply & cooling module





PCI Differential SCSI Card





PCI Graphics Card





Power cord





Country Kit





420R Server with 2 x 450Mhz processors, 2 x 18Gb SCSI HDD, CD-ROM, 2 x PSU, Solaris licence





PCI Single Ethernet Card





PCI Graphics Card





PCI Differential SCSI Card















Sun Storedge A1000 RAID solution. 145Gb w 4 x 36Gb disks















Sun Storedge Tape Library, 1 x DLT7000 8 x slots















72-inch StorEdge Expansion Rack w/ 2 power sequencers and cables. The rack is 24" wide and 72" tall. This rack will include power sequencers and power cables.





Door Assembly















Veritas BusinessSuite Backup Software





Veritas File System  Media Pack





Veritas File System Tier 1





Direct Assist Support





Veritas File System Tier 2





Direct Assist Support





Veritas Volume Manager Tier 2





Direct Assist Support















"Gold" Maintenance for E4500 1 year





"Gold" Maintenance for System Board for 1 year





"Gold" Maintenance for 420R 3 years














1 Days installation/consultancy















Total Sell










Oracle Licences:










4 Processor E4500




Oracle Enterprise Server




Silver Support for above








2 Processor 420R




Oracle Enterprise Server




Silver Support for above








6 Processor E4500




Oracle Enterprise Server




Silver Support for above








Oracle Media

















Network Engines Hardware:




D13.2.8. Staff size/expansion capability.


CentralNic's ability to recruit and expand staff numbers in all areas of it's operation as well as employment policies, training and space to accommodate new members of staff has been described in detail under section 13.1.7.



D13.2.9. Availability of additional management personnel.


To date the company has an excellent record of recruiting the ablest technical and management people by word-of-mouth as well as the active seeking of key staff through other channels.


CentralNic is proud of its record in recruitment and staff retention and feels that this augurs well for the company’s future ability to recruit first-rank personnel.



D13.2.10. Term of registry agreement.


CentralNic believes that an initial assumption of at least a four year term for the registry agreement would be prudent. CentralNic believes that a term of less than two years would result in costings not appropriate to this proposal.


It is in the nature of the market in which CentralNic intends to operate that, subject to the professional running of the registry, CentralNic expects that the registry agreement would be automatically renewed for terms well in excess of the initial agreement period.



D13.2.11. Expected costs associated with the operation of the proposed registry.


These costs are shown in the pro-forma financial projections at 13.3. Revenue assumed to be paid to ICANN is shown in these projections.



D13.2.12. Expected revenue associated with the operation of the proposed registry.


These revenues are shown in the pro-forma financial projections at 13.3 and arise from the demand levels shown in the table at 13.2.5.



D13.2.13. Capital requirements.


Quantification of capital requirements in amount and timing

Based on the demand figures provided to it by Telnic, CentralNic estimates that the following capital requirements will need to be met:


Year 1:            $2,200,000

Year 2:            $1,500,000

Year 3:            $2,300,000

Year 4:            $3,200,000

Year 5:            $4,800,000


Obtaining capital

CentralNic is presently closely engaged in seeking new investors to fund the next stage of the company’s expansion.


CentralNic has already had offers (subject to commercial due diligence) from potential investors indicating that substantial funds are available to purchase a significant minority interest in CentralNic. These funds, combined with current revenues are more than sufficient to fund the expansion envisaged above.


CentralNic’s financial advisers Cavendish Corporate Finance are optimistic that a valuation of not less than $35 million can be obtained. This figure is substantially lower that might have been expected if the current general investor wariness of TMT stocks was not present. A letter from Cavendish Corporate Finance is at 13.4.4.


The investment partner with which CentralNic will probably choose to ally itself has an understanding and knowledge of CentralNic’s present field of operation as well as an understanding of the opportunities which are available to it as a registry operator for the present TLD applicant.


The potential funding sources with which CentralNic is in negotiation have a highly positive view of the further capital requirements necessary to meet the registry operator demands under this application and the opportunity this would present to CentralNic.


Sources, costs of capital

As described above, CentralNic is presently engaged in discussions for equity funding requiring the issue of new shares in CentralNic for an ownership interest in the company.


It is possible that the investment will be in the form of some debt or convertible finance. However, the strong likelihood is that CentralNic will remain debt-free during the next stage of its growth.


It should be noted that CentralNic has very substantial free cash flow and that this is highly advantageous to CentralNic in whatever route it takes to new capital.



D13.2.14. Business risks and opportunities.



The principal risks associated with the registry operator’s proposal stem from the ability of Telnic to predict accurately or not the demand for registrations.


There are business risks for CentralNic in either of the following circumstances:


1) Demand for registrations far in excess of that assumed in this application. This would lead to CentralNic being required to scale up its technical plan, perhaps in a very short period, leading to considerable pressure on staff and equipment.


2) Demand for registrations well below that assumed in this application. In the event of low demand, CentralNic would have scaled up its capital expenditure significantly in the pre-operational phase leaving capital resources under-utilised and staffing levels in excess of those required.



The success of Telnic would provide CentralNic with a potentially large increase in the volume of registrations.


Part of CentralNic’s success in its relatively short period of operation has been its ability to increase its management and technical systems to respond to a rapidly expanding market. CentralNic views the challenge of increased business volume in all areas of its operations with confidence based on its proven technical and operational ability for:


·        Scalability.

·        Total reliability.

·        Security.

·        World-wide, redundant servers.

·        Fast access/high bandwidth.



D13.2.15. Registry failure provisions.


CentralNic is presently addressing the legal requirements of new minority shareholders seeking to make a substantial investment in the company. Part of this due diligence process is identifying and valuing the assets of the company.


Unusually for a company in CentralNic’s area of operation it has bankable ‘real estate’ assets in the form of domain names. These assets are divisible from CentralNic and ones which it is possible to value independently of CentralNic’s overall worth.


In the very unlikely event of any reversal leading to the financial failure of the registry operator, CentralNic is confident that registrants would be served without interruption by any new entity taking on the management of the registry operator. This is because the domain names and their users form a substantial and valuable asset in their own right and one which a third party company would be keen to acquire and maintain.

Revenue Model New TLD (.tel)







































Annual registration cost













**Revenue per registration













Renewal rate


























New registered


























Total Quarterly Sales













Total Annual Sales


























Current registered


























Registrations: Quarterly Revenue













Registrations: Annual Revenue








































































































Annual registration cost













**Revenue per registration













Renewal rate


























New registered


























Total Quarterly Sales













Total Annual Sales


























Current registered


























Registrations: Quarterly Revenue













Registrations: Annual Revenue

































































**NOTE:  2 years registration fee is paid in advance.












D13.4. Supporting documentation:


D13.4.1. Registry operator's organizational documents.


A copy of CentralNic's Certificate of Incorporation is shown on the following page.

D13.4.2. References.


A copy of a letter from Mr Clive Hammond, CentralNic's bank manager at HSBC is on the following page.

D13.4.3. Annual report.


CentralNic's Draft Accounts to 15 September 2000 are on the following page.

D13.4.4. Proof of capital.


CentralNic has recently received two offers of further second round financing.  For further details please contact Mr Raymond Fagan, Director of Technology at Cavendish Corporate Finance Limited, who will be pleased to answer your queries.

Cavendish Corporate Finance Limited

40 Portland Place, London, W1N 3DG, England

Tel:       +44 (0) 20 7908 6000

Fax:      +44 (0) 20 7908 6006

D13.4.5. Proof of insurance.


On the following page is a copy of the insurance policy document from CentralNic's insurers, Zurich Insurance Company








D15.1. Registry operator's technical capabilities.


To serve its customers without interruption, CentralNic operates an  international network of Domain Name Servers running on the latest versions of Solaris and GNU/Linux to ensure maximum reliability and performance. The servers are co-ordinated and controlled from the company's network operations centre in London, United Kingdom.


CentralNic is a proven name in the Internet Domain Name industry, with the experience and expertise of operating a private registry since 1994.





CentralNic has a total of 5 highly-skilled technical staff, of which 3 have contributed code towards the GNU/Linux project and other open-source projects. The enthusiastic and entrepreneurial attitude of the technical staff leads to many of the innovative systems which are in use within the registry.


All technical staff work closely together and have the ability to program Perl and SQL, giving a high level of personnel redundancy throughout the team. As the CentralNic system has developed, so has staff expertise and recent expansions and reimplementation efforts have seen sections recoded in C and Java.


It is CentralNic's aim to continually nurture staff skills and foster good business relationships: to this end the technical staff frequently attend RIPE industry meetings, and participate in working groups with CENTR, IETF, ICANN and RIPE.


The Chairman of CentralNic, Stephen Dyer, has also been elected onto the board of Nominet, the UK ccTLD registry. This has enabled CentralNic's technical staff to consult with the Nominet technical staff and vice-versa, assisting both parties in building reliable and futureproof systems.


Staff within CentralNic enjoy a close relationship with their supplier of bandwidth in the UK, Mailbox Internet Ltd., and colocate personal servers for private development work. Such relationships assist in communication with other telecommunications and Internet providers.





Initial implementations of the CentralNic system in 1994 utilised the Informix database system via a tty interface. In 1997 the system was recoded to utilise a MySQL database engine on Sun SparcStation hardware, and in 1998 we introduced web-based console access. We constantly monitor load on all systems and plan to extend, reimplement or replace when load exceeds 50%.


The company is currently experiencing growth rates of more than 50% a month and has currently more than 50,000 registered domain names (as of June 2000). This boost is in no small means thanks to the online reseller console system which was introduced in May 2000 and is detailed in section D15.2.3.




D15.2. Technical plan for the proposed registry operations.


D15.2.1. General description of proposed facilities and systems.


The core CentralNic servers are held at Telehouse Europe (North Building), Coriander Avenue, London E10. The facility is manned 24 hours a day by trained, uniformed security staff to provide a deterrent to unauthorised access.  CCTV, with time-lapse video, both internally and externally provides information to a security control centre on possible intrusion.  Proximity cards control access within the facility. Telehouse has a sophisticated power distribution system for resilience. Multiple mains electricity feeds are supported by a UPS (uninterruptible power supply) system with generator backup.


The Telnic core encompasses the following network hardware as described on the following pages:










Sun E4502

Oracle 8i Database Host #1



Sun E4502

Oracle 8i Database Host #2



Sun E420R

Backup database host



NE Blazer

Primary mail relay for human email



NE Blazer

Web server for and




RAID5 fileserver with Veritas manager

DLT backup solution



NE Blazer

Monitoring and logging host







Sun E420R

Oracle Financials Host







NE Blazer

Zone file generation system #1



NE Blazer

Zone file generation system #2



Sun E420R

Registry/Registrar transaction server



Sun E420

Whois Lookup server







Cisco PIX 515

Hardware firewall for protection



Black Diamond

Core switching, and future load balancing



Cisco 12008

Core routing and peering



Core Functions:

·        Core database operations are provided for by twin Sun Enterprise 4500 multiprocessor servers running the Solaris operating system, and Oracle 8i database software utilising the parallelism features of the database engine.

·        As a backup to the core database server a Sun Enterprise 420R is constantly kept in synchronisation with the core database to provide a failover. As with the core database machine, this server runs Solaris and Oracle 8i.

·        Storage is through a RAID array, with data backup through a DLT backup unit.

·        A Network Engines "Blazer" dual-processor Intel PIII server appliance provides for email for "human" access to the ".tel" staff.

·        A Network Engines "Blazer" dual-processor Intel PIII server appliance also provides for immediate web provision via such sites as "".

·        A Network Engines "Blazer" dual-processor Intel PIII server appliance will be allocated to constantly check network connectivity, host and router status, and operation of the registry. This host will be one of many - one in each location - which will constantly monitor the registry.


Administrative Functions:

·        The financial system is operated through Oracle Financials (incorporating the ledger accounting system), on a Sun Enterprise 420R server running Solaris.



·        Core Registry/Registrar transactions are handled by a Sun Enterprise 420R server running Solaris.

·        DNS zone file generation and propogation is handled by two redundant Network Engines "Blazer" dual-processor Intel PIII server appliances. These run the Linux operating system.



·        Internal switching is handled by an Extreme Networks Black Diamond router, which also provides load balancing features for expansion.

·        Protecting the network and handling the VPN is a Cisco PIX hardware firewall model 515.

·        The network gateway is handled by a high-power Cisco 7200 router.


Interoperability is handled through an Extreme Networks Black Diamond core switch handling level-3 switching through a 48-port line card, providing resiliency and failover protection. As all the servers are Unix-based, there are very few anticipated interoperability issues.


Hardware Details


The specifications of the machines used within the Telnic environment are:


Sun "Enterprise 4502" Server

6 x 400Mhz processors; 2 x 18GB SCSI HDD; 2 x CPU/Memory Boards; 4Gb RAM; 2 power/cooling modules; 2 S-BUS I/O boards; S-BUS Quad 100baseTx Ethernet card

OS: Sun Solaris 8.0

Software: Oracle 8i

Sun "Enterprise 420R" Server

2 x 450Mhz processors; 2 x 18Gb SCSI HDD; CD-ROM; 2 x PSU; 1GB RAM; 100baseTx Ethernet card

OS: Sun Solaris 8.0

Sun RAID/DLT array

Sun "Storedge A1000" RAID solution with 145GB space, split into 4 x 36GB disks; 8-slot Tape Library with 1 x DLT7000

Software: Veritas BusinessSuite Backup Software

Network Engines "Blazer" Server

Dual Intel™ Pentium III 600MHz processors; 256MB DRAM; 20GB IDE HDD; dual 10/100baseTx ethernet ports; system maintenance bus for out-of-band management; cluster maintenance bus external connection for easy integration with a Network Engines cluster.

OS: Debian Linux stable release 2.2

Regulatory Approval: UL, FCC Class A, CE, CISPR Class B, VCCI

Cisco 12008 Router

256MB DRAM to hold BGP routemap if needed; 64MB packet buffer RAM; Dual redundant PSU setup; 8-port 100baseTx line card; redundant GRP card with 200 MHz R5000 CPU.

Software: Cisco IOS Service Provider Secure Shell v12.0

Extreme Networks 6808 Black Diamond Router

3-layer switching backplane with redundant load-sharing Management Switch; 48-port 100baseTx line card with non-blocking 128Gbps architecture; policy-based QoS extensions; dual redundant PSU setup.

Software: ExtremeWare Dual image

Cisco PIX Firewall 515

PIX solid-state hardware firewall with proprietary Cisco software; dual redundant PSU setup; dual redundant chassis setup


Security is handled for the most part by the delimitation of a DMZ behind the Cisco PIX firewall. Tripwire technologies will be used to give a second level of protection to the data servers. Redundancy of power and processing power has been specified where possible to give the highest availability possible.



Satellite Systems


Distributed systems are based in the following locations:


·        US East Coast & West Coast

·        Amsterdam

·        Germany

·        Denmark

·        Russia

·        Australia

·        South Africa

·        Japan

·        Singapore

·        South America

·        Sweden




All locations are manned 24 hours, and employ facilities management engineers available to carry out technical tasks up to a certain level. Even with this borne in mind, we have considered failsafe systems which will continue the operation of the .tel domain name even if a whole continent is rendered inoperative.


Satellite systems rely on a network connection from either a local provider and/or a telecommunications company. Larger communications companies (such as UUnet or AboveNet) are favoured because of their peering arrangements and throughput: multiple companies have been chosen to give as wide a spread of ASN peers as possible.


Each distributed cluster is identical and consists of the following machines:


·        4 x Network Engines "Blazer" server appliances, to carry out the following tasks:

·        1 x DNS repeater server

·        1 x mail relay

·        1 x monitor machine

·        1 x failover backup machine, handling any task automatically

·        1 x APC SmartUPS rackmount backup PSU (acting as a supplement to each location’s own power backup facilities).

·        1 x APC PowerSwitch, to allow remote power-down where necessary.

·        1 x Cisco PIX Firewall model 515, handling VPN provision between the network core and the satellite station.

·        1 x Cisco Catalyst 2924 high-performance switch.


The network topology at each satellite location is constructed thus:



This setup has been tested extensively and shown to be reliable and adequate for the task. The storage requirement of each location is not high, and the rack space requirement is less than 30U.


Connectivity at each secondary location is provided by a 2Mb link through mixed bandwidth providers:






US: San Jose

AboveNet (West Coast hub)

50 W. San Fernando Street,

San Jose, CA


US: New York Telehouse

AboveNet (East Coast hub)

60 Hudson Street

New York


Netherlands: Amsterdam




Johan Huizingalaan 759

1066 VH Amsterdam

Nederland Map


Germany: Frankfurt




Eschborner Landstraße 110

60489 Frankfurt


Denmark: Copenhagen

UUnet (Partner Arrangement)

<exact location unavailable>


Russia: Moscow


Russian Federation,


Miusskaya Pl., 6, bild. 3


Australia: Sydney

UUnet (via UUhost service)

<exact location unavailable>


South Africa: Capetown

UUnet (via UUhost service)

<exact location unavailable>


Japan: Tokyo


KDD Otemachi Building,

1-8-1 Otemachi,

Chiyoda-ku, Tokyo



UUnet (Partner Arrangement)

<exact location unavailable>


Brazil: Sao Paulo

Diveo DataCentre

Diveo do Brasil Telecomunicações Ltda.

Rua Tenente Negrão,

166 - 20 andar

Itaim-Bibi 04530-030

São Paulo


Sweden: Kista-Stockholm

UUnet (Partner Arrangement)

<exact location unavailable>



All centres are open 24 hours a day, 7 days a week, with security guards and duty engineers available.


Data Flow


Within the Telnic registration system the following data flow applies:




The more detailed second-level data-flow illustrates the inclusion of the verification and authentication stages of the registration process:






Registry software is provided via CentralNic's own turnkey system, developed in-house since 1993. The software is a complete registry package encompassing email automaton, domain administration, customer management, and automated logging. It has been proven in a production environment running CentralNic's own registry systems, and is in a continuous state of development utilising in-house programming staff. The current incarnation of the system left the beta-test stage during August 2000.


The CentralNic system comprises of three separate sections:


Staff Console

Designed to provide for all staff enquiries and changes regarding any object within the database, this section operates through a web browser. Via this interface any member of staff may add, change or delete an object and carry out maintenance on that object.


Registrar Console

A subset of the staff console, designed to operate only on a particular registrar's names. Registrars may carry out most of the tasks the staff console can carry out, but they will be restricted to names over which they are tagged as having control. This section is also accessed through a web browser.


Back-End Systems

The day-to-day housekeeping and compilation of files are carried out periodically by the back-end system. Most scripts are written using Perl or C, and are designed with scaleability and reliability in mind. The back-end systems also deal with the current email automaton, which will be superceded by an XML-based transaction engine for registrars.


The CentralNic software is split into abstract modules, and database calls are carried out through a Perl-based API. The re-use and abstract modularisation of code has been encouraged throughout the development to assist in upward scaling and feature expansion.


The console interfaces are designed with elegance and usability in mind. A typical screenshot of the interface follows:



The domain editing screen is similarly user-friendly:




DNS requirements are serviced through use of the popular Berkeley Internet Naming Daemon, currently through version 8.1.2pl5 but in the future through version 9. This will allow implementation of the Secure DNS protocol DNSSEC. To this end several members of the technical team have been working with RIPE in the training and implementation of a trial system, with the eventual aim of creating a reliable production system.


The software has been specified with the immediate implementation of the next-generation Internet protocol IPv6 in mind: to this end the .tel registry will be launched with IPv6 support from the outset. Legacy support will however be implemented for IPv4, as the registry will launch during the transitional period.



D15.2.2. Registry-registrar model and protocol.


The format of the registry/registrar/registrant relationship within the Telnic system follows this pattern:




·        Registrars are primarily responsible for database transactions for all registrants under their control. To all intents and purposes, registrars act as a fourth handle whose details override the administrative, technical and billing contacts, and inhibit the registrant from submitting a change to the Telnic database directly.


·        Registrants are the end-users who submit changes to the registrars for merging into the main database.


Occasionally registrars may have relationships with resellers; however, such resellers should not be expected to implement the processing of changes directly to the database itself and instead will be dependent on any mechanism the registrar may implement to update the database.


It may also be possible that a registrant wishes to directly approach the registry operator: in such cases, a "discouragement fee" will be necessary, to ensure that the registrant approaches a more cost-effective reseller.



Dialogue Between Registry and Registrar


The registrar will require a common, secure, validated format of both querying and updating the database. Rather than implement an API within an environment which may not be available with the registrar we will be using the XML document language.


Why XML? It is a standard data definition language, with accepted limitations and a certain amount of built-in validation. This makes the operation of the registry/registrar relationship a lot easier, as it is documented and many newer database systems will interact directly with an XML-based system: the ease of implementation for registrars is of course paramount here.


It is worth mentioning at this point that CentralNic is a member of a working group with CENTR, the Council of European National Top-Level Registries, to build a standard XML template method for registering domain names and communicating with registry databases. Indeed, several ccTLD registries have signalled their intent to convert wholly to an XML basis internally.


The registry/registrar dialogue is carried out using the transaction server, a Sun Enterprise 420R server:




In effect, the transaction server acts as a proxy to the core database, carrying out validation and authentication checks on any attempted database operations to preserve database integrity and the cleanliness of the data therein.


XML Data Definitions


Domain Object DTD:


<!ELEMENT domain (key|owner|handle+|host*)>

<!ATTLIST domain

            id ID #IMPLIED

            function NOTATIONS (register|delete|modify|request) #REQUIRED

registrar CDATA #REQUIRED>




<!ELEMENT owner (oname|oaddress|ocountry|ophone|ofax|oemail)>

<!ELEMENT oname (#PCDATA)>

<!ELEMENT oaddress (#PCDATA)>

<!ELEMENT ocountry (#PCDATA)>

<!ELEMENT ophone (#PCDATA)>


<!ELEMENT oemail (#PCDATA)>


<!ELEMENT handle (hname|haddress|hcountry|hphone|hfax|hemail)>

<!ATTLIST handle

            id CDATA #IMPLIED

type NOTATIONS (admin|billing|technical) #REQUIRED


<!ELEMENT hname (#PCDATA)>

<!ELEMENT haddress (#PCDATA)>

<!ELEMENT hcountry (#PCDATA)>

<!ELEMENT hphone (#PCDATA)>


<!ELEMENT hemail (#PCDATA)>



<!ATTLIST host

            id CDATA #REQUIRED>



Example Document:


<?xml version="1.0" standalone="yes" ?>

<!DOCTYPE domain SYSTEM domain.dtd>

<domain id="do8384" registrar="re4848" function="register">



            <oname>Bob Smith</oname>

<oaddress>50 The Mount, Smithfields,

Smithtown, SM5 4ST</oaddress>


<ophone>+44 7775 358485</ophone>

<ofax>+44 7573 483948</ofax>




                        <!-- Use existing handles -->

                        <handle id="bs9385" type="admin"/>

                        <handle id="bs9385" type="technical"/>


                        <!-- Create a new handle -->

                        <handle type="billing">

            <hname>Bob Smith</hname>

<haddress>50 The Mount, Smithfields,

Smithtown, SM5 4ST</haddress>


<hphone>+44 7775 358485</hphone>

<hfax>+44 7573 483948</hfax>




<!-- Nameserver entries -->

<host id="ho4387"/>

<host id="ho3948"/>





Handle Object DTD:


<!ELEMENT handle (name|address|country|phone|fax|authentication)>

<!ATTLIST handle

            id ID #IMPLIED

            function NOTATIONS (register|delete|modify|request) #REQUIRED

            type NOTATIONS (person | role | registrar) #REQUIRED




<!ELEMENT address (#PCDATA)>

<!ELEMENT country (#PCDATA)>

<!ELEMENT phone (#PCDATA)>



<!ELEMENT authentication (#PCDATA)>

<!ATTLIST authentication

            method NOTATIONS (pgp | x509 | signature) #REQUIRED

            object ID #REQUIRED>



Example Document:


<?xml version="1.0" standalone="yes" ?>

<!DOCTYPE handle SYSTEM handle.dtd>

<handle type="person" id="bs9384" email="" function="modify">

<name>Bob Smith</name>

<address>50 The Mount, Smithfields, Smithtown, SM5 4ST</address>


<phone>+44 7775 358485</phone>

<fax>+44 7573 483948</fax>

<authentication method="key" object="au3948"/>




Host Object DTD:


<!ELEMENT host (name|ip)>

<!ATTLIST host

            id ID #IMPLIED

            function NOTATIONS (register|delete|modify|request) #REQUIRED







            type NOTATIONS (ipv4 | ipv6) #REQUIRED>



Example Document:


<?xml version="1.0" standalone="yes" ?>

<!DOCTYPE host SYSTEM host.dtd>

<host id="ho4958" tech="te9385" function="modify">


<ip type="ipv4"></ip>




Error Codes


As a result of a transaction with the Registry/Registrar system, it is anticipated that a variety of error codes may be produced. This include:


·        Within the scope of object creation:

Cannot create object

Object already exists


·        Within the scope of object modification:

Cannot modify object

Object does not exist

You do not have permission to modify this object


·        Within the script of object deletion:

Cannot delete object

Object is still referenced - cannot delete

Object does not exist

You do not have permission to modify this object


During implementation of this section a full exhaustive list of error codes will be compiled.



Registry-Registrar Connection


Requests for database handling will be made via a https-style 128-bit SSL connection, with authentication option chosen by the registrar in accordance with the types within the authentication table. This method has been used widely for financial transactions on the Internet and is proven in the industry as a secure and reliable transaction method.



Registrar Transfer


Registrar transfer will be achieved through issuance of a modification request with the domain object, with the new registrar handle.


D15.2.3. Database capabilities.


The database consists of the following subsections:


·        Domain Objects

The .TEL domain data itself. Each domain which is registered within the Telnic database has a single domain entry, but it may contain expired domain details.


·        Host Objects

Verified name-servers which provide for the domain objects. Verification of nameservers is covered later. Host objects are linked to domain objects through the HostEntries table.


·        Handles

Each administrative contact, technical contact or billing contact is referenced through a handle. A handle is defined as a "contact person or role".


·        Authentication

Details for authentication of requests, including PGP keys or X509 public keys. A handle may or may not have an authentication request.


·        History

This table consists of descriptive textual entries for each modification of an object within the database; the concept is that any change is traceable immediately to a particular source simply by pivoting the data within the history database.


·        Support

Each support object represents a support incident - whether that be a registration via email, a telephone conversation to the support department, etc. A support object forms part of a portfolio of objects with the same incident number.


·        Payment & Financial Data

Handled primarily by the Oracle Financials package, this contains invoices, proforma invoices, credit account details, ledger information, etc.



The second-normal database entity-relationship diagram looks like this:





The detailed attributes of each object are as follows (underlined attributes are primary keys, italicised attributes are foreign keys):



Physical Name










Domain object ID




Domain name string, eg. "".





   "on hold",












The name of the domain owner




The address of the domain owner




The domain owner's country/region




The domain owner's telephone number, including the international code, in the format "+cc xxxxxxxxx"




The domain owner's facsimile number, including the international code, in the format "+cc xxxxxxxxx"




The domain name owner's email address








The handle object of the administrative contact




The handle object of the technical contact




The handle object of the billing contact




The registrar object maintaining the record - if null, the maintainer is the registry itself








The object's creation date




The expiry date of the object: disconnections and reminders are taken from this attribute




The date of the last modification to this domain object




The email address of the last person/system to carry out any modification on this object








Object ID of the corresponding host entry




Object ID of the corresponding domain entry








Handle object ID








The personality of the handle:

·          "Person" signifies an individual person, eg. "John Smith"

·          "Role" signifies a role account, eg. "Hostmaster"

·          "Registrar" signifies a registrar account, eg. "Selective Internet GmbH"








Contact name




Contact address




Contact region/country




Contact telephone number, including the international code, in the format "+cc nnnnnnnnnn"




Contact facsimile number, including the international code, in the format "+cc nnnnnnnnnn"




Contact's email address











The authentication method for operations involving this handle, host or domain objects for which this handle is administrative or technical contact.




The object ID of the authentication record associated with this handle.








Handle object's creation date




The date this handle was last modified




The email address of the last person/system to carry out any modification to this handle








Object ID of the Host entry




Hostname, eg. ""




IP Address of host, stored in IPv6 format








Host object's creation date




The date this handle was last modified




The email address of the last person/system to carry out any modification to this handle








Object ID of the Authentication entry




































Object ID of the History entry




































Object ID of the Support entry








The domain name of the support object




The date and time the support object was entered into the database - normally the date and time the email was received, or the call was taken
















Object ID of the Registrar entry




The Registrar's administrative handle object ID




The Technical Handle's administrative handle object ID




The Billing Handle's administrative handle object ID




The credit level of the Registrar


A domain may have one of the following statuses:

-         Live: The domain is in the DNS zone files and active.

-         On Hold: Due to non-payment or some other incident, the domain is still active but is not placed in the DNS zone files.

-         Deleted: The domain has been deleted and may be re-registered by another party.

-         Prohibited: The domain is not available for registration by a registrar or registrant.


Database Size


Given that a typical domain object is 274 bytes long, as observed through CentralNic’s own experience running a registry, the initial figures look like this:



Given the above figures, the hardware specified will be more than adequate for the first five years.





Database reporting on the following factors:


-         Database size, split into individual tables

-         Throughput monitoring, both in terms of query speed and quantity

-         Identification of potential bottlenecks

-         Constant projections of database size at 1-month periods over the next 3 years


Database reports will be sent every three hours to the duty database administrator, and a more extensive report will be run weekly.





By the middle of the second year, we will introduce Oracle's parallelism capability over two different Sun Enterprise 4500 chassis, giving extra redundancy and reliability. The parallelism is easily expandable, and splits the processes over several machines.



Database Integrity


A constant referential integrity check will be carried out as a daemon on the database cluster to ensure that the possibility of dereferenced data is minimised. Checkpoints will also be used within the transaction log.


Object deletion will be covered later, but through the deletion procedure strict checks will be made for the purposes of preventing dereferenced data from entering the database, for example by deleting a handle object which is referenced by a domain object thus creating potentially invalid data.


In the extremely unlikely event of database corruption, data recovery will be possible through Oracle's automated use of transaction logging and rollbacks.



Change Notification


Before a change is made to the database, an authorisation must take place. The authorisation may be via an emailed verification request, or automatically through the registry/registrar protocol.

Notifications are automatically made whenever an object is changed to the following contacts:



Notification via Email


Technical Handle, Administrative Handle


Related Host Handle


Relevant Handle


Relevant Handle


Object Creation


Each type of database object goes through a different set of validation rules before it is entered into the database. To illustrate the flow of information, the following chart illustrates the different stages of creating an object:




Object Editing


An object change request will go through the following procedure:


Object Deletion


The deletion of objects must be handled with the utmost care, and indeed domain objects are not designed to be deleted: rather they are designed to be "disconnected" or given the more temporary "held" status.


The status of objects and their ability to be deleted are:



Deletion Status


May not be deleted, but disconnected domain names older than 3 years may be archived.


May be deleted only if unreferenced by any other object: confirmation provided by an emailed verification request


May be deleted only if unreferenced by any other object: confirmation provided by an emailed verification request to the technical contact.


May not be deleted, but old history entries linked to disconnected domain names may be archived.


May not be deleted, but closed tickets may be archived.


May not be deleted.


May be deleted.


The strict nature of the deletion status is to preserve referential integrity throughout the database, as mentioned earlier.



D15.2.4. Zone file generation.


The building of zone files will take place at an interval either established by CentralNic staff as the most optimum, or at a set interval defined by TelNic management.


This may be a policy issue on the TelNic side, and as such any recommendations / definitions from them would be used. A script would be used to query the database at the given intervals, and to build the zone file based on data it finds from all zones contained within. This script has been proven to be reliable, as it has been running on the CentralNic systems over a long time period. The code is stable, and can be run at any time to generate a new zone file.


What we envisage happening is that a server, dedicated for the purpose, is used as the machine which builds all of the zone files periodically, as described above. Refresh times in the zone file would then allow our core servers to update the zone file periodically. Following on from this, the core DNS servers will not be impacted by the work of having to rebuild the zone file from the database, as this will be done periodically on a separate server.


Code Flow Chart


·        Login to database.


·        Pull a list of suffixes from a table in the database.


·        Then, for each suffix in that list:


1) Grab an alphabetically sorted list of all the domains and their associated DNS servers.


2) Add a line to the open file with the domain name and the formatted NS entries.


·        This is repeated until the code has gone through the entire database, for each suffix.


SOA times


Network Solutions uses the following values for their SOA records on their zones:


86400 - 1 Day


1800:                     Refresh                       - 30 minutes

900:                       Retry                          - 15 minutes

604800:                 Expire                         - 7 day expire

86400:                   Minimum TTL            - 1 day




10800 - 5 hours


10800:                   Refresh                       - 5 hours

1800:                     Retry                          - 30 minutes

6048000:               Expire                         - 70 days

10800:                   Minimum TTL            - 5 hours


The refresh times on our domains are higher than NSI's - this is because we want our data to last longer in caches before it expires. The Retry field is only a little bit higher - this does not cause significant impact. Expire times are the same. Minimum TTL, however, is different. This is because we update our zone files more than once a day - every 3 hours, in fact, and so a lower TTL is more suited to bringing fresh data into the system at the earliest possible point.


Automatic Generation


The small perl script described above is the key to zone file generation within the system - this script is called, at present, on the primary name server. This is done with a cron job - a scheduled command to be run on a system - every 3 hours on the hour starting at midnight, and rebuilds the zone files. The name server then loads these new files and begins serving requests for any new entries immediately.


There is no downtime when the zonefiles are being built by the script, although some load is put on the system generating the zone files. This is why we propose to move this task onto a separate server.



D15.2.5. Zone file distribution and publication.


It is imperative that zone files are maintained at all times. It is for this reason that the worldwide network has been specified as in section 15.2.1.


Primary nameservers are located in:


United Kingdom

London Telehouse

United States

San Jose

United States

New York Telehouse











South Africa







Sao Paulo





Zone files are distributed via a secure point-to-point tunnelled virtual private network (VPN) to each location, and verified through periodic independent checksum utilising a tripwire-style approach. Connection requests generate a one-time 128-bit key utilised over an SSL link to circumvent network scanning. Refreshing of zone files and DNS reload are initiated by the core zone file generation machines every 24 hours maximum.


Distribution is initiated by the core zone file generation machines "zonehost-1" and "zonehost-2". Generation is split over the two machine equally, and logged remotely to the monitoring and logging host.



Zone File Access


Access to zone transfers from any primary server is restricted to:


-         Approved secondaries (none exist in the initial rollout plan)

-         Host count mechanisms as performed by RIPE, UKERNA, etc.


For access to zone transfers to be approved, it is envisaged that the requesting body must agree to a contract restricting use of the data in order to prevent usage such as unsolicited commercial email, etc.


CentralNic is committed to using the DNSSEC protocol as it becomes available from the root nameservers.



D15.2.6. Billing and collection systems.


The financial system chosen is Oracle Financials, due to its multi-user capabilities, platform independence, scalability and close relationship with the Oracle database itself. This enables the Console system to link in and provide instant statements of account, the ability to secure payment online, and seamlessly tie in with the general ledger.


The reporting structure of the Oracle Financials system is such that it is provided through a web interface - therefore the reporting can be integrated within the Console system, supplying live key performance indicators to management, and optimising project execution. Most, if not all financial reports will be generated by the Oracle Financials system.


The core server for the Financials system is a high-specification Sun Enterprise 420R server, described earlier in section 15.2.1. It is secured behind the Cisco PIX firewall, and any reporting/manipulation will only be permissible through the VPN to authorised personnel, administered via a username/password arrangement.


Email Billing & Reminders

The current CentralNic system allows for an automated setup of invoicing, reminders after a preset period, withholding of domains, and subsequent deletion.


The following boundary timescales apply within this process:




Registration Date (r)

Invoice is issued with notice to pay by "r + 30 days".

Expiry date e is set to r + 30 days.

Expiry Date (e)

Reminder is issued via email to billing contact

e + 7 days

Disconnection notice is issued via email to billing contact and administrative contact

e + 14 days

Domain is placed "on hold"

e + 21 days

Domain is released for re-registration




D15.2.7. Data escrow and backup.


·        Daily backups.

·        Configs + Data from all critical servers is pulled off on a daily basis.

·        CVSDB.

·        Mail config.

·        Majordomo.

·        Homedirs.

·        websites.


We are investigating total on-the-fly backups of the database using software designed for the purpose. This will allow us to maintain a real time copy on a separate machine that can be used to transaction rollback if necessary - this is unlikely but we prefer to work on the "prevention is better than cure" rule.


Restoration Capabilities and Procedures


The ability to restore data to any machine is highly dependent on it having a network connection. If a machine suffers total failure, which can be replaced in a very short time, it is possible to do a minimal install to that machine and then to restore from backup in a short period. In the meantime other machines will continue the work of the failed unit, so customers / clients should never see any problems. Tasks may take slightly longer to execute, depending on which machine fails, but the end result is hopefully a totally resilient solution.


24 hour paging and support staff will alert senior staff to any problems as soon as they are noticed - problems are usually picked up inside a couple of minutes of occurring, by the automatic systems in place.


Senior staff are on call at all times and if support staff cannot resolve a problem in a defined period of time, they will follow procedures to bring senior staff out to resolve the issue. It is not possible to give a guaranteed time of fix for all problems, as the nature of a problem may make it more difficult to solve than at first thought, and may leave issues outside of our control, such as acquiring replacement hardware.


On the issue of replacement hardware, we aim to have backup cluster units at our premises ready to "slot in" in the event of UK problems. Any problems in Global locations that result in hardware failure or otherwise will be solved as soon as physically possible - if we establish that an entire global location has suffered hardware failure (a very unlikely event), the first response will be from support or technical staff, to keep services running on alternate machines in different locations. If the problem is hardware failure, a replacement unit or units will be sent out to the affected location and a member of senior technical staff will go to the location as soon as physically possible, to replace the units and restore service to the area. We aim that due to resilience within our network and our systems, that other units will take over the job of the failed units almost immediately. However, there may be a short period of downtime while the backup units take over the job of the failed units, but we will use our best endeavours to ensure that any downtime is keep to an absolute minimum.


Backup Methods


There is a daily backup of system files, as shown above - these are rotated, such that we have data rolling back at least a week.


Off-site backups are made by archiving and transferring the same backup files to a location which is physically nuclear warfare safe - see for information. A cluster of servers within this location caters for resilience and redundancy within the backup facility. We are also investigating off continent backups either by DLT transfer by carrier, or by file transfer to off site servers.



D15.2.8. Publicly accessible look up/Whois service.


Every domain name registry should operate a Whois service conforming to RFC954 to allow open and clear access to domain objects within a database (subject to local data jurisdiction laws), and CentralNic is no exception.


Whois queries are handled by a separate Whois server: a Sun Enterprise 420R which queries the live database directly. The net effect of this is that the Whois data is kept completely up-to-date - a system at CentralNic which has been proven in a production environment.


The Whois daemon software is a multithreaded daemon application written in C. Unlike most other Whois daemons, it is stand-alone (not spawned from inetd).


Responses to Whois queries look like this:




Registrant: Mailbox Hostmaster, Mailbox Internet


Client Contact, Billing Contact: (I5502)

  Mailbox Hostmaster

  Mailbox Internet

  163 New Kings Road


  London SW6 4SN

  United Kingdom


    Tel: 0870 845 9292

    Fax: 0870 845 9293


Technical Contact: (I2048)

  Joel Rowbottom

  Mailbox Internet Ltd

  163 New Kings Road


  London SW6 4SN

  United Kingdom


    Tel: (020) 7371 8558

    Fax: (020) 7736 9253


Record created on  8 Sep 2000

Record paid up to  8 Sep 2002

Record last updated on 28 Sep 2000


Domain servers listed in order:





This whois service is provided by CentralNic Ltd and only contains information

pertaining to Internet domain names we have registered for our customers. By

using this service you are agreeing (1) not to use any information presented

here for any purpose other than determining ownership of domain names (2) not

to store or reproduce this data in any way. CentralNic Ltd -



Under the CORE system many registrars do not maintain their Whois server in a production environment, nor keep it up-to-date for referral through the "Referral Whois" system detailed in RFC2167. Bearing this in mind, the Whois queries will be centralised. This is not to say that referrals will not happen to the centralised Telnic server, but centralisation will remain the key to a reliable service.


In order to minimise abuse, a constraint will be placed upon the number of queries which may originate from one particular IP address over a single 24-hour period: this method has been implemented by several registries and is an effective way of combatting what effectively amounts to a denial-of-service attack. Queries may also be performed from the Telnic website, and will be similarly limited.


Options to the Whois system are in line with RFC1834: "Whois and Network Information Lookup Service, Whois++", and related RFC documents RFC1835, RFC1913 and RFC1914.


Additionally, a second more restrictive Whois will be installed to provide domain object access in XML format, to the specification given in section 15.2.2.



D15.2.9. System security.


We take every step to ensure the security of our systems. This comprises hardware security for the servers, network security in the form of multiple firewall layers, and also physical security in the form of access restrictions at the facility centres that host our servers.


Hardware Security / Physical Security


Hardware security and physical security tie in together very closely. All of the servers that handle our network are in locked cases - which in turn are in locked cabinets, in a locked cage, within the facility centre. The only people with access to the cage that our equipment is kept in are the facilites staff, and senior technical staff of the company. This rule is very strictly applied. Indeed - many of the colocation providers restrict the access to their own rules - in most circumstances anyone wishing to have access to any of the CentralNic servers would need Photo ID, which has previously been communicated with the facility staff by an authorised contact. Otherwise, the person would not be allowed into the facility. In addition to this, most of the machines are in locked cases situated in locked cabinets. The same rules apply here - only senior technical staff and the facility staff have keys for the cabinets and also for the machine cases. This ensures that no-one can just walk into the facility centre, into the cage, open the cabinet, and tamper with the machines.


Facility centres are fully power protected, and also have fire detection and control systems, in addition ot full environmental monitoring and HVAC Air Conditioning Systems. Most centres are also earthquake-proof - enabled by seismic bracing within the structure of the building itself. This is more prominent in earthquake prone locations, but most centres have this level of protection.


Full audit trails are available from the provider at any time - this ensures that actions taken can be traced. Everything is recorded - date and time of exit and entry, the escort to the cage, what was taken in and out in terms of hardware, and technical staff will keep a record of actions taken and work carried out on systems.


Network Security


Access to machines over the network is the biggest single point of access, and hence, the one that requires the most protection. To this end, we employ hardware firewalling technology from Cisco Systems, which also provides us with network access control, and another layer of traffic logging.


Cisco Pix Firewall


We use Cisco Pix Firewalling units at each location of servers to provide full hardware protection - these units are completely self contained and thus maintainence free. By using multiple units, not only do we get failover / redundancy of the firewalling, but also we get the ability to reroute traffic between machines seamlessly. The units communicate with each other over an encrypted connection - this allows us to effectively set up a totally private internal network for all of the global servers whereby the firewall hardware handles the address translation and routing of traffic.


We utilise 2 units in each location for redundancy. These units are effectively configured to run in the same state at all times by communicating directly across a local channel so that if one unit loses network connectivity, Power, or has a failure, the other unit may take over with minimal disruption to services.


In combination with managed switches, this provides us with a fully redundant hardware firewalling solution, and with the VPN features of the PIX hardware, we have a highly secure method for transferring sensitive network traffic. This is especially useful for network logging facilities, and also transfer of data to a machine dedicated for backup purposes, as all the data is transferred over a secure connection. All traffic that does not originate from a public internet connection is encrypted, thus protecting the intellectual property within the data, as the database is never transmitted in the clear or revealed to the outside world.






The Cisco Pix units that we utilise can handle 125,000 simultaneous connections - given that most Unix and Linux machines can only handle 65,000 connections at once, it is very unlikely that the units will be overloeded. We would be more concerned about other hardware, such as routers, which would probably not withstand such load - we will do everything we can to prevent problems in this area. The PIX product does have "floodguard" technology, however, which is designed to prevent such things as the recently publicised "Distributed Denial Of Service" attacks on high publicity sites.


The main role of the Pix units, however, is not to provide failover, but to provide firewalling. To this end, all traffic from the internet that is not coming over the encrypted link is highly restricted. On the server side, only database ports will remain open to a restricted set of sources. At DNS server level, Pix firewalling in combination with software restrictions will secure the DNS servers from unauthorised access attempts.


Passwords / Access


All server passwords are changed not less than once every 2 weeks. Additional methods of authentication are used - for remote access, SecureID and/or Cryptocard technology ensures that only authorised senior technical staff have access to the machines, by requiring a hardware based token authentication. Such hardware tokens guarantee that passwords are only valid for 2 minutes at a time, thus greatly reducing any risks in the unlikely event of traffic being intercepted, or of passwords being stolen. In addition to the token code, a user PIN is also required. In the event of a token being lost or stolen it can easily be rendered useless by setting an option on the authentication server. This solution has the added benefit of logging all attempted logins on the authentication server.


All sensitive traffic on the network will be encrypted where it traverses untrusted networks, as described above. This makes it impossible for a hacker to sniff passwords in transit over the network and use them to access machines in an unauthorised manner. Also, machines will be configured to only allow connections from certain sources, so an attacker would have to already be on the network, and have a password, and a hardware authentication token, to move across the network. This allows legitimate access with no problems, but unauthorised access is very difficult.


New passwords are communicated to facility staff only if absolutely necessary. Console logins only require a username and password, as it is impractical to give facility staff hardware tokens to perform remote maintainence if required. We intend that we will be able to do everything remotely, as the combination of a Terminal Server, remote power switch, and network access, ensures that there is effectively nothing that cannot be done remotely that could be done at the machine console, except in the case of hardware or provider connectivity problems. Procedures for dealing with hardware problems are described in the System Reliability section.



D15.2.10. Peak capacities.


Peak capacities cannot accurately be predicted as hardware and software will not be in operation until the alpha-test stage.

Given the nature of the potential for a new top-level domain name and unavailability of prior application data, it would not be prudent to attempt to predict peak capacities at this stage. However, CentralNic is confident the systems specified are scalable to an upper ceiling of 10,000,000 registrations based upon it's own experience in the domain name market.


D15.2.11. System reliability.


Backup and coverage for outages is addressed in this proposal in sections 15.2.11 and 15.2.12.  It is worth noting however that in the event of a multiple catastrophic failure of our internal systems the front end of the registry is a queueing system which can store up to 3,906,250 registration applications in appropriate chronological sequence.

In the event of a major failure of all access to our systems (for example a major failure of a portion of the Internet itself), applications are handled by the standard email system which would indicate non-delivery to the initiating registrar.

In the six years during which we have been operating this situation has never affected our main systems, although local outages can obviously cut off individual registrars or resellers.  Cover for such situations has to be the responsibility of the local operator since we cannot detect them or circumvent them.

It is the aim of the Registry Operator to provide a service 24 hours a day, 7 days a week, 52 weeks a year. We set very high standards and use all resources we can to provide customers with the service they expect.


To this end, we only use high quality systems from suppliers such as Sun, Network Engines, and Cisco Systems. The connectivity for the global network comes from suppliers with a proven track record in providing high quality service and high availability to end users.


The connectivity suppliers monitor their own systems and networks on a constant basis, which allows them to provide us with the best possible service, which in turn allows us to provide the best possible service to the users.


All implemented systems are, where possible, fully redundant. At least 3 servers are installed in every location world-wide to handle requests - not only does this speed up responses, as traffic does not have to travel several thousand miles to it's destination and back again, but also it allows us to provide a fully redundant service in the case of hardware failure or otherwise.


Systems are configured such that a machine will take over the job of a different machine in the event of the first machine failing for any reason. We employ custom tools to suit this purpose, along with specialised hardware.


Our systems are also continuously monitored - all processes we run are checked every minute of the day. Any potential problems are immediately flagged and support staff are alerted - monitoring systems will try to fix any problems before technical staff are made aware of the problem, but if this is not possible staff will be alerted immediately, and will take appropriate action to resolve the issue.


Our tests have shown that under normal use the reliability of our systems is very high - outages are kept to an absolute minimum, and are usually resolved within minutes of being reported.


What do we monitor?


The automated systems on the network monitor everything possible - right through from the basic "this service is working" to the more advanced checking that data returns expected values, temperatures / fan speeds / voltages from sensors built in to the systems, that processes are running, and that network connectivity exists properly.


Multiple redundant and distributed monitoring takes place - it is quite feasible for a member of support staff to see an overview of the status of the entire network from their desk at any time of the day or night. If a problem occurs it will be flagged on this display, and staff can then "drill down" into the particular machine with the problem, identify what the cause is, and take steps to correct it.


If users see a problem which they believe support staff are not aware of, technical staff are contactable 24x7 by pager - there is a dedicated number to alert staff to a problem.


We keep a status page available to the general public which is constantly kept up to date, so customers can verify that we know about a problem and are working on it before they page us. This keeps support staff from receiving a multitude of pager messages, all describing a problem they already know about.


We do encourage people to let us know if we report a problem as fixed and it is still not working correctly, as this will improve our ability to resolve small problems before they turn into major issues.


Data Validation


Data in the database will regularly be validated and referential integrity will be checked on a constant basis by a daemon installed on the database server cluster.


History Logging


Our monitoring systems keep a full history of all events they record - processes going down, processes coming up, acknowledgements by staff, etc.


This means we can pull out reports on any system or service over a period of time. This also gives a complete history of things that have happened - if a service breaks we can check the history to see what has happened to that host or service previously.



D15.2.12. System outage prevention.


Our international network exists to provide sensible and fast routing of DNS queries. It also provides multiple redundancy.


It is worth noting that the total, long-term failure of a single node does not, in fact, materially impair our service. However, each location has full outage prevention systems as described below.


We protect the systems we invest in as much as possible. This includes such things as UPS cover for all parts of our systems, hardware RAID to protect the integrity and availability of our database and our servers, and hardware monitoring to ensure that any potential problems are discovered early and can be resolved before they develop into issues which will affect our customers.


Our Outage Prevention Measures are described in more detail below:




We integrate UPS products from APC <> - a proven leader of high quality UPS equipment - to ensure that our servers keep on running through power failures.


The batteries on the UPS systems will keep our servers running for at least 30 minutes - this is in addition to the power protection systems at each server facility. We anticipate that the combination of our own UPS's with 30 minutes runtime plus facility systems will mean that we never suffer a power outage.


The UPS sytems are complemented by a MasterSwitch solution from APC - this allows us to selectively turn the power on and off to any connected socket remotely. This gives us greater control of our servers and allows us to perform almost all problem resolution remotely.


If a piece of software crashes for whatever reason and hangs the machine, generally it is impossible for the machine to be rebooted remotely - this would involve a call to the facilities management staff, at cost, to reboot the machine. With this system in place we can perform this task ourselves, quickly and easily.


Both the UPS systems and the MasterSwitch systems are fully network connected - our monitoring systems are capable of extracting information from both UPS and Masterswitch via SNMP (Simple Network Management Protocol), an industry standard method for extracting and using network data. We can tell at a glance what the power status on a UPS is, it's runtime on batteries, it's temperature, etc - in the event of a battery failure staff will be notified immediately, and as such can schedule replacements / repair work to correct the problem.


Any problems with UPS hardware will not cause outages to the servers that are connected. For example - if a battery in a UPS fails, either due to manufacturing defects or through general use (UPS batteries are quoted as lasting around 2 years) - the UPS will send out an immediate alert, but will continue to power the systems connected to it. Staff will arrange for a resolution to the problem immediately. Even replacing a battery on the UPS systems does not require that the load on the UPS is turned off - this task can be performed quickly and easily by any member of staff to restore the unit to full use as soon as possible.


If the facility of a server loses power for a length of time that requires operation of our UPS, staff will be paged and alerted. If the power remains out for such a length of time that UPS battery power starts to run low, then automatic software will shutdown servers cleanly in turn, which allows us to keep at least one server running for as long as possible before a power failure. In the event of all power to a facility failing, monitoring systems will control the scheduled transfer of servers



D15.2.13. System Recovery Procedures.


In the unlikely event of a system outage occurring within the CentralNic network, systems monitoring would alert support staff and senior technical staff immediately.


Procedure for restoring from an unexpected outage


If a catastrophic error occurs on a server which causes failure of that server, the primary aim would firstly be to ensure no loss of service to the customers. Once this has been achieved, restoring the failed unit to a working setup is the next highest concern. If it is discovered that a disk has crashed or failed, the unit will be swapped out and a replacement, pre-configured unit will be swapped in as soon as is physically possible. The failed unit will then either be returned to the vendor on a 48 hour turnaround, or if the problem is small, will be fixed as soon as possible. If a machine can easily be restored to working order, it will be monitored closely by CentralNic Technical staff to ensure the problem does not recur, then if all tests are OK, the machine will be swapped back into service at a time that is not inconvienient to users. This is the primary logic behind having at least 3 servers in every location.


Redundant / Diverse Systems


This section is covered by section 15.2.12 - System Outage Prevention.


Recovery Processes


Due to the nature of failures, it is impossible to describe a recovery process for each. As such, all recovery will be undertaken using best endeavours, with the aim of restoring service as quickly as possible.


Training of Technical Staff


Staff will be trained in-house by Senior Technical Management to deal with potential recovery issues as they arrive. There will be demonstration systems which will have to be restored by the staff, under supervision, to gain experience in re-installing the OS and performing a restore of files from the backup server. This should enable backups to be undertaken by staff without senior staff supervision, but should a machine fail and backups be required, the company will undertake to have a member of Senior staff present to supervise and oversee the entire recovery process, and to co-ordinate other services, such as failover to secondary / backup units, liaising with component manufacturers, etc. If such an event occurs a member of Senior staff will be called - there will be a rota of Senior staff on call 24/7, to ensure availability.


Availability of software, operating systems, and hardware needed to restore the system


If a server fails for any reason, there is always a copy of the media containing the correct OS of that server within the building. If a remote server fails, the member of staff that travels to deal with the issue will also have a CD copy of the media.  Hardware availability is pre-arranged using service contracts with the manufacturers of the server equipment, i.e. Sun and Network Engines.


Backup Electrical Power Systems


All facility centres have redundant power supplies and UPS Units, which are supplemented by generators. This provides a guaranteed service at all times. Servers are also protected by their own UPS which will be in addition to any facility power protection, and will provide a runtime of 2 hours on the core Database servers, and 30 minutes for the global clusters.


Projected time for restoring the system


We estimate, based on our own experience, that after we have restored a machine to a working state, it should take no more than 45 minutes to restore  it to it's original status. This time is obviously in addition to any hardware problems that occur, but redundant machines will continue the work of the original machines while maintainence takes place. If a problem occurs with a core database server, the projected time could be a lot higher than this. As such, estimated recovery times are to be confirmed.


Procedures for testing the process of restoring the system to operation in the event of an outage


Backup tapes and procedures will be tested every month under supervision of a member of Senior Technical Staff. This is to ensure that staff are kept up to date on any changes in procedure that take place, and also any new technologies that may have been implemented. This also ensure validity of backup tapes and offsite backups.


Documentation kept on system outages and potential system problems that could result in outages


In combination with monitoring software, every outage is recorded into a database. Resolutions, notes, comments, etc are all entered into this database also via a web based administrative form - this allows management and/or technical staff to pull out reports in real-time on any given service or host. In a similar fashion, printed and typed documentation is stored containing details of potential problems that could result in outages, how to check for them, how to fix them, and what to do if the described method doesn't fix them.


D15.2.14. Technical and other support.


Availability of Support


There will be the following methods of obtaining support:


1.      "Delayed" support requests, answerable on a non-urgent basis:


·        Email

·        Web form submission

·        Facsimile support


2.      "Immediate" support requests, for which staff must be allocated to cope with demand more urgently:


·        Telephone support, providing low-cost or toll-free numbers where possible


It is envisaged that most end-user support will be carried out by registrars in their own geographic regions, therefore language support will not be a major issue. However, CentralNic already employ speakers fluent in English, Russian, German, Hungarian, Polish, Swedish, French, Italian, Punjabi and Hindi.


Registrars will be given their own particular contact name within the support department for arising issues, to assure customer service continuity is maintained.



Logging Support Tickets


Technical help will be logged via the ticketing system described earlier as Support Objects.

The following flowchart illustrates the procedure when a call is logged:





Online Assistance


The support given on the web site will be of paramount importance. In particular, we have considered the following areas:


·        Frequently Asked Questions

Compiled by the support staff in response to the most popular queries, this documentation will lower the level of support queries which need to be answered.


·        Support Ticketing Status Reports

An area of the web site which queries support tickets to retrieve status on whether support requests have been actioned, and thus provide a quality service to the enquirer.


·        Registrar/Registrant Discussion Maillists

A means by which the general public may discuss the ".tel" domain name, its ramifications and its operation.



Support Staff


Since the Internet spans many time zones and regions, front-line support will be a 24-hour operation requiring multi-lingual staff trained in the basics of domain administration. Shift patterns will follow a 12-hour continental pattern, 3-on 3-off arrangement, spread over four teams. Through this mechanism there will always be competent staff on-hand to assist registrars and end-users, and alert the appropriate people in the event of a problem.


A support database will be built up of symptoms, questions and resolutions to reduce the need for highly trained technical staff on front-line support.



General Technical Staff


The following positions will be 24-hour, rotational shift staff, with the given number being immediately available at any one time:


Staff Position

Day staff

Night staff

On Call

(surplus to night staff)

Shift Team Leader *




Hostmaster *




Database Administrator *