Application Downloaded On: 07 May 2015
String: politie
Application ID: 1-1736-17699
1. Full legal name
Politie Nederland
2. Address of the principal place of business
Zeisterweg 1 - 3984 Odijk The Netherlands
3. Phone number
+31343 534500
4. Fax number
5. If applicable, website or URL
http://www.politie.nl
6(a). Name
Peter de Beijer
6(b). Title
Product Manager Cloud, Big Data and Internet
6(c). Address
6(d). Phone Number
+31 343 534500
6(e). Fax Number
6(f). Email Address
peter.de.beijer@politie.nl
7(a). Name
Hubert Welleman
7(b). Title
New Business Manager
7(c). Address
7(d). Phone Number
+31 26 3525500
7(e). Fax Number
7(f). Email Address
hubert.welleman@sidn.nl
8(a). Legal form of the Applicant
public entity / governmental entity
8(b). State the specific national or other jurisdiction that defines the type of entity identified in 8(a).
Artikel 4.7.a van de politiewet 1993 Nederlands recht / Article 4.7.a of the Dutch Policelaw 1993
8(c). Attach evidence of the applicant's establishment.
Attachments are not displayed on this form.
9(a). If applying company is publicly traded, provide the exchange and symbol.
9(b). If the applying entity is a subsidiary, provide the parent company.
9(c). If the applying entity is a joint venture, list all joint venture partners.
11(a). Name(s) and position(s) of all directors
|
| Dick Heerschop | CIO |
| Koos Veefkind | CTO |
| Marjo Lamers | CFO |
11(b). Name(s) and position(s) of all officers and partners
11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares
11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility
13. Provide the applied-for gTLD string. If an IDN, provide the U-label.
politie
14A. If applying for an IDN, provide the A-label (beginning with "xn--").
14B. If an IDN, provide the meaning, or restatement of the string in English, that is, a description of the literal meaning of the string in the opinion of the applicant.
14C1. If an IDN, provide the language of the label (in English).
14C2. If an IDN, provide the language of the label (as referenced by ISO-639-1).
14D1. If an IDN, provide the script of the label (in English).
14D2. If an IDN, provide the script of the label (as referenced by ISO 15924).
14E. If an IDN, list all code points contained in the U-label according to Unicode form.
15A. If an IDN, upload IDN tables for the proposed registry. An IDN table must include:
- the applied-for gTLD string relevant to the tables,
- the script or language designator (as defined in BCP 47),
- table version number,
- effective date (DD Month YYYY), and
- contact name, email address, and phone number.
Submission of IDN tables in a standards-based format is encouraged.
15B. Describe the process used for development of the IDN tables submitted, including consultations and sources used.
15C. List any variants to the applied-for gTLD string according to the relevant IDN tables.
16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string. If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.
As far as the applicant is aware of there are no known operational or rendering problems with regard to the .TLD-string
17. OPTIONAL.
Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).
18A. Describe the mission/purpose of your proposed gTLD.
With the commissioning of the National Police, a new era for policing has started in the Netherlands. The formation of a national police force offers opportunities for improvement and innovation. The ambitions and expectations are high. The police provide a recognizable order in society and is the focus of social developments and public attention. The trust of citizens and administrators in good police work is of great significance because it is an important indicator for the acceptance of the authority and the actions of the police.
The police are constantly faced with new security issues. New tasks, such as the surveillance of the Internet and processing of images of citizens are being shaped into a valued service component of the police portfolio of tasks.
To increase public safety in the Netherlands, regional and national units of the National Police must work together very closely. This cooperation is dependent on information- and IT-facilities to which the Police have access.
In the cooperation with private and public partners and citizens, information exchange is vital. Police and partners are strongly dependent on each otherʹs sharing of information and on a common approach to safety issues within society. The police and partner organizations have a clear need to significantly improve information exchange.
The Internet is seen as an important tool to enhance both the internal cooperation within the Police and the external cooperation with citizens and partner organizations as far as possible.
The National Police as an organization already offers its services via the Internet. This includes: a national and global portal for the National Police, in interaction with citizens, businesses and other national and international agencies and police organizations.
The expectation is that in the near future all citizen interactions with the Police, if desired, can be performed over the Internet, or that at least the first steps will have been achieved to make this possible. Searching for (informative-) information, a declaration - or logging a report and being able to directly communicate with a Police officer in the neighborhood, are just some of the basic functionalities expected in this context.
In addition, an Internet portal for the National Police will offer opportunities for partnerships with local stakeholders and provide a platform for local partners to share information concerning a particular incident or a structural problem within a neighborhood.
Shielded environments that employees themselves can create and manage, provide the opportunity to exchange information and to collaborate with third parties, and between police officers themselves.
Police officers may very well soon be using the Internet to perform their primary duties. The information management of the police will be accessible via the Internet. Furthermore, police officers will be trainable through the Internet and be able to mobilize their expertise via the Internet. The police are then able to present real time information processing and relay real-time information effectively to deploy and capitalize on the core business of maintaining law and order.
In summary, the National Police organization expects to achieve the following aspects with the availability on the toplevel domain ʺ.politieʺ:
• It will emphasize the role of the National Police in the current information society.
• It offers the possibility to take responsibility for the availability and safer use of Internet technology and services.
• It ensures the availability and future stability of an internal service offering and of service delivery to citizens, businesses and partner organizations.
• By taking the responsibility for the issuance of subdomains, the integrity of the police will be better guaranteed. This contributes to the visibility of the Police on the internet and provides an improved reputation.
• Domain names in which the word ʹpolitieʹ occurs but not being a subdomain of ʺ.politieʺ are instantly recognizable to citizens, businesses and partner organizations, as not being part of the National Police.
Through the toplevel domain ʺ.politieʺ the National Police positions itself to society as a transparent organization contributing to the improvement of the mutual contact between society and the Police.
18B. How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?
By claiming the namespace “.politie” the Dutch Police is the authority within the namespace. This claim provides the Dutch Police the trustworthy image which fits the organisation and its role in society. Potential users of the namespace, which can only be from inside the organisation or peer-groups, can make use of this trustworthy image. By claiming the namespace “.politie” the Dutch Police identifies itself as one organization acting on the national and international levels. It provides the Dutch Police a dominant position in their fight against cyber crime.
It further provides trust for the internet user experience. Domain names in which the word ʹpolitieʹ occurs but not being a subdomain of ʺ.politieʺ are instantly recognizable to citizens, businesses and partner organizations, as not being part of the National Police.
18C. What operating rules will you adopt to eliminate or minimize social costs (e.g., time or financial resource costs, as well as various types of consumer vulnerabilities)? What other steps will you take to minimize negative consequences/costs imposed upon consumers?
Since the “.politie” TLD will only register domains for its own usage and with only the police as the registrant there will no ‘social costs’ whatsoever involved in the operation of “.politie” TLD. Instead of that, the fact that all internet communications from the Dutch Police will be under the “.politie” domain will enhances the trust for all internet users that these communications are for 100% sure to actual come from the Dutch police and reach the Dutch police.
To be complete:
- There will be no multiple applications for any particular domain name as all registrations will be done in the name of a single party: the Dutch Police;
- There will not be any cost benefits for registrants as there will be no other registrations than by the Dutch Police;
- The Dutch Police will, as it is obliged to, work with an ICANN registrar and also allow all ICANN registrars to sign its standard Registry Registrar Agreement. It is expected however that the Dutch Police in its role as a registrant will register all domains through a single registrar. As the Dutch Police will be the sole registrant of domains under “.politie”, and in the end will cover all the costs for as well the running of the registry and the registration fees to be paid as the registrant, the registry plans to register and publish the domains under “.politie” without any charge to the registrar. The registrar will as usual add its mark up towards the registrant. Given this situation not any price in- or decreases are foreseen.
19. Is the application for a community-based TLD?
No
20A. Provide the name and full description of the community that the applicant is committing to serve. In the event that this application is included in a community priority evaluation, it will be scored based on the community identified in response to this question. The name of the community does not have to be formally adopted for the application to be designated as community-based.
20B. Explain the applicant’s relationship to the community identified in 20(a).
20C. Provide a description of the community-based purpose of the applied-for gTLD.
20D. Explain the relationship between the applied- for gTLD string and the community identified in 20(a).
20E. Provide a complete description of the applicant’s intended registration policies in support of the community-based purpose of the applied-for gTLD. Policies and enforcement mechanisms are expected to constitute a coherent set.
20F. Attach any written endorsements for the application from established institutions representative of the community identified in 20(a). An applicant may submit written endorsements by multiple institutions, if relevant to the community.
21A. Is the application for a geographic name?
No
22. Describe proposed measures for protection of geographic names at the second and other levels in the applied-for gTLD. This should include any applicable rules and procedures for reservation and/or release of such names.
Measures for protection of geographic names in the .politie top-level are being taken for Country and territory names (conform Specification 5 in the Base Agreement).
Registry Operator will exclude all country and territory names from registration on the second level, the only level in which registrations will be offered by Registry Operator, specified in Specification 5 of the Base Agreement:
5.1. the short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉;
5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;.
The names on these lists will be shown in the registries’ Whois with status ‘excluded’.
Registration of these names will be limited during the entire lifetime of the .politie top level domain to registrants who are designated by the government or public authority of the concerned country or territory. Authentication of representation is based on the existing methodology developed for release of country names in the .INFO top-level domain.
A government or public authority wanting to register their country or territory name under .politie has to get an authentication by GAC Secretariat. This authentication and the name of the designated beneficiary need to be transferred to Registry Operator, who will issue an authorisation number to the designated beneficiary in the country concerned. The domain name can be registered through an accredited registrar with the designated beneficiary as the registrant, using the authorisation number.
The registrant of these domain names can only be changed after registration if the new designated registrant also has been authenticated by GAC Secretariat.
23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
The following registry services are customary services offered by a registry operator:
- Receipt of data from registrars concerning registration of domain names and name servers.
- Dissemination of TLD zone files.
- Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
- Internationalized Domain Names, where offered.
- DNS Security Extensions (DNSSEC). The applicant must describe whether any of
these registry services are intended to be offered in a manner unique to the TLD.
Additional proposed registry services that are unique to the registry must also be described.
All core registry services for .politie will be provided by .politie’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.
All infrastructure, systems, procedures and processes used for supporting registry services of .politie will be based on SIDN’s infrastructure, systems, procedures and processes for supporting registry services for .NL.
SIDN deploys a fully redundant infrastructure. All systems supporting registry services (with the exception of the public DNS services) are located at two geographically separated production sites that together form one logical network. The public name servers are geographically spread with a gravitational centre in The Netherlands. This suits the need of the .politie top level, which is also aimed at the Dutch community.
SIDN is an ISO 27001 certified organization. Procedures and processes related to registry services at SIDN are based on the principles of this standard.
23.1 Domain Registration Services
Domain Registration Services are provided to all .politie Accredited Registrars through the Shared Registration System. As explained in the business model of .politie there is probably only one Registrar, since this is a single registrant TLD.
The SRS for .politie is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web-interface. Both interfaces are available to all accredited registrars and offer the same functionality. Both interfaces are available through IPv6 and the SRS supports IPv6 AAAA Resource Records in all relevant information fields.
The SRS is compliant with all EPP RFC’s (3735, 3915, 5730, 5731, 5732, 5733, 5734 and 5910) and performs well within the ranges as specified by the SLA Matrix set by ICANN in Specification 10 to the Base Agreement.
Registration transactions for domain names eligible for registration (i.e. domain names that are not excluded or reserved )are handled fully automated by the SRS. Registration transactions are:
- create, update, renew, transfer and deletion of a domain name;
- acknowledgement or refusal of a transfer request;
- restore of a domain name in redemption grace period;
- create, update and deletion of a contact;
- create, update and deletion of a name server.
Upon expiration of a domain name, the registry will automatically renew the registration with one year . If the domain name is deleted or successfully transferred to another registrar within 45 days of this auto-renewal, the charge made for the auto-renewal will be credited.
Deleted domain names are quarantined in a Redemption Grace Period for 40 days before becoming available for registration anew.
The SRS accepts DNSKEYs for signed delegated domain names and the DS record for the child zone will be computed by the registry.
Not all registration transactions are always allowed. For a full description, please see the answer provided to Evaluation Question #27 ‘Registration Life Cycle’.
Excluded domain names will be listed in the registry agreement and honour ICANN’s requirements regarding reserved domain names. Domain names excluded from registration are not in the .politie zone file, have a Whois status ʹexcludedʹ and cannot be registered by anyone. An EPP «create» command will be rejected by the shared registration system.
Reserved domain names can only be registered by a designated or authorized registrant. Policies and procedures regarding the dissemination of reserved domain names will be provided in the registry agreement and published on the registry website for .politie.
After registration, updates of the registrant are blocked in the registration system. An EPP «create», «update» or «transfer» command will be manually reviewed by .politie registry operator and has to be authorized before it will be processed by the registration system.
23.2 DNS and DNSSEC Services
At launch, .politie will be set up with 2 geographically separated name servers (clusters) and an Anycast name server. The Anycast name server will have a minimum of 5 nodes. If and when demand rises above SIDN’s capacity baseline threshold, additional name servers or nodes will be introduced.
All public name servers for .politie are reachable via IPv4 and IPv6 addresses.
The zone file for .politie will be signed with DNSSEC and checked for integrity and accuracy before being published. Zone file generation and publication will be done every half hour, matching the requirements specified in Specification 10 of the Base Agreement. NSEC is used for authenticated denial of existence.
SIDN requires registrants to obey the rules set out in a ‘technical requirements document’ that defines minimal technical requirements for the registration (and delegation) of domain names (in the DNS). Most of the technical requirements are enforced by technical controls in the shared registration system. Other requirements are checked once the domain is delegated, by means of an in-house developed tool called the ‘DNS crawler’. This tool produces monthly feedback on the DNS quality of the domain names registered to registrars. It also reports violations of the technical requirements and DNS errors to registrars and to our compliance monitoring team.
A publicly available name server check will be provided on the website of .politie. This name server check is identical to SIDN’s name server check (https:⁄⁄www.sidn.nl⁄en⁄about-nl⁄registering-a-domain-name⁄dns-check⁄) and provides DNS and DNSSEC information about both delegated and undelegated domain names.
23.3 Registration Information Services
.politie’s WHOIS will be offered publicly through a website and as a command-line protocol over port 43.
The HTML version of the public WHOIS will be accessible through http:⁄⁄whois.nic.politie and will be protected by a Captcha mechanism. The output of the WHOIS service on port 43 is text based (ASCII). Every line is terminated with CRLF as is specified by RFC3912. Besides the standard port-43 WHOIS, we also support a HTML-based WHOIS and an XML-based WHOIS. The WHOIS data is updated in real-time.
Additionally, an ‘IS’ service will be provided for retrieving domain registration statuses. This is a domain availability service, which only shows the status of a domain name. This function could be provided by IRIS⁄CRISP⁄DCHK, but those standards are not commonly used or known.
Accredited Registrars also have access to an XML-based WHOIS, which is partly based on the IRIS specifications (RFC3982 DREG). This WHOIS is only available to accredited registrars and shows full registration information. A free client code is offered through Perl CPAN (Net::Whois::SIDN). The data returned is in UTF-8 format, to support international characters.
Additionally, registrars can retrieve registration information through the EPP interface of the SRS.
SIDN will comply with new standards if and when they are introduced, for example standards based on the results achieved by the IETF WEIRDS group .
Developments in the area of RESTful WHOIS services are studied and our technical advisors work closely with the IETF (IETF WEIRDS WG) community to get this to a standard. When a standard for RESTful WHOIS arises, it will be implemented on IPv4 and IPv6.
.politie will further provide Zone File Access to the public and Bulk Registration Data Access to ICANN entirely in line with the requirements as specified in Specification 4 to the Base Agreement
The .politie registry will provide periodic reporting to ICANN as specified in the Base Agreement and Specifications.
Registrars will receive monthly reports regarding registration transactions (also used as a specification to billing) and feedback on the DNS quality of the registered domain names (through the output from the DNS Crawler).
24. Shared Registration System (SRS) Performance:
describe
- the plan for operation of a robust and reliable SRS. SRS is a critical registry function for enabling multiple registrars to provide domain name registration services in the TLD. SRS must include
the EPP interface to the registry, as well as any other interfaces intended to be provided, if they are critical to the functioning of the registry. Please refer to
the requirements in Specification 6 (section 1.2) and Specification 10 (SLA Matrix) attached to the Registry Agreement; and
• resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel
roles allocated to this area).
A complete answer should include, but is not limited to: - A high-level SRS system description;
- Representative network diagram(s);
- Number of servers;
- Description of interconnectivity with other registry systems;
- Frequency of synchronization between servers; and
- Synchronization scheme (e.g., hot standby, cold standby).
24 SRS Performance
All core registry services for .politie will be provided by .polities’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.
The Shared Registration System for .politie is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.
Access to the SRS for both interfaces is restricted to registrars through a username and password and connections are only allowed for registered networks (IP-whitelisting). The web interface is secured by HTTPS. The EPP interface uses TLS for encryption of the transport layer.
Both interfaces are available through IPv6 and the SRS supports IPv6 AAAA Resource Records in all relevant information fields.
The EPP interface is based on the following standards:
- Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) – RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt),
- Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
- Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
- Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
- Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
- Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
- Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)
The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
- After being idle for 10 minutes;
- After being open for 24 consecutive hours;
- Upon receiving a ‘logout’ command.
Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.
For more information regarding EPP, please see the answer provided to Evaluation Question #25 ‘EPP’.
The Shared Registry System is an in-house developed system. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see the answers provided to Evaluation Question #30 ‘Security Policy’ for more details).
Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q24-Tuvit’).
SIDN deploys a fully redundant infrastructure. All systems supporting registry services (with the exception of the public DNS services) are located at two geographically separated production sites that together form one logical network.
Both data centres hosting the production locations are certified and offer high quality security and support services. For a more detailed description, please see the answers provided to Evaluation Question #34 ‘Geographic Diversity’.
Contracts with both data centre providers are available and added as an attachment to Evaluation Question #39 ‘Registry Continuity’.
Although these locations are marked as ‘primary’ and ‘secondary’, there is no active⁄passive location setup. Both locations provide active services and have accurate (mirrored) data. All registration data in use by registry services is maintained in a database that is synchronized over both production locations. At both locations an additional standby database is present. This makes it possible to switch between locations without loss of data for committed transactions. Both production sites have active systems for all applications needed to provide SRS and WHOIS-services and the hidden primary name server. With this setup, the Recovery Point Objective for registry services is negligible.
Testing for recovery of services is done at least once a year. During the last test SIDN performed, the recovery time for all registry services was less than 10 minutes. This is far below the required Recovery Time Objective of 4 hours.
Both production locations are connected through a Dense Wavelength Division Multiplexing (DWDM) based dark fibre ring, owned and operated by SIDN. This fibre ring is designed so that fibres never share the same physical path or the same duct. This setup provides the locations with active connections, even in the event of a fibre cut. Connectivity to the internet is also set up redundantly, through multiple connections and via different network operators, both commercial and non-commercial. These connections are terminated on separate routers and geographically separated locations. Furthermore all network equipment is fully redundant. This applies to routers, switches, firewalls and load balancers and even network interface cards in a number of servers (by means of link aggregation aka bonding or ‘NIC teaming’).
Bottlenecks in the systems-design and –infrastructure are avoided by making sure that there is always a surplus in capacity, calculated over peak-times and monitored on a constant basis. This is handled by the ITIL ‘capacity management process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for more information).
Our Test Department conducts load- and performance tests regularly on software that is developed or in use, in order to detect issues early on. The standards for these tests are set quite high. Soft- and hardware will not pass the testing, if it is not able to deal with multiple times the load that is expected to have under predicted peak-conditions. Trend analysis is performed on all systems to support these predictions.
In the exceptional event of needing to handle unusual large amounts of traffic, systems for traffic-shaping are present. Traffic-shaping provides the abilities to cut off or limit access to specific abusive users, while keeping the services available for others.
Diagrams depicting SRS systems are enclosed in the attachment ‘Q24-SRSdiagrams’ and include:
- Production location diagram ⁄ access layer
- Registry Application Server Diagram
- Registry Services Systems
The SRS is based on diskless Linux systems, with separate storage servers containing the file systems. Management of the database file systems on the storage layer is done by Oracle Enterprise Manager⁄Grid Control (http:⁄⁄www.oracle.com⁄us⁄products⁄enterprise-manager⁄index.html). One of both locations runs the primary database. All mutations on the primary database are directly shipped to all standby databases. Every transaction that is committed on the primary database is secured on the standby database. Therefore no committed data can ever be lost in a disaster scenario where the primary database gets lost.
Both production locations contain additional standby databases, configured with fast-start failover, available for production. One standby database is used as the current standby database for production; the other one is used for cloning of a production database in order to investigate incidents that require a database with production data in it. In case of a server malfunction, it’s easy to switch over to a standby database. However, this is no resolution for data corruption. Therefor a daily backup is made of the production databases. This backup is copied to the central backup server and put on tape.
Database replication puts high demands on network latency and packet-loss. The dark fibre ring and the selection of the locations for our data centres allow for extremely short round-trip times, often less than 1 ms and generally not above 5 ms. Packet-loss baselines are set to 0% for ‘normal’ operations and cannot exceed 1%. Exceeding of this threshold leads to closer investigation via the ‘Incident Management Process’ (see answers provided to Evaluation Question #30 ‘Security Policy’ for details on this process).
Monitoring of the connections to the public internet depend on network-distances and show round-trip times well below 300 ms in general. Packet-loss for public internet connections is very low as well, way below 10%, due to carefully selected network-operators and tight monitoring.
SIDN is researching cost-efficient alternatives for the current Oracle database management system setup. Requirements for any alternative solution include matching of all functionalities and service levels for database management and reporting capabilities as described in the answers to the Evaluation Questions. If a feasible solution is found and tested, it will be implemented for .politie’s registry services. Details of such implementation will be available to ICANN for evaluation and testing before implementation.
Currently, SIDN operates SRS services for .NL that are well in range of the SLA’s described in Specification 10 of the Base Agreement. Measurements based upon the definitions in this Specification show the following performance for current SRS services:
EPP Service availability
- SL SIDN: 99,955% (Q4 2011)
- SLR Specification 10: 〈= 864 min of downtime (˜ 98%)
EPP session command RTT
- SL SIDN: 〈= 360 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands
EPP query command RTT
- SL SIDN: 〈= 350 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 2000 ms, for at least 90% of the commands
EPP transform command RTT
- SL SIDN: 〈= 750 ms, for at least 90% of the commands
- SLR Specification 10: 〈= 4000 ms, for at least 90% of the commands
Performance for SRS services for .politie will be in line with current performances for .NL.
Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .politie SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .politie the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.
SIDN therefore has all necessary resources on hand to provide all services described in this answer.
25. Extensible Provisioning Protocol (EPP): provide a detailed description of the interface with registrars, including how the applicant will comply with EPP in RFCs 3735 (if applicable), and 5730-5734.
If intending to provide proprietary EPP extensions, provide documentation consistent with RFC 3735, including the EPP templates and schemas that will be used.
Describe resourcing plans (number and description of personnel roles allocated to this area).
A complete answer is expected to be no more than 5 pages. If there are proprietary EPP extensions, a complete answer is also expected to be no more than 5 pages per EPP extension.
25 EPP
All core registry services for .politie will be provided by .politie’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.
The Shared Registration System for .politie is cloned from SIDN’s registration system for .NL and offers an EPP-interface and a web interface. Both interfaces are available to all accredited registrars and offer the same functionality.
The EPP interface is based on the following standards:
- Guidelines for Extending the Extensible Provisioning Protocol (EPP) - RFC3735 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3735.txt),
- Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP) – RFC 3915 (http:⁄⁄www.ietf.org⁄rfc⁄rfc3915.txt),
- Extensible Provisioning Protocol (EPP) - RFC5730 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5730.txt),
- Extensible Provisioning Protocol (EPP) Domain Name Mapping - RFC5731 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5731.txt),
- Extensible Provisioning Protocol (EPP) Host Mapping - RFC5732 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5732.txt),
- Extensible Provisioning Protocol (EPP) Contact Mapping - RFC5733 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5733.txt),
- Extensible Provisioning Protocol (EPP) Transport over TCP - RFC5734 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5734.txt) and
- Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) - RFC5910 (http:⁄⁄www.ietf.org⁄rfc⁄rfc5910.txt)
The EPP interface maximizes the amount of simultaneous connections per registrar to eight. Only SIDN-authorized networks⁄interfaces can connect to the EPP interface. Connections will be closed:
- After being idle for 10 minutes;
- After being open for 24 consecutive hours;
- Upon receiving a ‘logout’ command.
Per session, multiple XML forms may be sent (containing one command per form, pipelining not possible). EPP commands are processed by the SRS in the sequence in which they are received. All commands are executed immediately and an immediate response containing the execution result is returned.
25.1 EPP objects and commands
EPP is used to create or edit three types of objects: domain names, contact persons and name servers. The object domain name refers to existing contact persons (registrant, administrative contact and technical contact) and name servers.
The SRS supports the following EPP commands:
Sessions
Hello⁄greeting
Login
Logout
Poll
Domain names
Domain check
Domain info
Domain create
Domain update
Domain delete
Domain transfer
Domain renew
Contact persons
Contact check
Contact info
Contact create
Contact update
Contact delete
Name servers
Host check
Host info
Host create
Host update
Host delete
25.2 Configuration Settings
clTRID
The clTRID element can be used with all commands in order to link the registrars’ identification to the command. When responding to this command, SRS sends this value back. The value for this element is freeform and should be unique. No checking is performed on this field by the registry.
Domain object
- Domain.ns: The ‘hostObj’ implementation is chosen for authoritative name servers for a domain name. The number of authoritative name servers has been limited to a maximum of thirteen but can be left empty. A domain should have a minimum of 2 name servers before the domain name is published in the zone.
- Domain.registrant: The registrant attribute is mandatory.
- Domain.contact: Only the ‘admin’ and ‘tech’ contact person types are supported and the following additional rules apply:
- a minimum of one and a maximum of one ‘admin’ must be submitted for a domain name
- a minimum of one ‘tech’ must be submitted for a domain name
- Domain.authInfo: The authInfo attribute is only used in the transfer procedure. Consequently, this attribute is only used in the Domain transfer (op=“request”) command and it is also issued in the response message to the Domain info command and in the response message after a successful transfer.
Note: this attribute is mandatory in the Domain.create command in EPP and will be filled with a value generated automatically by the SRS (see ‘Proprietary EPP Extension’).
- Domain.status: The following contact domain statuses are not used in the SRS:
- PendingUpdate
- PendingRenew
- PendingRestore
Contact object
- Contact.name: In the EPP standards, the name is part of the «postalInfo» group. Both localized (unrestricted UTF-8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for a name in order to avoid a situation where different names for the contact person are included in both formats.
- Contact.org: In the EPP standards, this field is reserved for the name of the organization. In the SRS implementation, however, it has been decided to use this field for the name of the department with which the contact person is associated (affiliated). The proprietary EPP extension contains two fields to describe legal registration information of companies (see ‘proprietary EPP extension’ below) and the organizations’ name is to be provided in Contact.name.
- In the EPP standards, the «org» attribute is part of the «postalInfo» group. Both localized (unrestricted UTF 8) or internationalized (a subset of UTF-8 that can be represented in the 7-bit US-ASCII character set) forms may be used for this group. The SRS implementation only allows one format (unrestricted UTF-8) for the name in order to avoid a situation where different names are included in both formats.
- Contact.status: The following contact person statuses are not used in the SRS:
- clientDeleteProhibited
- clientTransferProhibited
- clientUpdateProhibited
- pendingCreate
- pendingDelete
- pendingTransfer
- serverDeleteProhibited
- serverTransferProhibited
- serverUpdateProhibited
Consequently, the responsible registrar is also unable to set ‘client’ statuses.
- Contact.postalinfo: A maximum of 1 is allowed. Only type=ʺlocʺ is supported.
- Contact.street: A maximum of 1 is allowed. A PO Box may not be entered in the first street tag.
- Contact.sp: The optional state⁄province attribute is not implemented.
- Contact.pc: This field is mandatory if country code “NL” is used. In this case, the postal code must always start with four digits and end in two letters (regular expression: ʺ[0-9]{4}[A-Z]{2}ʺ).
- Contact.voice: The telephone number is mandatory.
- Contact.trDate: This attribute is not implemented, since contact persons cannot be transferred in the SRS.
- Contact.authInfo: This attribute is not implemented, since contact persons cannot be transferred in the SRS.
Note: this attribute is mandatory in the Contact create command in EPP and will be filled with a value generated automatically by the SRS.
- Contact.disclose: This attribute is not implemented. Only the sponsoring client (responsible registrar) and the server (SIDN) may view the information for a contact person in the SRS.
- Contact.id: The submitted value of this attribute will be ignored in the SRS and the server will automatically generate an ID (= handle). The handle that is generated by SIDN follows the format XXX999999-YYYYY (regular expression: [A-Z]{3}[0-9]{6}[-][A-Z0-9]{5}). The first part of this handle is used to identify the contact. The second part is used to identify the maintaining registrar. If a domain name is transferred, all related contacts are copied to a new contact maintained by the gaining registrar. In that case, the contact-identifying part of the handle is unchanged and the registrar-identifying part is updated to reflect the new maintainer.
Host object
- Host.status: The following name server statuses are not used in the SRS:
- clientDeleteProhibited
- clientUpdateProhibited
- serverDeleteProhibited
- serverUpdateProhibited
- pendingCreate
- pendingDelete
- pendingTransfer
Consequently, the responsible registrar is also unable to set «client» statuses.
- Host.name: The name for a name server cannot be updated in the SRS. Consequently, the chg attribute is not implemented in the Host update command.
- Host.IP-adres: The number of IP addresses has been limited to a maximum of ten.
- secDNS.keyData: The Key Data Interface is chosen, implementing ‘secDNS.keyData’. As a consequence secDNS.dsData is not supported.
- secDNS.maxSigLife: This optional attribute is not implemented.
25.3 Proprietary EPP extension
SIDN provides a proprietary EPP extension (compliant with RFC 3735). The extension scheme is provided in the attachment ‘Q25-sidn-ext-epp-1.0.xsd’.
Since the proprietary extension is also used for registration of other TLD’s, including .NL domains, there may some elements present that are only in use for those TLD’s and will be ignored for .politie. At the moment of writing, this is the case for elements containing the field ‘optOut’ (used for shielding privacy sensitive information in the .NL-Whois) and fields in the element ‘trnData’ (used in messages regarding escalation of transfers through the registry for .NL). Since .politie is aimed at the same audience as .NL, we strive for an alignment in registry services and EPP-commands, however, if various policies lead to an unclear extension, we will decide to split the xsd to support only .politie functionality.
This extension contains elements for the legal registration of companies in The Netherlands. This information specific to the Dutch market and relevant to the .politie TLD.
The proprietary extension also contains a status element ‘limited’. This status is a more fine-grained setting of the ‘serverProhibited’ status, allowing for:
- Prohibition of changes to parts of an object (e.g. a domain object can be updated, but the registrant cannot be changed);
- Authorization of commands before execution by Registry Operator (a command is validated before being accepted or denied).
This status is used for controlling the registrant of specific reserved domains where a validated registrant may not be changed, but contact details for the registrant may be updated as needed by the registrar.
The EPP interface will show if the status ‘limited’ is present for objects and indicates that a command for this object will be rejected or pended. It doesn’t show the various types of this status used internally by the registry and the specific consequences involved.
To facilitate various specific TLD policies for transferring domain names (including .NL, where transfer policy compliancy is supported by escalation procedures at the registry), the SRS generates unique values for the authInfo attribute upon creation of the object. These values are reset and generated anew when the following transactions occur: transfer, registrant update and bulk transfer. A reset and regeneration of this value can be requested by the registrar-of-record at any time through the regular support channels.
Proprietary extension attributes and elements
- Domain info
Extension for status limited in response message
- Domain cancelDelete
Message extension used for .NL
- Domain transfer (op = ʺrequestʺ)
Extension for authInfo-value (“pw”) in response message
- Contact info
Extension for legal form, registration number and limited in response message
- Contact create
Extension for legal form and registration number
- Contact update
Extension for legal form and registration number
- Host info
Extension for limited in response message
- All
Extension for message with field, code and message in response messages
25.4 Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .politie SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .politie the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.
Next to the Development Team (10 staff responsible for the software development at SIDN), SIDN has a dedicated Test Team of 4 staff. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing.
SIDN therefore has all necessary resources on hand to provide all services described in this answer.
26. Whois: describe
- how the applicant will comply with Whois specifications for data objects, bulk access, and lookups as defined in Specifications 4 and 10 to the Registry Agreement;
- how the Applicant's Whois service will comply with RFC 3912; and
- resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
A complete answer should include, but is not limited to:
- A high-level Whois system description;
- Relevant network diagram(s);
- IT and infrastructure resources (e.g., servers, switches, routers and other components);
- Description of interconnectivity with other registry systems; and
Frequency of synchronization between servers.
To be eligible for a score of 2, answers must also include:
- Provision for Searchable Whois capabilities; and
- A description of potential forms of abuse of this feature, how these risks will be mitigated, and the basis for these descriptions
A complete answer is expected to be no more than 5 pages.
26 Whois
All core registry services for .politie will be provided by .politie’s back end provider SIDN. SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD.
SIDN acknowledges that Whois services are a good and proven way of disseminating information about domain name registrations and are therefore an integral part of the registry services.
SIDN has relevant experience in offering Whois services. The zone file for .NL is not publically accessible in full, a side effect of which is the emergence of a significant strain on the Whois services for .NL. Whois services for .politie will be offered through the same technical infrastructure and based upon similar processes and functionalities as Whois for .NL.
.politie’s Whois will be offered publicly through a website and as a command-line protocol over port 43. Additionally, an ‘IS’ service will be provided for retrieving domain registration statuses. Accredited Registrars also have access to an XML-based Whois (and can retrieve registration information through the EPP interface of the SRS).
.politie will further provide Zone File Access to the public and Bulk Registration Data Access to ICANN entirely in line with the requirements as specified in Specification 4 to the Base Agreement.
26.1 Whois for .politie
The offered Whois service is RFC3912 compliant.
Web-based
The HTML version of the public Whois is accessible through http:⁄⁄whois.nic.politie and is protected by a Captcha mechanism.
Port 43
The output of the Whois service on port 43 is text based (ASCII). Every line is terminated with CRLF as is specified by RFC3912. Besides the standard port-43 Whois, we also support a HTML-based Whois and an XML-based Whois. The Whois data is updated in real-time.
IS function
As many other registries, SIDN offers a service within the Whois, called the ‘IS’ function. This is a domain availability service, which only shows the status of a domain name. This function could be provided by IRIS⁄CRISP⁄DCHK, but those standards are not commonly used or known.
SIDN will comply with new standards if and when they are introduced, for example standards based on the results achieved by the IETF WEIRDS group. Developments in the area of RESTful Whois services are studied and our technical advisors work closely with the IETF (IETF WEIRDS WG) community to get this to a standard. When a standard for RESTful Whois arises, it will be implemented on IPv4 and IPv6.
XML-based
SIDN offers a proprietary XML-based Whois, which is partly based on the IRIS specifications (RFC3982 DREG). This Whois is only available to accredited registrars and shows full registration information. A free client code is offered through Perl CPAN (Net::Whois::SIDN). The data returned is in UTF-8 format, to support international characters.
26.2 Data and Output
The data presented by the public Whois of .politie will be compliant with Specification 4 of the Base Agreement. EPP standards RFC5730-5734 are followed regarding data format rules, ensuring a uniform response over different interfaces.
26.3 Conditions of use
Use of Whois is subject to the ‘Whois Terms and Conditions of Use’, stating the following conditions:
Information is made available through the Whois service for the following purposes:
- To enable technical problems associated with the working of the Internet to be resolved.
- To facilitate the process of applying to register new domain names.
- To help to protect intellectual property rights.
- To help to prevent and combat illegal and harmful Internet content.
A. Information obtained using the Whois service may be used only for the legitimate purposes described above and in accordance with Dutch privacy legislation. Under no circumstances may such information be used or allowed to be used:
1. to facilitate the dissemination of solicited or unsolicited commercial or advertising material, by post, e-mail, telephone or otherwise; or
2. in the context of bulk automated processes that make use of or query any SIDN computer system.
B. Without SIDN’s explicit written permission, information obtained from the Whois service may not be compiled, recorded, duplicated (which here includes stored in an automated retrieval system) and⁄or published by printing, photocopying or any other means.
C. SIDN reserves the right to restrict use of and access to the Whois service in the interest of operational stability.
D. SIDN reserves the right to restrict or block use of and access to the Whois service for any party that contravenes these conditions.
E. SIDN may revise these conditions at any time.
SIDN does not guarantee the accuracy of the information made available via the Whois service. All intellectual property rights and database rights to the Whois database and the register from which that database is derived are held by SIDN.
26.4 Performance specifications
Currently, SIDN operates Whois services for .NL that are well in range of the SLA’s described in Specification 10 of the Base Agreement. Measurements based upon the definitions in this Specification show the following performance for current Whois services:
RDDS availability
- SL SIDN: 99,4% uptime
- SLR Specification 10: 〈= 864 min of downtime (˜ 98%)
RDDS query RTT
- SL SIDN: 〈= 50 ms, for at least 95% of the queries
- SLR Specification 10: 〈= 2000 ms, for at least 95% of the queries
RDDS update time
- SL SIDN: = 5 min for at least 95% of the probes
- SLR Specification 10: 〈= 60 min, for at least 95% of the probes
Performance for Whois services for .politie will be in line with current performances for .NL.
The following measures are taken to prevent abusive use of the Whois service:
- A rate limitation of 20 requests per second per client, with a maximum of 100 requests per second overall is set on the port-43, and XML-based Whois;
- A rate limitation of 20 requests per second per client, with a maximum of 500 requests per second overall is set for the IS function;
- The web-based Whois is protected with a Captcha mechanism.
26.5 Network, infrastructure and management
Whois services are accessible through redundant interfaces. There are multiple instances of the Whois services, located in protected VLAN’s in two geographically dispersed data centres in the Netherlands. These two data centres are mirrored production sites. If one location fails or is unreachable, the other location automatically takes over. Access to the Whois service is separated from the Internet through firewalls and load balancers.
The Whois service will consist of two Java based Application Servers. Two F5 Local-Traffic Managers (LTM’s) will balance the traffic to these two Whois servers. When demand rises to the Whois service, more servers can be added to the service. The LTM will provide a virtual service, to which servers are added or deleted when necessary. A minimum of downtime is ensured for upgrading the Whois service (e.g. due to changing or adding functionality). Traffic shaping is also done by the LTM’s. Two firewalls will deliver a security layer (as a first line of defence) on the Whois service.
See attachment ‘Q26-Whois_Architecture’ for a depiction of the Whois infrastructure.
The F5 LTM’s and the firewalls are shared with services for .NL. This also applies to the IT infrastructure, which provides the interoperability between the two data centres for production and SIDN’s office location as the overall command and control location. The infrastructure provides a transparent Layer 2 over 10Gbps paths over dark fibre between all locations. The highest throughput possible at this moment is 30Gbps.
The infrastructure has two independent uplinks to the Internet. One connection is directly connected to the AMS-IX (SIDN is member of AMS-IX since 1998). The other connection is connected through the BIT network, which is connected to AMS-IX, DE-CIX, LINX and local parties like NL-IX, GN-IX and NDIX.
At the back-end, the Whois servers are connected to the Shared Registry Systems’ database. The Whois servers have a read-only access to the data needed for Whois services in the database. Direct access to the database ensures real-time information provided in answers to Whois requests. More details are provided in the answers to Evaluation Question #32 ‘System and Network Architecture’.
All Whois requests are logged and kept for one week. After this period, statistical data will be extract from the logging, and the logging will be removed from the systems.
Patch management is actively applied to all systems that support registry services. Common practices (like the Security Configuration Guides from NSA) are followed. SIDN is ISO27001 certified, which reflects a high security awareness of the employees. More details are provided in the answers to Evaluation Question #30, Security Policy.
26.6 Zone File Access
As described already above, also zone file access will be provided via the back end services of SIDN.
.politie will offer via the Centralized Zone Data Access Provider its standardized Zone File Access Agreement to grant any interested internet user who provides identification and contact details free access to the Zone Files using a sub format as described in Specification 4 under 2.1.4 of the Standard Master format defined in RFC 1035, Section 5 including all the records present in the actual zone used in the public DNS.
The zone file will be made available via the ICANN specified and managed URL .politie.zda.icann.org. This will be done in conformance with the details under 2.1.3.
The agreement will contain the limitations to the right to use the zone file as specified in 2.1.5 and the right and grounds for the CZDA Provider and Registry Operator to reject access or revoke access as further detailed under 2.1.1. .politie will provide access for a period of 3 months with the possibility of renewal.
.politie will further co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by permitted users and provide bulk access to the zone files to ICANN, or its designee and to Emergency Operators designated by ICANN on a continuous basis in the manner that ICANN may reasonably specify from time to time.
26.7 Bulk Registration Data Access to ICANN
.politie will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Thin Registration Data as specified in Specification 4 under 3.1.1 and in the format specified under 3.1.2 and make it available as specified under 3.1.3. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
.politie will further in case of a registrar failure, de-accreditation, court order, etc. that prompts the temporary or definitive transfer of the domain names to another registrar, at the request of ICANN, provide ICANN with up-to-date data for the domain names of the losing registrar. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. Registry Operator will provide the data within 2 business days. Unless otherwise agreed by Registry Operator and ICANN, the file will be made available for download by ICANN in the same manner as the data specified in Section 3.1. of Specification 4 to the Base Agreement.
26.8 Resources
SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed, most of them entirely dedicated to .nl services. As back end registry operator of .politie SIDN will provide all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .politie the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.
SIDN therefore has all necessary resources on hand to provide all services described in this answer.
27. Registration Life Cycle: provide a detailed description of the proposed registration lifecycle for domain names in the proposed gTLD. The description must:
- explain the various registration states as well as the criteria and procedures that are used to change state;
- describe the typical registration lifecycle of create/update/delete and all intervening steps such as pending, locked, expired, and transferred that may apply;
- clearly explain any time elements that are involved - for instance details of add-grace or redemption grace periods, or notice periods for renewals or transfers; and
- describe resourcing plans for this aspect of the criteria (number and description of personnel roles allocated to this area).
The description of the registration lifecycle should be supplemented by the inclusion of a state diagram, which captures definitions, explanations of trigger points, and transitions from state to state.
If applicable, provide definitions for aspects of the registration lifecycle that are not covered by standard EPP RFCs.
A complete answer is expected to be no more than 5 pages.
27 Registration Life Cycle
A depiction of the Registration Cycle for .politie is provided in the attachment ‘Q27-Registration_Life_Cycle.pdf’.
All ʹcommonʹ domain names eligible for registration (i.e. domain names that are not excluded or reserved) follow the domain name life cycle described below.
Available
Domain name is available for registration. Whois status is ʹfreeʹ.
Available transaction: EPP «create»
Pending Create
After receiving an EPP «create» command, the domain name goes through a ʹpending createʹ phase until the registration system has handled the request. This phase is skipped for regular domain names and is used for manual review of registration of reserved domain names (see ʹreserved domain namesʹ below).
If registration is pre-authorized or no manual review is required, the domain name will automatically proceed to ʹregisteredʹ within milliseconds.
OK (Registered)
Domain name is registered with an Accredited Registrar and is linked to one registrant and at least one administrative contact and one technical contact. Whois status is ʹactiveʹ or ʹinactiveʹ (if no nameservers are linked to the registration).
Possible transactions for registered domain names
- EPP «update» (via registrar of record)
Updates registration details (registrant, contacts, nameservers, EPP client status). Command not possible with EPP status serverUpdateProhibited.
EPP status clientUpdateProhibited only allows for removal of this status, all other updates are rejected.
- EPP «renew» (via registrar of record)
Expiration date is changed (prolonged by 1 to 10 years with a maximum of 10 years from renewal date). Domain status is unchanged. Command not possible with EPP status clientRenewProhibited or serverRenewProhibited.
- EPP «transfer» (via all accredited registrars)
Domain name enters ʹpending transferʹ until transfer is completed (or rejected). Command not possible with EPP status clientTransferProhibited or serverTransferProhibited.
- EPP «delete» (via registrar of record)
Domain is immediately available for registration again. No Redemption Grace Period is implemented. Command not possible with EPP status clientDeleteProhibited or serverDeleteProhibited.
Pending Transfer
Domain name is in a transfer process from one registrar to another. Whois status shows active or inactive, depending on the number of associated nameservers. EPP status is ʹpendingTransferʹ.
Upon receiving a transfer request, the registration system sends EPP messages to the registrar of record and the gaining registrar with information on the received transfer request. The registrar of record can approve or reject the requested transfer within a 5 day transfer period. The gaining registrar can cancel the transfer request during the 5 day waiting period.
If the registrar of record approves the transfer or doesnʹt respond within the 5 day waiting period, the transfer will be successfully completed. The domain name will be registered with the gaining registrar and moves to the ʹregisteredʹ phase. The registrant and contact persons are copied to the gaining registrar. If the registrant and contact persons already exist in the gaining registrarʹs data, the existing handles are copied to a new contact maintained by the gaining registrar. The contact-identifying part of the handle is unchanged and the registrar-identifying part is updated to reflect the new maintainer. The name servers also transfer to the gaining registrar and can be updated after completion of the transfer.
A one year renewal will be charged to the gaining registrar and added to the expiration date (unless the expiration date exceeds 10 years from the transfer date).
Notifications of transfer completion are sent through the registration systemʹs EPP interface to both registrars.
If the registrar of record rejects the transfer or if the gaining registrar cancels the transfer request within the 5 day waiting period, the transfer is cancelled. The domain name remains registered with the registrar of record and moves to the ʹregisteredʹ phase.
Notifications of transfer completion (rejection) are sent through the registration systemʹs EPP interface to both registrars.
No other transactions are possible until the transfer process has been completed. After a completed transfer the domain name will be in the ʹregisteredʹ phase and a default renewal of one year is added. If the domain name was in ʹauto-renew graceʹ when the transfer was requested, and the transfer is rejected, then the domain name returns to ʹauto-renew graceʹ as long as the auto-renew grace period hasnʹt expired.
Auto-renew Grace
After expiration of the domain name, the registry will automatically renew the registration with one year. If the domain name is deleted or successfully transferred to another registrar within 45 days of this auto-renewal, the charge made for the auto-renewal will be credited.
All available transactions and statuses are equal to the ʹregisteredʹ state.
Auto-renew grace ends when the registration is renewed or deleted by the registrar, if the domain name is successfully transferred to another registrar or after 45 days.
27.1 Excluded and Reserved Domain Names
Domain names excluded from registration are not in the .politie zone file, have a Whois status ʹexcludedʹ and cannot be registered by anyone. An EPP «create» command will be rejected by the registration system.
Excluded domain names are:
Exclusions based on Specification 5 in the Base Agreement.
- The label ʹexampleʹ;
- All two-character labels;
Labels that include hyphens in the third and fourth position (the .politie registry does not offer IDN);
- The labels ʹnicʹ, ʹwwwʹ, ʹirisʹ and ʹwhoisʹ (some of these labels will be used by the registry operator).
Exclusions based on technical requirements for .politie
- All one-character labels;
- Labels containing more than 63 characters;
- Labels that contain other characters than letters, numbers and hyphens;
- Labels containing hyphens that are not between letters and⁄or numbers.
Reserved domain names can only be registered by a designated or authorized registrant.
After registration, updates of the registrant are blocked in the registration system. An EPP «create», «update» or «transfer» command will be manually reviewed by .politie registry operator and has to be authorized before it will be processed by the registration system.
gTLD registry and registry operator names
This list contains the names reserved for usage by gTLD registry and to be transferred with the Registry Database in the event of reassignment. Only the gTLD registry or gTLD registry operator can be the registrant of these names.
Country and territory names
Registration of these names will be limited to registrants who are designated by the government or public authority of the concerned country or territory.
A government or public authority wanting to register their country or territory name under gTLD has to get an authentication by GAC Secretariat. This authentication and the name of the designated beneficiary need to be transferred to gTLD operator, who will issue an authorisation number to the designated beneficiary in the country concerned. The domain name can be registered through an accredited gTLD registrar with the designated beneficiary as the registrant, using the authorisation number.
The registrant of these domain names can only be changed after registration if the new designated registrant also has been authenticated by GAC Secretariat.
List of country and territory names, conform Specification 5 in the Base Agreement
- 5.1. the short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union (http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU);
- 5.2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and
- 5.3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;
27.2 Resources
SIDN is the foundation that operates since 1996 the registry for the .nl TLD, the 7th largest TLD in the world with currently approximately 5 million registered domains and the 3th largest ccTLD. Running the .nl TLD is the main activity of SIDN. More than 95% of all the time and resources are dedicated to this significantly important task. The work of SIDN is well regarded by its registrars and the Dutch Government. SIDN is a highly experienced and knowledgeable registry provider and from the date of its conception an active participant in ICANN and also active in IETF and for example the CENTR Community. SIDN is based in Arnhem, the Netherlands and has a total staff of 73 people employed.
As back end registry operator of .politie SIDN will provide as a service all technical registry services on the basis of the .nl-infrastructure. This infrastructure is maintained by SIDN’s Technical Division that consist of a total staff of 26 under a dedicated manager who is a member of SIDN’s Management Team. The Technical Division is divided into 4 groups: ICT Operations, Software Development, Application Development and a Test Team.
For the services to .politie the main resources will be drawn from the team ICT Operations. This team currently consists of 10 staff responsible for the 24x7 uptime of the .nl registration system including the network infrastructure and the DNS servers. From this team, every week, two persons are on 24x7 duty. Also, two persons are on 10x5 duty to handle regular service requests and the daily maintenance of systems and applications. This team will be extended with at least two new people before the end of this year. ICT Operations manages further an external company that is responsible for the daily maintenance (including monitoring, incident, problem and change management) of the databases.
SIDN will further provide all registrar and registrant support and handle abuse notices via its Support Desk. The SIDN support desk currently consists of a team of 14 highly skilled, well trained and experienced staff who handle all support questions (including abuse) and calls for the .NL TLD and the 1.3.e164.arpa ENUM delegation, also operated by SIDN. Together they serve about 1,800 registrars and about 2,7 million unique registrants. All support is provided in Dutch as well as in English. The SIDN support desk is organized in a first (9 staff) and second line (4 staff), with a dedicated manager who is a member of SIDN’s Management Team. The staff has a diverse background including experience on technical, policy and legal aspects in its ranks. The SIDN support desk has direct access to all the other specialists of SIDN who may act as a third line of support. The SIDN support desk handled on average in 2011 950 phone calls and 1625 mail calls per month.
SIDN which is ISO 27001 certified, has its own Security Officer who is responsible for all security related matters (physical as well as technical) of SIDN and therefore of SIDN services as back end provider. SIDN also has a legal counsel employed who is experienced in domain name law and policy matters and may support .politie where necessary and act as a liaison to ICANN.
SIDN therefore has all necessary resources more than available to provide all services described in the answers to the questions of the applicant guidebook for gTLDs.
28. Abuse Prevention and Mitigation: Applicants should describe the proposed policies and procedures to minimize abusive registrations and other activities that have a negative impact on Internet users. A complete answer should include, but is not limited to:
- An implementation plan to establish and publish on its website a single abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning all names registered in the TLD through all registrars of record, including those involving a reseller;
- Policies for handling complaints regarding abuse;
- Proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6); and
- Resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
To be eligible for a score of 2, answers must include measures to promote Whois accuracy as well as measures from one other area as described below.
- Measures to promote Whois accuracy (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Authentication of registrant information as complete and accurate at time of registration. Measures to accomplish this could include performing background checks, verifying all contact information of principals mentioned in registration data, reviewing proof of establishment documentation, and other means
- Regular monitoring of registration data for accuracy and completeness, employing authentication methods, and establishing policies and procedures to address domain names with inaccurate or incomplete Whois data; and
- If relying on registrars to enforce measures, establishing policies and procedures to ensure compliance, which may include audits, financial incentives, penalties, or other means. Note that the requirements of the RAA will continue to apply to all ICANN-accredited registrars.
- A description of policies and procedures that define malicious or abusive behavior, capture metrics, and establish Service Level Requirements for resolution, including service levels for responding to law enforcement requests. This may include rapid takedown or suspension systems and sharing information regarding malicious or abusive behavior with industry partners;
- Adequate controls to ensure proper access to domain functions (can be undertaken by the registry directly or by registrars via requirements in the Registry-Registrar Agreement (RRA)) may include, but are not limited to:
- Requiring multi-factor authentication (i.e., strong passwords, tokens, one-time passwords) from registrants to process update, transfers, and deletion requests;
- Requiring multiple, unique points of contact to request and/or approve update, transfer, and deletion requests; and
- Requiring the notification of multiple, unique points of contact when a domain has been updated, transferred, or deleted.
A complete answer is expected to be no more than 20 pages.
Abuse prevention and mitigation will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry. The operations for .politie will, where necessary, be conducted based on the same standards and procedures that SIDN has in place for .NL. This suits the needs of the .politie top level, which is also aimed primarily at the Dutch community.
SIDN is very proud that .NL, being the 7th largest TLD with almost 5 million registrations, is one of the safest domains according, to amongst others, these independent reports by Norton and McAfee:
Norton Cybercrime Report (2011) -http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄
McAfee Mapping the Mal Web (2010) – http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf
SIDN is further an ISO 27001 certified organization. Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle. Abuse prevention and mitigation is an integral part of SIDN’s security policies. For more details regarding security, please see the answers provided to Evaluation Question #30 ‘Security Policy’.
What will be regarded as abuse?
Abuse has, as SIDN has seen in the 16 years as a TLD registry operator, many different forms and modes. This varies from the direct infringement of (IP)rights and cybersquatting, to unauthorized domain transfers, to registering domains with false data, but also registrars simply forgetting to change the contact information of the registrant after relocating to a new address and content issues such as phishing, malware distribution, the spreading of child pornography, et cetera.
What is regarded abuse under .NL, is defined in its general terms and conditions for the registrant. Under .politie there will be no direct contractual relation between the registry operator and the registrant and therefore the description of what is abusive will be something that the registrars need, as will be provided for in the RRA, to put in their contracts with the registrants.
In general the following will be regarded as abuse:
- The registrant infringes the technical requirements set for .politie. These technical requirements are based on ICANN’s requirements and the relevant RFC’s;
- The registrant does not provide correct name and⁄or contact details of himself or the other contacts, or fails to keep these accurate;
- The registration or the use of the domain name infringes the rights of a third party, or is unlawful or illegal in any other way;
- A domain name is transferred to another registrar or to another registrant without the authorization of the registrant.
The abuse and its mitigation referred to in this Evaluation Question is mainly focused on abusive actions from the side of the registrant, but there are all other kind of ‘abuses’ that a registry operator has to deal with. E.g. Abuse of DNS by overloading the name servers with queries, or abuse of the registration system by registrars ‘hammering’ the SRS to obtain domains falling out of redemption grace period. SIDN developed an array of procedures, technical solutions, rules and regulations to prevent these types of abuse and mitigate possible detriment. These types of abuse and mechanisms to control risks are discussed in the answers to other Evaluation Questions, such as #30 ‘Security Policy’. In the answer to this Evaluation Question, we now however focus on the registrant’s abuse as defined above.
Although abuse mitigation will be available for the TLD in line with the description underneath, abuse in the sense mentioned will be extremely unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police.
28.1 Single abuse point of contact & handling of notices of abuse
The central registry operator’s website for .politie will, on the homepage, have a clearly visible ‘report abuse’ sign where every visitor of the site may find contact details (e-mail, telephone, postal address) that may be used to report abuse. As specified in Specification 6 to the Registry Base Agreement, these details will also be provided to ICANN in the form in which ICANN would like to receive them. These contact details will all lead to the support desk of SIDN which will also make sure that upon any changes to these details ICANN will be promptly notified and the information on the registry operator’s website will be updated.
The SIDN support desk currently consists of a team of 14 highly skilled, well trained and experienced staff who handle all support questions (including abuse) and calls for the .NL TLD and the 1.3.e164.arpa ENUM delegation, also operated by SIDN. Together they serve about 1,800 registrars and about 2,7 million unique registrants. All support is provided in Dutch as well as in English.
The SIDN support desk is located at SIDN’s main office location in Arnhem and is organized in a first (9 staff) and second line (4 staff), with a dedicated manager who is a member of SIDN’s Management Team. The staff has a diverse background including experience on technical, policy and legal aspects in its ranks. The SIDN support desk has direct access to all the other specialists of SIDN who may act as a third line of support.
The primary focus of the SIDN support desk is on registrars. SIDN services around 1800 registrars for .NL, accounting for around 65% of all the incoming calls (e-mail and telephone). The SIDN support desk also has extensive experience assisting and handling abuse notices and complaints from registrants and third parties. The mission of the SIDN support desk is to help everyone as good and as fast as possible by listening to the issues and where necessary clarifying the question or complaint, providing answers, solving issues whenever possible, providing information, explanations or clarifications on policies, rules and regulations and⁄or redirecting the person involved to a more adequate internal or external source that might be able to resolve the issue. SIDN also has a legal counsel employed who is experienced in domain name law and policy matters and may support .politie where necessary and act as a liaison to ICANN.
The primary support channels for the SIDN support desk are e-mail and telephone. Post and fax are mostly used for administrative purposes but are also available for contacting the support desk. The SIDN support desk is directly reachable during SIDN office hours (Monday-Friday 08:00 – 18:00 Netherlands time, which is UTC+1). During these hours telephone calls are answered directly. When more incoming calls occur than employees are available to answer them, the calls are placed in a queue. The current planning is very adequate: telephone queues are a rare occasion and last only one minute at the maximum. The incoming e-mail calls are also queued. E-mails receive a receipt-notification with a ticket number for references immediately and are answered in maximum 2 days. The queue however is monitored constantly for urgent messages which will of course be given the necessary priority. The SIDN support desk is further reachable 24⁄7 for registrars through a voicemail system for reporting technical disturbances and critical problems. Reports of critical problems outside office hours are responded to within 30 minutes.
The SIDN support desk works with a CRM-system to log in detail all calls and responses. This system can provide extensive differentiated reports (e.g. source, channel or type).
All calls received via whatever media including all abuse notices are screened for urgency during working hours and handled accordingly.
The desk further utilizes clear and extensive work instructions that provide baseline texts that may be used depending on the specific situation and assist the staff in handling the more or less regular or frequently asked questions. These work instructions are drafted by the staff of the desk in conjunction with the necessary technical, procedural and legal specialists. The work instructions are constantly being reviewed to keep them up to date. Amongst others, specific work instructions are available for handling notices of incorrect WHOIS information and other abuse notifications. The work instructions are available in Dutch and can be provided if requested.
SIDN participates in various partnerships that deal with IT security, like for example the Dutch National Cyber Security Centre (NCSC). This enables us to quickly engage into a nationwide coordination with the NCSC and Dutch ISP’s in case of security incidents. It also provides us with a network for sharing information regarding malicious or abusive behaviour with industry partners and eventually engage in a rapid takedown or suspension of a domain name through what’s called a ‘Notice-And-Take-Down’ agreement (http:⁄⁄www.samentegencybercrime.nl⁄NTD⁄NTD_English?p=content). SIDN has a Security Officer (CSO) and a Computer Security Incident Response Team (CSIRT; formed in 2004) with experts from various disciplines within the organization. This team acts as a ‘quick reaction force’ in case of a security incident related to the registry- and DNS functions of SIDN. (See the answers provided to Evaluation Question #30 ‘Security Policy’ for more detailed information.)
On a non-formalized basis SIDN, being the ‘de facto’ national Dutch registry, has many direct and warm contacts with Law Enforcement, Government and members of the technical community on different levels. In the case of extreme urgent matters SIDN may and will be reached 24⁄7 and is fully capable to take any action necessary.
28.2 Mitigating abuse in general
Mitigating abuse will be done by a series of different measures:
.politie will first of all, as described above, have a central abuse contact published and available and an professional experienced support department ready to handle any abuse notices.
.politie will further mitigate abuse by taking technical measures to make sure that certain types of abuses simply cannot occur. For example, the registration system will not allow registration attempts of domains with a length of less than 2 characters or more than 63 (one of the technical requirements) and makes it technically impossible to register names on the excluded names list. Types of abuse that cannot be completely prohibited, will be made less likely through technical controls (e.g. by the obligatory use of the AuthInfo Code for domain name transfers).
.politie will also implement automated signalling systems to inform the registrars of possible abusive behaviour of the registrants, for example via reports from what is called the ‘DNS Crawler’ and an alerting system to registrars for domains that are being used in Phishing. (See ‘3. Infringement of technical requirements’ below).
.politie will further mitigate abuse by providing a Trademark Claims Service, available during the landrush and 60 days after the opening of .politie for registrations, and supporting UDRP and URS. More detailed information on this and the other rights protection measures mentioned will be provided in the answer to Evaluation Question #29 ‘Rights Protection Mechanisms’. The TLD will however not organize a sunrise. Given the single registrant policy a sunrise would not offer any other than the single registrant an opportunity to register domain names and would therefore be entirely irrelevant for the protection of third party trademark rights. It may clear that a Dutch governmental organization as the applicant will not register⁄use infringing domain names. Because the TLD recognizes the importance of the protection of trademark holders in the current expansion, the TLD is entirely prepared to adopt that Trademark Claims Service and the other RPM’s although it may be clear that these will never be used with regard to this TLD.
.politie will next to the forgoing inform and educate the public with regard to possible abuse issues, the availability of remedies and the how and where to obtain these in detail via its website, apart from the clear notice of the abuse contact and how to contact them.
.politie will further pick the fruits of using SIDN as the back end provider as SIDN is in its role as the .NL registry already constantly working on the enhancement of the trust in the .NL-domain environment and in that respect working hard to prevent and mitigate abuse and develop new methods, policies, practices and measures to fight abuse.
28.3 Specific abuse policies
In the above the overall approach towards abuse has been described. Underneath please find a more detailed description of policies and mitigation measures in place. As said a detailed description of the rights protection measures already named in the above is to be found in the answer to Evaluation Question #29. All measures described below will also be made available for the .politie registry.
At the same time it is highly unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police that abuse as described in this answer to happen.
28.3.1 Incorrect Whois details
Although incorrect Whois details will be extremely unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police the TLD will have the following approach available.
.politie will follow in principle the same rules and regulations SIDN does for .NL with regard to registering domains and providing correct registration data. This means that the registrant will have a contractual obligation to present correct information and to keep the information correctly updated during the full registration period. The registrars will further have a contractual obligation to take all reasonable steps to ensure the accuracy of the registered data and the traceability of the registrant or party that commissioned the registration. The registrar shall not register any data that the registrar knows or suspects to be inaccurate and shall, upon independently ascertaining or learning from SIDN or a third party that an item of registered data is inaccurate, immediately replace the data in question with accurate data. If requested to do so by SIDN, the registrar shall provide evidence of the accuracy of the registered data. Under ICANN’s ‘Whois Data Reminder’ Consensus Policy, registrars are obliged to at least annually present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.
.politie will have a procedure available to handle notices of possible incorrect Whois details which will be a version of the current procedure used by SIDN. For .NL SIDN has a detailed script with regard to the actions to be taken upon the receipt of an abuse notification. In general SIDN will contact the registrar and request the registrar to verify the alleged incorrect information and have the registrant provide proof of the correctness of the alleged incorrect information. In general the registrant is provided the opportunity to update incorrect information but will have to provide proof of the correctness of the updated information. The registrant will not be given this chance if the information provided is clearly or purposely incorrect. In that case SIDN will cancel the registration.
28.3.2 Infringement of technical requirements (including orphan glue records)
SIDN requires registrants to obey the rules set out in a ‘technical requirements document’ that defines minimal technical requirements for the registration (and delegation) of .NL-names (in the DNS). The current version of this .nl-document that will be updated for .politie is attached to the answer of this question.
Most of the technical requirements are enforced by technical controls in the shared registration system. Other requirements are checked once the domain is delegated, by means of an in-house developed tool called the ‘DNS crawler’. This tool produces monthly feedback on the DNS quality of the domain names registered to registrars. It also reports violations of the technical requirements and DNS errors to registrars and to our compliance monitoring team. The specifications to this tool are provided as an attachment (Q28-DNS_Crawler_Specifications’).
The Shared Registry System has controls in place, at several layers, to prevent so called ‘orphaned glue records’ as is mentioned in the SSAC comment on Orphan Glue Records in the Draft Applicant Guidebook (SAC048). The controls preventing orphaned glue records are described below.
When malicious conduct on domain names is verified, the procedure ‘Notice-And-Take-Down’ is started (see ‘4. Unlawful or criminal use of a domain name’ below). This procedure handles the take down of domain names on which malicious conduct finds place. SIDN is also on the NXDomain mailing list to track requests for take down of domain names. Furthermore, SIDN takes part in the Conficker working group.
Detailed information on Orphaned Glue
With respect to orphaned glue, the following controls are in place to mitigate the danger of having orphaned glue:
- When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name.
- If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers.
- If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file. This approach is in line with policy 3 of SAC048, section 4.3.
Apart from these controls, additional checking of the zone file is in place, including checks on orphaned (and missing) glue records. See the answers provided to Evaluation Question #35 ‘DNS’ for more details.
Registrars will be informed about their registrations with less than the minimum required number of name servers through the monthly reports sent out by the ‘DNS crawler’ (see ‘3. Infringement of technical requirements’ above).
When a domain name has no linked host objects (registration state is inactive), the registrar will be directly notified and asked to correct this situation.
28.3.3 Phishing feed
Under .NL SIDN has a fully automated phishing feed that provides for a fast signalling of and action against phishing attempts under .NL-domain names.
SIDN has agreed a deal with Netcraft (http:⁄⁄news.netcraft.com⁄), an internet security authority that for several years has offered a wide range of services aimed at eliminating internet fraud, including phishing. It was Netcraft, for example, who developed the Anti-Phishing Toolbar that many internet users now rely on to check the authenticity of websites. The toolbar provides Netcraft with an enormous volume of data, which they are then able to make available to clients.
Every five minutes or so, SIDN checks Netcraft’s suspect URL database, which is constantly being updated. Every time a .nl URL is added to the database, an e-mail message is automatically sent to the relevant registrar’s administrative contact e-mail address. In other words, the system does not rely on periodic reporting, but on almost immediate individualised e-mail contact. It therefore provides a basis for very rapid intervention.
The e-mail sent to draw a registrar’s attention to the fact that a client is running a website that may be fraudulent will include the following information:
- Suspected phishing site URL
- Host: the IP address of the system running the website
- Country: the country of origin of the IP address
- Date: the date and time that the suspect site was detected
- Target: the name of the company that seems to be targeted
As the registrars only receive information that is specifically relevant for them and their customers, these e-mails receive high attention and usually lead to swift actions from the registrar, ending the phishing attempts.
29. Rights Protection Mechanisms: Applicants must describe how their registry will comply with policies and practices that minimize abusive registrations and other activities that affect the legal rights of others, such as the Uniform Domain Name Dispute Resolution Policy (UDRP), Uniform Rapid Suspension (URS) system, and Trademark Claims and Sunrise services at startup.
A complete answer should include:
- A description of how the registry operator will implement safeguards against allowing unqualified registrations (e.g., registrations made in violation of the registry’s eligibility restrictions or policies), and reduce opportunities for behaviors such as phishing or pharming. At a minimum, the registry operator must offer a Sunrise period and a Trademark Claims service during the required time periods, and implement decisions rendered under the URS on an ongoing basis; and
- A description of resourcing plans for the initial implementation of, and ongoing maintenance for, this aspect of the criteria (number and description of personnel roles allocated to this area).
>To be eligible for a score of 2, answers must also include additional measures specific to rights protection, such as abusive use policies, takedown procedures, registrant pre-verification, or authentication procedures, or other covenants.
A complete answer is expected to be no more than 10 pages.
Rights protection mechanisms are a part of abuse prevention mechanisms. As already mentioned in the answer to Evaluation Question #28, abuse prevention and mitigation under .politie will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry, being worldwide the 7th largest TLD with almost 5 million domain registrations.
SIDN’s support desk will act as the single abuse point for .politie as is described in detail in the answer provided for Evaluation Question #28. SIDN’s support desk with a total number of 14 staff is experienced in working with right protection mechanisms and supporting rights holders, registrars and registrants when they are confronted with right infringement matters and procedures. SIDN provides these services under the registry back end services contract with .politie.
With regard to rights protection .politie will implement all currently by ICANN prescribed measures by providing a Trademark Claims Service available during the landrush and 60 days after the opening of TLD for registrations, and supporting UDRP and URS. The TLD will however not organize a sunrise. Given the single registrant policy a sunrise would not offer any other than the single registrant an opportunity to register domain names and would therefore be entirely irrelevant for the protection of third party trademark rights. It may clear that a Dutch governmental organization as the applicant will not register⁄use infringing domain names. Because the TLD recognizes the importance of the protection of trademark holders in the current expansion, the TLD is entirely prepared to adopt that Trademark Claims Service and the other RPM’s although it may be clear that these will never be used with regard to this TLD.
.politie will evidently adhere to any other or any amended rights protection mechanisms (RPMs) that may be mandated by ICANN. .politie will, except for the sunrise, include all ICANN mandated and independently developed RPMs in the registry registrar agreement. .politie will not mandate any rights holder to use any other trademark information, aggregation, notification or validation service in addition to or instead of the Trademark Clearinghouse.
.politie will further comply with the dispute resolution mechanisms (PDDRP and RRDRP) and implement and adhere to any remedies ICANN imposes following a determination by a panel under the DRPs and will accept to be bound by such determinations.
In following section, the different measures and the role of the registry operator are described in more detail.
29.1 Trademark Claims Service
During the projected landrush period and during the first 60 days after the start of the availability of the shared registry system for general registrations, the .politie will offer a Trademark Claims Service in cooperation with the Trademark Clearinghouse and its registrars according to the then available procedures. During this period all requested registrations will be checked by .politie for Identical Matches (conform the definition in the current Trademark Clearinghouse document) with trademarks registered in the Trademark Clearinghouse. If such a match is detected .politie will send a Trademark Claims Notice in Dutch and English via its sponsoring registrar to the prospective registrant to inform him about the match and make sure that by still registering the name the registrant warrants the reception of the notice, that he has understood it and that, to the best of his knowledge, the registration or use of the domain will not infringe on the specific trademark rights.
Under the Registry Registrar Agreement the registrar will be obliged to promptly notify the trademark holder via the registrar’s interface with the Trademark Clearinghouse after the registration is effectuated.
29.2 Unified Domain Name Dispute Resolution Policy (UDRP)
.politie supports the UDRP procedure, which is one of the formal consensus policies, and will oblige registrars via the Registry Registrar Agreement to support it and to have the registrants accept the applicability of the UDPR via the Registry Registrant Agreement.
29.3 Uniform Rapid Suspension
The support organization for the .politie, which will be made available through SIDN as the backend service provider, will handle URS notices received from the URS providers in line with the final URS rules. As the current draft URS Rules require the registry to lock the domain within 24 hours after the reception of the notice, the registry will implement a procedure to make sure that these notices are timely signaled, the domains in question are locked via the SRS and the URS Provider receives a Notice of Lock. The registry will then await further notices from the URS Provider and act accordingly by or:
a. immediately unlocking the domain; or
b. suspending the domain, redirecting the name servers for the domain to the webpage provided by the URS Provider and publish in the Whois that the domain name will not be able to be transferred, deleted or modified for the life of the registration.
The registry will do the same if it receives notice of the outcome of an appeal.
The registry will not renew the registration of a, because of the outcome of a URS procedure suspended, domain name except if it receives a request from the registrar for the domain name to renew the domain for one year upon a request by the successful complainant. Please note that the actual and detailed implementation will depend on the final URS rules.
29.4 Domjur.nl
SIDN publishes since 2001 legal rulings and articles about court and ADR cases involving domain names in The Netherlands (many on the basis of rights infringement claims) on the website http:⁄⁄www.domjur.nl. The information on this site (in Dutch only) gives a nearly complete overview of all domain name related cases in the Netherlands since the upcoming of the internet and is aimed primarily at lawyers, but there is also information that may be of interest to ‘lay’ visitors.
Summaries of all relevant rulings are provided on the website. Rulings with particular legal significance are also annotated by leading internet lawyers. The DomJur website is maintained jointly by SIDN and the Tilburg Institute for Law, Technology, and Society (TILT) of Tilburg University.
DomJur will of course also publish any domain name cases that might arise under .politie and will be a good source for (lawyers of) rights holders to learn about the whereabouts of domain name disputes.
30A. Security Policy: provide a summary of the security policy for the proposed registry, including but not limited to:
- indication of any independent assessment reports demonstrating security capabilities, and provisions for periodic independent assessment reports to test security capabilities;
- description of any augmented security levels or capabilities commensurate with the nature of the applied for gTLD string, including the identification of any existing international or industry relevant security standards the applicant commits to following (reference site must be provided);
- list of commitments made to registrants concerning security levels.
To be eligible for a score of 2, answers must also include:
- Evidence of an independent assessment report demonstrating effective security controls (e.g., ISO 27001).
A summary of the above should be no more than 20 pages. Note that the complete security policy for the registry is required to be submitted in accordance with 30(b).
The back-end registry operator for .politie is SIDN, the .NL-registry. All operations for .politie will be conducted by the same standards and procedures that SIDN has in place for .NL. The security policy for .politie will be the same as SIDNʹs security policy for .NL.
SIDN is very proud that .NL, being one of the largest ccTLD’s with almost 5 million registrations, is one of the safest domains according to these independent reports by Norton and McAfee:
Norton Cybercrime Report (2011) - http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄
McAfee Mapping the Mal Web (2010) - http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf
SIDN is an ISO 27001 certified organization. (See attachment ’Q30-ISO27001_SIDN.) Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle.
Almost all this documentation is written in Dutch. We have summarized and translated the relevant information from this extended documentation regarding our security policy. Full information is available in Dutch and can be provided if needed.
More detailed information on these topics is provided in the answer to part b of this Evaluation Question.
1. Security Management
Information security is defined as the process of assessing the required reliability of information systems in terms of availability, integrity and confidentiality, including describing, maintaining and validating a coherent set of related management controls.
SIDN has a pro-active attitude towards information security, aimed at mitigation of consequences and timely recovery of emergencies, and minimizing contingencies. Information security is not regarded as an impediment or cost, but as a way of thinking and working that facilitates SIDN to optimize the role of domain name registry. Attention and efforts regarding information security are taken into account early on in all decision making processes.
The SIDN Security Policy is carried out and fulfilled by all SIDN employees. The CEO of SIDN is overall responsible for security and has assigned a dedicated security officer to handle all security issues for the SIDN.
Segregation of functions is used as a preventive measure to avoid risks of abuse through separating tasks, authorisations and responsibilities.
SIDN approaches security management on three levels: strategic, tactical and operational. On each level, a dedicated security team is responsible for security management.
SIDN actively participates in several international security-related organisations, including:
- DNS Changer Working Group (http:⁄⁄www.dcwg.org⁄)
- The Dutch National Cyber Security Centre (NCSC https:⁄⁄www.ncsc.nl⁄english)
- Dutch Knowledge Centre for Information Security (Dutch only: PVIB - http:⁄⁄pvib.nl⁄)
- CENTR Security Working Group (http:⁄⁄centr.org⁄)
- DNS OPSEC-Trust (https:⁄⁄ops-trust.net⁄)
- SATIN (Securing and Trusting Internet Names - http:⁄⁄conferences.npl.co.uk⁄satin⁄)
- DNS⁄OARC (https:⁄⁄www.dns-oarc.net⁄)
- OpenDNSSEC (http:⁄⁄www.opendnssec.org⁄)
- Conficker Working Group (http:⁄⁄www.confickerworkinggroup.org⁄)
2. Audits and Performance Measurement
SIDN maintains a ‘performance-measurement’ program in order to demonstrate the effectiveness of the ISMS and the controls in place. This program consists of auditing, periodic assessments and measurement of Key Performance Indicators.
Apart from audits, SIDN performs internal monitoring on a structural basis to measure Key Performance Indicators. Key Performance Indicators (KPI’s) are variables used for analysing the effectiveness of the implemented security controls.
Audits are performed on both processes and infrastructure. SIDN performs 4 types of audits:
- Financial process audit. This audit results in annual accounts that are approved by a certified public accountant.
- Functional audit on system administration processes.
- Technical audit and penetration tests.
- Checks on Key⁄Quality Performance Indicators.
3. Information Classification
The goal of Information Classification is to provide consistent and structured management of documentation regarding traceability, reproducibility and quality.
Document management describes the document process flow from initiation to management approval, the form and content of documents and the management documents.
The SIDN Information Classification policy divides SIDN information into 4 categories: Public, Internal, Confidential and Secret. It prescribes when to use these classifications, how to transport it and who may see information.
4. Access management
4.1 Logical Access Management
The general policy for providing access to SIDN’s infrastructure prescribes that:
- Only SIDN authorized equipment is permitted access to SIDN’s ICT infrastructure.
- Authorizations and access rights for a specific system are based on the classification of information (Public, Internal, Confidential, Secret) present in that system.
- All users are registered.
- Access and rights are granted on a need-to-know basis.
- Accounts and passwords are strictly personal and not to be shared. Role- or group-accounts should be avoided whenever possible. Users are not allowed to use someone else’s account or password.
- The user of an account is responsible for using the account and password.
- Account information and password must be communicated to the account user separately.
- Passwords must be stored securely and must not be communicated to third parties.
- Usage of accounts (specifically logons) will be logged and monitored at all ICT systems.
- An account name must not reveal any information about its authorization and access rights. An exception is made for default accounts on generic operating systems.
- Special privileges or the usage of accounts with special privileges must be granted formally by the system or application owner or responsible manager and with a temporal validity. Usage of (accounts with) special privileges should be restricted as much as possible.
- Access rights and authorizations must be assessed and (re-)evaluated at least twice a year.
The usage of accounts and passwords is the most common way to gain access to ICT systems. SIDN maintains a password guideline for safe usage of passwords. For information systems which contain a classified higher level of information (e.g. Confidential or Secret), additional forms of authentication are in use, such as IP-whitelisting, certificates and chip cards.
System access to all registry systems and network equipment is restricted to employees in specific functions and related roles and is subject to tighter security.
4.2 Physical Access Management
Physical Access Management describes the policies and procedures for access to SIDN’s office location and specific area’s and rooms therein and SIDN’s production locations where the infrastructure providing registry services resides.
SIDN locations are only accessible for authorized persons with RFID-tagged access cards that need to be worn visibly. Access cards are strictly personal and only one card per person can be in use. Access to SIDN locations is specific to areas and rooms. Access to server-areas, archive rooms and storage rooms is limited to authorized persons.
- Access for SIDN employees is based on a personal access card (combined with biometric authentication) linked to specific authorizations. Temporary staff will have access cards with limited validity that need to be renewed periodically.
- Access for employees of suppliers and partners is based on a personal access card combined with biometrics (2 factor authentication) linked to specific authorizations;
- Visitors need to report to reception and will be provided a distinguishable visitor access card with limited authorizations. Visitors are accompanied by an SIDN employee at all time during access to the location. This employee is responsible for the visitor during the whole access period. Visitors’ access cards have a standard validity of one day.
Access to SIDN’s production locations is limited to SIDN personnel in specific functions and related roles.
5. System Security
5.1 Systems and networks
SIDN establishes a baseline including security elements for all information systems (see ‘Risk Management’ below). From a security perspective, these minimal requirements are set for the baseline:
- All systems have the most recent (security) patches installed;
- Systems are maintained via encrypted connections only;
- All non-required software and features are deactivated or removed;
- System accounts are strictly personal;
- All system accounts comply with SIDN’s password policy;
- Usage of the root account is limited to necessary situations only;
- All systems are monitored and backups are made periodically;
- System logging is monitored;
- System logging is archived. Archives are maintained on a separate system;
- All core systems are located at one of SIDN’s two production locations. All other systems are preferably located at one of SIDN’s two production locations;
- System administration and maintenance sessions are terminated after a specified duration of inactivity;
- All HTTPS-web interfaces are based on qualified and valid certificates;
- All passwords are stored encrypted;
- Systems are behind firewalls, unless specified otherwise;
- Configuration of firewalls is based strictly on a ‘closed-unless’-principle.
5.2 DNS
To ensure the correctness of updates between the registry systems and the pool of available DNS servers the following mechanisms are in place:
- DNS zone file is generated using the registry database;
- Zone file is checked for missing glue records and if ok, transferred to the DNSSEC signer machines;
- On the signer machines, the zone file is DNSSEC signed;
- Next to that validity checks are in place to ensure the correctness and completeness of the zone file;
- If still ok, the zone file if transferred to the pool of master DNS servers;
- The master DNS servers send notify messages to all slaves telling an update is available;
- The slaves contact the master servers to retrieve the updates.
The communication between master and slave name servers is TSIG protected. This means that all data is exchanged in a secure way. Next to that a firewall cluster only allows access to the master DNS servers when traffic is coming from a slave IP address (ether IPv4 or IPv6).
Orphaned Glue
With respect to the orphaned glue, apart from the zone file checks, the following measures are in place to mitigate to danger of having orphaned glue.
When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name. If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers. If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file.
DNS Abuse
Abuse prevention and mitigation is part of the security policies regarding DNS. SIDN’s DNS servers are intended to enable people to find .politie domains in the context of normal Internet use. However, it sometimes comes to SIDN’s attention that the servers are being used for other purposes. Such abuse puts unwanted pressure on system capacity and, in extreme circumstances, could prevent the servers from being used for their proper purpose. This could constitute a denial of service (DoS) attack and compromise the working of the Internet.
Abuse in this context is defined as any form of DNS server usage that isn’t part of normal Internet use. SIDN always regards the following as abuse: A single party’s prolonged or repeated generation of traffic whose volume exceeds the total volume of all normal Internet traffic.
SIDN has policies prescribing specific actions for handling DNS abuse upon detection.
5.3 Back-Up
Availability of information is critical to SIDN’s business processes. Depending on the type of information, data is duplicated and stored. Stored data and backups are made periodically. All information has a dedicated ‘owner’ who is responsible for backup schemes.
Backups are stored physically and geographically separated from the operational information systems. The information systems themselves are located at two geographically separated locations. Backups are stored at a certified supplier of data-backup storage.
5.4 Logging and Monitoring
All core systems are logged and logging is stored and processed through a Log Management System. Stored logging is kept for a minimum of 1.5 years and contains Syslog and system values (e.g. interface throughput, use of memory, processor usage).
The Log Management System also checks logs for at least:
- Errors;
- Failed logins;
- Suspected user logins;
- Successful Backups;
- Network changes, configuration backups;
- Loss of redundant network interfaces;
- Performance of firewalls;
- Types of Spam.
All core systems and applications are monitored. Monitoring is done by comparing pre-defined baseline values and thresholds to actual values and parameters. By crossing of a threshold, alerts are generated. These alerts generate notifications to multiple dedicated SIDN employees. If an alert relates to an incident, an incident ticket is created.
5.5 External Network Connections
External interfaces are interfaces that have access to SIDN’s infrastructure from a third party network or environment. Authorisation to connect to SIDN’s infrastructure can only be obtained after signing of a Non-Disclosure Agreement by the third party and signing the policy for connecting external interfaces. Risks involved in maintaining these interfaces are managed through a policy.
5.6 Software Development
The Shared Registry System is an in-house developed system and many of our other registration services systems and connections between systems rely on proprietary software. Software updates and releases are subject to the Change Management Process, which is based on ITIL (see section 6 below).
SIDN maintains a full DTAP (Development, Test, Acceptance, Production) street for development. With separated systems supporting each phase.
Quality of software is controlled through external auditing by SIG (Software Improvement Group - http:⁄⁄www.sig.eu⁄en). The SRS application (DRS 5.0) is certified with 4 stars out of 5 on maintainability by SIG⁄Tüvit (see attachment ‘Q30-Tuvit’).
Development at SIDN is based on ‘test driven development’. This requires starting with a unit test before developing new functionality. SIDN requires that 80% of all written code is covered by unit testing. Next to the Development Team, SIDN has a dedicated Test Team. All members are ISQTB certified (http:⁄⁄www.istqb.org⁄). The Test Team tests all software through functional application testing and regression testing. The Test Team also supports end users with acceptance testing.
6. Processes
SIDN’s ICT department has several security-related management processes based on ITIL and employees are required to apply them in the following ICT management processes:
- Security Incident Management
- Change Management
- Problem Management
- Configuration Management
- Release Management
- Capacity Management
- Vulnerability Management
- Patch Management
7. Risk Management
The Risk Management Process is an integral part of the ISO27001 methodology and covers a systematic and periodic approach to all activities aimed at:
- Identification and quantification of possible risks;
- Establishment and implementation of mitigating measures to both reduce the chance of occurrence and limit consequences of risks.
As part of a yearly cycle within the Risk Management Process, all primary business processes are reviewed and scored for business impact. Every process and information system is qualified as ‘normal’, ‘relevant’ or ‘critical’ on three aspects (availability, integrity and confidentiality).
SIDN works with a risk matrix that relates inventoried risks to baseline measures from the ISO 27001 standard and to additional measures taken through the risk management process. The full matrix is quite elaborate and written in Dutch. An excerpt with the most relevant threats and assessments is translated in English. Both documents are provided as an attachment to 30b.
8. Business Continuity Management
Business Continuity Management (BCM) is the process that structurally approaches detrimental internal and external influences and threats to business processes and mitigates them to an acceptable level. SIDN distinguishes between a regular and an emergency BCM process.
The regular BCM process covers the process of description, operation, monitoring and reviewing during regular operations. The emergency BCM process covers the process of identification of a disaster, recovering from it and coming back to normal operation as soon as possible.
The scope of the BCM processes are focused on critical business processes. BCM ensures maximum availability of the core business services. The CEO of SIDN has overall responsibility for the whole organisation and thus for Business Continuity Management.
SIDN’s infrastructure is redundantly spread out over several locations, with geographically separated locations for infrastructure supporting registry services, DNS services and system management.
SIDN has contingency plans to facilitate relocation of both infrastructure and staff in case of emergency. All systems providing registry services are hosted at two production locations that are both operational and both contain accurate data and available services. DNS services are supported by a widely distributed system, consisting of several unicast name server clusters and three anycast networks, all hosted at certified data centres. SIDN’s office location contains no systems supporting registry functions. Infrastructure relocation is tested periodically and showed a recovery time of all registry services in less than 10 minutes during the last test, with no outage for DNS services.
In case SIDN’s office location is lost (e.g. through fire or flooding), a backup site is available. This backup site also provides facilities for a partial relocation (e.g. if primary communication channels are lost). Relocation to the backup site is tested annually. These tests show that in case of a relocation, full office functionality is restored within 4 hours.
© Internet Corporation For Assigned Names and Numbers.