Unicorn a.s.

V Kapslovne 2767⁄2
Praha  130 00
CZ

+420602370806

+420221400114

http:⁄⁄unicorn.eu

Mr. David Kimr

Board Member

+420602370806

david.kimr@unicorn.eu

David Kimr

Board Member

+420602370806

david.kimr@unicornuniverse.eu

Corporation

Czech law

Attachments are not displayed on this form.

David Kimr
Member of Board
Jan Jaros
Member of Board
Martin Klima
Member of Board
Vladimir Kovar
Chairman of Board

unicorn

Attachments are not displayed on this form.

As the applied string is ASCII letters only, we do expect no operational nor rendering problems. All applications should accept the applied string without problems.

The applicant, company Unicorn a.s., was founded in 1990 by Mr. Vladimir Kovar, which started-up the business as an entrepreneur and still remains the owner and the chairman of the board of the company. In 1995 the company expanded and its structure became more complex. The Unicorn group of companies (“Unicorn Group”) had been created, the applicant being its parent company and the most important entity. In 2011 the Unicorn Group achieved a turnover of 1.325 billion CZK (more than 85 million USD.
From its very beginning the company Unicorn a.s. and afterwards the whole Unicorn Group focuses on providing complex services in the area of information systems and information and communication technologies. The Unicorn Groupʹs mission has been to bring customers a competitive edge and high added value by delivering top information products and services within the agreed quality, scope, time and budget. There are three product areas, on which the Unicorn Group is focused, each of them represented by one of Unicorn Group’s companies:
Unicorn Systems provides the largest information systems and solutions in the area of information and communication technologies. It has been operating on the market since 1990 and since then it has created a series of high-end large-scale solutions that are widespread and used among the most important companies in a variety of sectors. It has the best references from the banking, insurance, telecommunications, energy, industry, commerce and public sectors.
Unicorn Universe provides smart solutions for the support of management, sharing of information and mainly cooperation – you can organize your company, personal interests or other activities in your life. It builds a space on the Internet where you will be able to easily offer your business to others. You can communicate with business partners, share necessary information with colleagues or plan joint events together with friends at a single point. Maximum accessibility, absolute security and guaranteed protection of the data committed are its priorities. Users of the Unicorn Universe service can use their solutions round-the-clock, 7 days a week. They can work whenever and wherever – from any device with a display and a standard browser connected to the Internet. With the press of a button, users can enter their business. They can communicate with customers, partners, suppliers and others directly on Unicorn Universe platform. The system enables joint meetings in direct link to the related information. It is also possible to share current versions of documents and contracts with people in one common place. Each important activity is planned in direct link to its output in the system. Using Unicorn Universe system, people know which work to do. Vice versa, their managers are able to obtain the information important to them from the information system. They know what is happening in the company – what the current status of individual tasks and their outputs are.
Unicorn College is a reputable private university offering a high-quality university education in the field of information and communication technologies, economics, and management. It focuses on the systematic education of specialists in accredited disciplines with the aim of maximizing graduates’ competitive edge in their career. A comprehensive education system both summarizes and provides a well-balanced range of knowledge, consisting of the standards of good industry practice, applied research, corporate approach, and partner cooperation with industry leaders.
Since its foundation, all activities, services and products of the applicant and its daughter companies are being launched on the market under the UNICORN brand name. The UNICORN brand name is protected through number of trademarks, of which the Czech national trademark No. 184507 UNICORN (word) possesses the priority as of December 21, 1993. A list of UNICORN trademarks of the applicant is attached. Through its long-term and massive use not only on the territory of the Czech Republic, the UNICORN brand name and identical trademarks of the applicant gained good reputation and became well-known among all groups of customers.
The proposed gTLD “.unicorn” is thus the brand domain name enabling applicant to increase UNICORN brand awareness throughout the business community in the world. Registration and use of “.unicorn” domain name will establish certain brand consistency throughout all online social media forums, online search engines, and marketing campaigns. So far the applicant has to use national TLD “.cz” and “.eu”, which certainly limits the target group of customers and diminishes effects of applicant’s marketing efforts. “.unicorn” domain name will also increase visibility of the brand and the applicant, which means increased recognition, leading to increased confidence and trust in applicant’s UNICORN brand.
The proposed gTLD “.unicorn” should also assist applicant to improve communication between users of Unicorn Universe system and their identification. It will enable applicant, its employees, customers, partners and⁄or suppliers to better share their data and experiences in only one virtual space defined by Unicorn Universe platform. At the end of the day, the system (including “.unicorn” domain name) will comprise fully compatible and communicating group of Unicorn Universe users.
The purposes of the “.unicorn” gTLD are therefore a) to promote applicant and its products and services worldwide (without any geographical limitation); b) to improve the brand consistency and culture of its use; c) to assist applicant in establishing and developing community of Unicorn Universe system users.

The proposed gTLD “.unicorn” is the brand domain name. The applicant does intend to strictly control and limit registration and use of the domain name and does not expect any massive increase in numbers of users and registrants. The number of registrants and users of the domain name will not exceed 1000 in the first year with max. 20% growth every year. The applicant does not intend to be a commercial registry with thousands of registrations per month. The proposed gTLD “.unicorn” should serve mainly to applicant itself, for its promotion and better recognition throughout the business world, and to applicant’s customers and business partners, not to everyday use by infinite and unclosed number of registrants⁄users.
The applicant will register and maintain registrations of SLD under “.unicorn” gTLD through its contractual partner, company Gransy s.r.o. - the first Czech ICANN accredited registrar. A copy of the respective Letter of Intent is attached. With respect to the intended scope of use of the proposed gTLD, the applicant will not adopt any special registration rules and measures. The applicant itself will decide whether its business partner or any other subject using Unicorn Universe system should have also SLD under “.unicorn” and for what purpose. The applicant is entitled to terminate, at its discretion, a SLD registration if facts, on the basis of which the domain name was registered, change, for example if the registrant cease using Unicorn Universe or any other UNICORN system, if ceases to exist without any legal successor or dies without any heirs, or if acts against good morals and interests of the applicant.
The applicant will not request such private information from possible registrants and users of domain names under “.unicorn” gTLD. Thus no special measures for protecting the privacy or confidential information of users or registrants are needed. Moreover, the limited scope of use of “.unicorn” domain name excludes any possible breach or infringement of user’s privacy rights. 

The proposed gTLD “.unicorn” is the brand domain name. The applicant does intend to strictly control and limit registration and use of the domain name and does not expect any massive increase in numbers of users and registrants. The number of registrants and users of the domain name will not exceed 1000 in the first year with max. 20% growth every year. The applicant does not intend to be a commercial registry with thousands of registrations per month. The proposed gTLD “.unicorn” should serve mainly to applicant itself, for its promotion and better recognition throughout the business world, and to applicant’s customers and business partners, not to everyday use by infinite and unclosed number of registrants⁄users.
The applicant itself (at its own discretion) will decide whether its business partner or any other subject using Unicorn Universe system should have also SLD under “.unicorn” and for what purpose. Therefore,
i. No multiple applications are possible.
ii. No benefits for registrants are necessary.
iii. The applicant does not intend to make any contractual commitments to registrants regarding the price escalation. 

No

Attachments are not displayed on this form.

No

The proposed gTLD “.unicorn” is the brand domain name. The applicant does intend to strictly control and limit registration and use of the domain name and does not expect any massive increase in numbers of users and registrants. The number of registrants and users of the domain name will not exceed 1000 in the first year with max. 20% growth every year. The applicant does not intend to be a commercial registry with thousands of registrations per month. The proposed gTLD “.unicorn” should serve mainly to applicant itself, for its promotion and better recognition throughout the business world, and to applicant’s customers and business partners, not to everyday use by infinite and unclosed number of registrants⁄users.
The applicant itself (at its own discretion) will decide whether its business partner or any other subject using Unicorn Universe system should have also SLD under “.unicorn” and for what purpose. The applicant will not allow registration and use of geographical names at second and other levels.
Due to intended purpose of the “.unicorn” gTLD there is no possibility of infringement of any geographic name through registration and use of any SLD operating on gTLD “.unicorn”. 

As we mention in other part of this registration questionnaire, we are planning to outsource the technical operation of gTLD to our partner company Gransy s.r.o. This company is ICANN accredited registrar and is fully prepared for this operation. Our future co-operation is affirmed in the Letter of Confirmation, which is attached to this questionnaire just as reference to the Gransy company.

We would also like to point out that we plan to operate the gLTD for corporate purposes and we do not assume to open registrations to the public or to the other registrars.

The answers for the Technical Questions (Q23 - Q44) are derived from the technical documentation of the Gransy company.
 
Registry is purely EPP based, the only way to perform mutable registry request is using the EPP interface. We use self-developed and tested EPP server, which is in compliance with RFC standards as stated later. Security is enforced by using SSL protocol with mandatory certificate validation, IP address filtering and username⁄password authentication. Such information is exchanged with registrars using offline authentication. EPP server itself is equipped with mechanisms to limit number of registrar request per minute, if the traffic is unbalanced.

We provide DNSSEC capable DNS services on four geographically distinct nameservers. BIND software is used as the server itself and meets RFC standards as well. These nameservers are enough for our planned number of domains and a lot more.

Whois service is running on port 43 as standard Whois server using our own server application. It is highly configurable and for gTLD we use the format stated in Specification 4. Whois requests are limited per source IP address, it is only possible to successfully perform from 10 to 100 requests per minute from single IP address, depending on current server loads.

Web based Whois has the same limitation as the standard port 43 Whois, there is no captcha, but the same per-IP limitation, it is fairly adequate to keep the load stable. Client gets exactly the same information from web Whois as is in standard Whois, however there are added hyperlinks and simple html formatting to make output more readable and accessible.

Since all production servers are doubled, there is virtually no risk of hardware failure, in such case the other machine will handle the requests and the third spare server will be connected. All services run on dedicated servers under two independent and geographically distinct connection providers. When all servers are doubled, one of them is always connected to first provider, and the second to another provider. We are not fully dependent on one particular housing provider and it is possible to recover from full disconnection from one of them, this was carefully tested.

Concerning data safety, database servers are only accessible by our diagnostics servers, whois servers and EPP servers. Only EPP server has full right to modify data there, and EPP server was developed with care for security and robustness. It is not possible for registrars to get information about domains they do not manage. Our diagnostic server also verifies log files and checks the permissions.

All servers are running only the respective services and are protected by firewall.

We are also prepared to provide FTP or SFTP server for zone file dissemination.

Our software is IDN capable and we are prepared to use that feature in the future. At this moment we support Czech alphabet only.

SRS is EPP based, self-developed and well-tested, we were using it for different purpose before and we had enough time to evaluate its function. Its transport layer includes request limiter in case of too high number of requests from some particular registrar. Only certified registrars are allowed to connect, they have to give us their allocated IP address to connect with, their certificate file and have to obtain unique username and password combination to use in EPP login request. Every registrar is also limited to use maximum of four TCP connections at the same time.

DNS availability is 99.9%, and considering our planned number of domains there will not be any problem with stability, all requests are served in less than 100ms. DNS update time is set to 10 minutes. DNSSEC proper resolution is provided by BIND software and configured to do full chain resolution.

EPP server, Whois servers, database servers, backup servers and even diagnostics servers are doubled, so there are two running servers of each type. Additionally, for each service there is one additional backup server, which can replace malfunctioning productive server in case of hardware failure or housing outage. Database tables are synchronized directly using MySQL replication, including the third backup server. There are also two backup servers that save both incremental and full copy of registry data every one hour.

Regarding IPv6, all of our servers and network infrastructure is assigned IPv4 and IPv6 addresses. Registrars can use both protocols for both EPP and Whois services, they will connect to the same interface on the same physical servers. Our DNS system also supports handling of both IPv4 and IPv6 addresses, both types can be specified in EPP host commands.

Maintenance is provided by a team of three technicians who are monitoring the servers, monitor possible performance problems and security issues. Ideally, software is fully automatic and requires no manual maintenance. However it is necessary to monitor its function and resolve possible failures. Development team of two programmers is prepared to fix urgent problems in terms of two working days.
As stated before, the system is prepared for rather less amount of second level domain names. It is expected that the number of registered domains will not exceed 50000, however the system should handle 300000 domain names with no problems. If there will ever be the need to have more, there is no problem in adding additional servers in a few days. System is fully scalable and adding of new hardware will cause no interruption of operation.

Whois servers are available on ports 43 and 80 for standard and web-based Whois.

The biggest concerns about performance lay in SQL database servers. We have two live synchronized MySQL servers, which EPP servers use to get⁄save data and Whois use for getting data. Backups are also made in regular intervals. However, the data structure is well chosen and our measures and tests show, that two servers will be enough even with tens of thousands of domains. In immediate need to get more performance, we could connect the third backup server and extend SRS of new machines as soon as possible.

EPP server uses strict standard protocol, as specified in RFC 5730 (Extensible Provisioning Protocol), RFC 5731 (Domain Name Mapping), RFC 5732 (Host Mapping), RFC 5733 (Contact Mapping), RFC 5734 (Transport over TCP), RFC 3915 (Domain Registry Grace Period Mapping) and RFC 4310 (Domain Name System Security Extensions Mapping).

Server is listening on port 700, SSL encryption required. Number of connections is limited to 4 per registrar. Registrar is provided only to perform command on its own objects⁄domains, it is totally not possible to get information or even change data of other registrars. That is only possible using Whois service.

Brief EPP command summary:
(for further information please refer to RFC standards above, the server is fully compliant, this is just brief specification)


General requests

Hello – get basic information about the registry, and as a side effect is suitable to be used as keep alive request.

Login – required before processing any request specified below, mandatory to specify registrar username and 
password as additional authentication (however, the most important security feature is IP filter and SSL encryption, 
password is the third and last security measure).

Logout – explicitly end current session created by previous Login request. It is not required to call logout, it is automatically called after closing TCP session.

Poll – gets the next message from the register. Such messages contains domain deletion notifies, transfer notice for current domain registrar in case of request or cancel transfer, and transfer notice for new domain registrar in case of approve or reject transfer request. There could be some other messages in the future.

Ack – acknowledge the receipt of the Poll message indentified by its unique ID. It is necessary to acknowledge the messages in order to get next, more recent messages.


Host requests

Create – host objects are representation of the nameservers to be used in domain registrations. If the host is inside our zone, it is necessary to provide IPv4 and optionally IPv6 glue records.

Update – possible to change glue records of the nameserver, or add⁄remove client prohibition statuses.

Delete – removal of the host from the registry, only possible if the host is not used in any existing domain registration.

Info – returns all available information about the host object, particularly host name, glue records and statuses.

Check – if the specified host is or is not registered.


Contact requests

Create – for registering domain names it is necessary first to create contact handles for registrant, admin, tech and billing contacts. Registrar has to choose ID for new contact and fill required fields: name, street, city, postal code, country code, voice, email and optionally org, state⁄province and fax. Authinfo and disclose fields are not used.

Update – change information associated with particular contact ID. It is possible to modify fields specified in Create request. It is also possible to add⁄remove user 
statuses.

Delete – removal of the contact from the registry. It is only possible when the contact is not used as contact in any registered domain name. And be notified, that for archiving purposes the contact will be still internally stored in registry.

Check – just check if specified contact ID is not assigned to existing contact.

Info – get information about contact with specified ID. Returns all information about the contact specified in Create request and additionally returns also the dates and registrar IDs of creation and last modification.


Domain requests

Create – register new domain name. Compulsory to specify contact information for registrant, admin, billing and tech contacts. AuthInfo must be also filled. Nameservers are necessary for domain to be generated into the zone, but not necessarily required for domain registration. For use of DNSSEC please read RFC 4310, this extension is fully supported.

Update – enables registrars to change domain name data, particularly contacts, nameservers, and additionally also authInfo or dnsKeys. As a result there always has to be one contact of each type (registrant, admin, billing and technical).

Update⁄restore – grace period mapping uses restore command to ʹundeleteʹ domain name. It is possible to do so in two weeks after the domain was deleted.

Renew – explicit domain renewal, extends domain registration of specified number of years. It is not possible for the final expirey date to be more than 10 years from the current date.

Transfer – for transferring domain administration between two registrars. It is possible to request or cancel domain name transfer. Current registrar of the domain must confirm the request using approve transfer command. If current registrar rejects the request with reject transfer command, the transfer is not processed. If the transfer is not rejected during 5 days, the transfer is automatically approved.


Delete – explicitly removes domain from the zone and changes status of the domain to pendingDelete and redemption status to redemptionPeriod. The domain will be deleted two weeks after requesting Delete. In these two weeks it is possible to Restore the domain name.

Check – informs registrars if particular domain(s) (it is possible to check up to 10 domains at once) is available for registration, that means domain is not already registered and not reserved. Although the non-error result means that it is valid domain name.

Info – returns information about the domain name – all the fields in Create request and dates and registrar ids of creation, last modification, last transfer and expiration of this domain name.

For Whois service we have implemented our own Whois server application with simple domain, contact, host object and registrar search. Server is RFC 3912 compliant and we tried to make configuration the same as you request in Specification 4, we used that specification for development so our output is exactly the same as specified there. Server itself obtains data directly from registry SQL servers, server application has cache for ten minutes, we want the Whois information to always be up to date.

Request limiter is implemented directly inside the whois server. It limits the number of requests on IP address basis. The limit can vary according to current server load and configuration. We plan to use limit between 10-100 requests per minute.

We are not planning to have publicly available search service, although we probably will enable such searches for registrars.

Currently it is not possible to do partial searches or use wildcards. Only exact matches are possible.


Searches are possible by:

Domain name - to get information such as domain status, admin, billing, technical and registrant contacts, nameservers used to resolve such domain and the creation, last modification and expiry dates, as well as the identification of sponsoring registrar.

Contact handle – contact information for subjects used as registrant, admin, billing or technical contacts, identified by its unique registry ID.

Registrar organisation – contact information of the company responsible for managing the domain names

Nameservers – possible to search by nameserver address (ns1.example.com) or glue IP addresses.

When domain name is first created, it goes directly to ʹokʹ status. In ʹokʹ status registrar can perform all modification requests such as update, renew or delete. Using update request it is possible to set client statuses clientUpdateProhibited, clientTransferProhibited, clientDeleteProhibited or clientRenewProhibited.

When a domain expires – the expiration date passes, the domain goes to autoRenew status for two weeks. This status does not prevent the registrar from performing domain requests, the behaviour is the same as in ʹokʹ status. The meaning of this status is that it is possible to delete the domain without effective billed renewal. After the autoRenew period if there is no delete domain renew is confirmed and the domain has to be paid for.

After performing delete command the domain goes into pendingDelete status, with rgp status ʹredemptionPeriodʹ. This state will last for two weeks. It is possible to restore a domain using restore request (implemented in RGP extended update command). After restoration the domain goes back to ʹokʹ status and is renewed. If it is not restored, the domain goes to pendingDelete status and pendingDelete rgp status and will soon be deleted and available for registration again.

When there is transfer requested, domain is in transferPending status, which prevents the registrar to perform any operations with the domain name. After transfer is approved, auto-approved, cancelled or rejected, domain goes back to ʹokʹ status. Domain transfer will renew domain for one year.

Because of the fact that the domain is intended as a brand based gTLD, new second level domain assignment will be handled at corporate level. Decisions on granting such domains will be based on the business model of our company and will not be made by any 3rd party companies. As such, there is very little chance of abuse, as abuse would primarily impact our company. A corporate board will be established to handle new domain registrations and domains will be assigned in compliance with current business needs.
    
        Orphan glue records will not occur, since all the registered domains will use one set of DNS servers. These servers will be controlled exclusively by our company. Domains used in name server hosts will be permanent and not subjected to any changes. Example:

    ns1.dnscore.unicorn
    ns2.dnscore.unicorn

There will be no 3rd party registry operators, the entire domain will be controlled solely by our company. As of writing, our company has no intention of deploying UDRP or URS these systems are not needed in our gTLD domain, all decisions on granting, revoking and renewing domains are purely business driven and are subjected to our business needs. Sunrise periods and Trademark claims are, again, resolved on corporate level. 

We are going to outsource the technical operation of gTLD to our partner company Gransy s.r.o.. This company is ICANN accredited registrar.
Our future co-operation is affirmed in the Letter of Confirmation, which is attached to this questionnaire just as reference to the Gransy company.
We comply with the following ISO standards: 9001, 27001, 20000, 14001. The copies of certificates are in attachments:

    ʺLetter of Confirmation.pdfʺ
    ʺISO 14001_EN.JPEGʺ
    ʺISO 14001_EN.pdfʺ
     ʺISO 20000_EN.pdfʺ
    ʺISO 20000_EN_USY.pdfʺ
    ʺISO 27001_EN.pdfʺ
    ʺISO 27001_EN_USY.pdfʺ
    ʺISO 9001_EN.pdfʺ

Security testing, in addition to functional and load testing, is one of the three pillars of the entire process of ensuring
software quality. It is a discipline whose aim is to continuously verify the quality of the security system. It focuses, in
particular, on the detection of vulnerabilities that allow an attacker to get illegally to the data through user interface,
respectively to manipulate the system in contrary to its original purpose.
In order to assess the safety parameters of a complex information system is monitoring and analyze the quality of static code without its execution and then the behavior of the code when the application is running.
Basically, these tests are known as static (static application security testing - SAST) and dynamic (dynamic application security testing - DAST) tests. Static tests consist, in particular, of routine review ⁄ control code and static analysis of code. Dynamic tests will be subdivided into whitebox (with knowledge of code ⁄ system structure) and blackbox (without prior knowledge of the system).
Whiteboxis testing and static analysis of the code is performed together and is closely related. The various types of tests are carried out in other phases of software development and different methods are applied to them. Each of them covers a different group of errors and that is why it is necessary to not to neglect one of them, and outputs are mutually correlated.
 
Type of test Goal (types of vulnerabilities discovered):

Code review - Expertise verification of the code in order to discover vulnerabilities as unused pieces of code, code not
related with the business functionality (utilities for developers, possibly backdoors) etc.

Static code analysis - Syntactic and typing errors, hard-coding of definitions of constants, lack of input validation (e.g. use of regular expressions), use of methods and classes generally considered unsafe (obsolete⁄deprecated classes)

Whitebox testing - Vulnerabilities as SQL injection, code injection. Information Leakage and Improper error handling,
insecure direct object reference etc.

Blackbox testing - Cross-Site Scripting, Cross Site Request Forgery, HTTP Response Splitting, parameter tampering, Hidden Field Manipulation, any attempt to use debugging options, Application Buffer Overflow, Cookie Poisoning, SQL Injection, session fixation and others.
Types of vulnerabilities discovered with whitebox and blackbox testing are similar, so there we will execute both types of
tests to reduce the number of false positives and false negatives.
Our security tests can detect errors already during the development and thus significantly reduce the cost of its eradication, but this does not affect the role of penetration tests.
Penetration tests are still needed as they are usually performed on a finished and running system and covers not only the application layer, but also the infrastructure. Our penetration tests are independent (which is not the case whith security testing, which can be performed directly by the development team). That means that penetration tests are still works as the independent audit of overall level of the system security. It can detect also other types of vulnerabilities, e.g. handling of user accounts, securing of the communication channels etc.
So the penetration testing will be supported by Symantec Vulnerability manager for infrastructure vulnerability scanning.