Application number: 1-2124-3690 for ministery of the Interior and Kingdom Relations

ministery of the Interior and Kingdom Relations

Schedeldoekshaven 200
The Hague 2511 EZ
NL

+31648130227

+3170467639

Mr. Olaf Andersen

deputy director

+31648130227

olaf.andersen@minbzk.nl

Mr. Olaf Andersen

deputy director

+31648130227

oandersen@freeler.nl

non-profit organization

Dutch government agency: ministery of the Interior and Kingdom Relations

Not Available

Maarten Hillenaar
director

overheidnl

Not Available

As far as the applicant is aware of there are no known operational or rendering problems with regard to the .TLD-string

The mission⁄purpose of the gTLD ʺ.overheidnlʺ is to improve the quality of the internet where the Dutch Government is visible. The name of the TLD consist of the elements “overheid” (Government in Dutch) and “nl” (standard abbreviation of the Netherlands) and the applicant is the Ministry of the Interior and Kingdom Relations as representative of the Dutch Government on this subject.

The improvement of the quality of the internet where the Dutch Government is visible will amongst other be ensured by the usage of the .overheidnl TLD in three ways:
- registration of domain names in the .overheidnl TLD will be limited to organizations that are considered to be part of the Dutch Government;
- the implementation of a variety of security technologies, including for example DNSSEC and DANE, will be obligatory for all .overheidnl domain names;
- the implementation of the Dutch Government accessibility guidelines, will be obligatory for all websites under .overheidnldomain names.

The .overheidnl TLD will thus be a closed authorized registrants only TLD in which all domain names will be reserved and only assigned to organizations which are considered to be part of the Dutch Government upon their request and upon specific authorization from the registry. The registrants will not be allowed to transfer the domain names in the TLD to any other party except for other organizations that are considered to be part of the Dutch Government and again only after having obtained the specific authorization thereto from the registry. 

Benefits for the registrants of having .overheidnl domain names are in the fact domain names can not be claimed by others than organizations that are considered to be part of the Dutch Government. The Dutch Government currently communicates in general via domain names registered under the .nl ccTLD. One of the challenges for the Dutch Government thereby is that the .nl domain, as many traditional TLD’s, is an ‘open’ TLD where domain names are issued on a strictly first come first served bases. Where this clearly is beneficial in many ways, the downside for the Dutch Government is that other parties may register or have registered domainnames that are of interest to governmental organizations or create false expectations for Internet users by registering and using domain names that are regarded by the public as being governmental domain names or typo’s of such names. By having a strictly Government only gTLD the Government makes sure that governmental organizations can register that domain names that they choose and that these names are available. It further provides a warranty to Internet users that they actually communicate with a governmental organization which enhances further trust in governmental Internet communication for Internet users. 

As already mentioned before the .overheidnl TLD will be a closed authorized registrants only TLD in which all domain names will be reserved and only assigned to organizations which are considered to be part of the Dutch Government upon their request and upon specific authorization from the registry. The registrants will not be allowed to transfer the domain names in the TLD to any other party except for other organizations that are considered to be part of the Dutch Government and again only after having obtained the specific authorization thereto from the registry. As a result there will no ‘social costs’ whatsoever involved in the operation of the .overheidnl TLD. 

To be complete:
- There will not be an open or first come first served registration process for domain names under the .overheidnl TLD. All domain names will be assigned by the registry who will handle multiple applications for any particular domain name through an internal governmental procedure;
- Given the purpose of the .overheidnl domain and the fact that its existence is not at all financed by the sale of domain names there will not be any cost benefits for registrants in the sense specified in the question;
- The .overheidnl domain will, as it is obliged to, work with an ICANN accredited registrar and also allow all ICANN registrars to sign its standard Registry Registrar Agreement. It is expected however that the Dutch Governmental Organizations may decide to register all domains through a single or a few registrars. The registry will not charge the registrars for registrations under the .overheidnl domain but will be entirely funded by the Dutch Government. Given this situation there are no price in- or decreases foreseen.

No

Not Available

No

22 Protection of Geographic Names

Measures for protection of geographic names in the .overheidnl 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 .overheidnl 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 .overheidnl 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 Registry Services

All core registry services for .overheidnl will be provided by .overheidnl’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 .overheidnl 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 .overheidnl 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 .overheidnl Accredited Registrars through the Shared Registration System. The SRS for .overheidnl 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 .overheidnl 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 .overheidnl.
After registration, updates of the registrant are blocked in the registration system. An EPP «create», «update» or «transfer» command will be manually reviewed by .overheidnl registry operator and has to be authorized before it will be processed by the registration system.

A test environment of the SRS will be made available to registrars, providing all needed functionality to create and test administrative interfaces.

23.2 DNS and DNSSEC Services
At launch, .overheidnl 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 .overheidnl are reachable via IPv4 and IPv6 addresses.

The zone file for .overheidnl 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 .overheidnl. 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
.overheidnl’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.overheidnl 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.

.overheidnl 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 .overheidnl 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 SRS Performance

All core registry services for .overheidnl will be provided by .overheidnls’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 .overheidnl 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 .overheidnl’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 .overheidnl 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 .overheidnl 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 .overheidnl 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 EPP

All core registry services for .overheidnl will be provided by .overheidnl’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 .overheidnl 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. The domain name status ‘pendingRestore’ is not used in the SRS, since a restore report is a mandatory element of the restore-command.

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 .overheidnl. 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 .overheidnl 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 .overheidnl 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 .overheidnl 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, restore by non-maintaining registrar, 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 .overheidnl 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 .overheidnl 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

All core registry services for .overheidnl will be provided by .overheidnl’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 .overheidnl will be offered through the same technical infrastructure and based upon similar processes and functionalities as Whois for .NL. 

.overheidnl’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). 

.overheidnl 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 .overheidnl
The offered Whois service is RFC3912 compliant. 

Web-based 
The HTML version of the public Whois is accessible through http:⁄⁄whois.nic.overheidnl 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 .overheidnl 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 .overheidnl 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. 

.overheidnl 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 .overheidnl.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. .overheidnl will provide access for a period of 3 months with the possibility of renewal.

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

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

A depiction of the Registration Cycle for .overheidnl 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 enters ʹredemption graceʹ. 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.

Redemption Grace
Domain name has been deleted and will be in redemption grace for 40 days. Whois status is ʹin quarantineʹ. EPP status is ʹpendingDeleteʹ. During this period all accredited registrars can restore the domain for the registrant of record. A restore report is a mandatory element of the «update» command with «rgp:restore» element. The EPP-status will be ʹpendingDeleteʹ until a restore (with restore report) is submitted and the domain name is restored to the phase ʹregisteredʹ.
After expiration of the redemption grace period, the domain name will automatically become available for registration (see ʹavailableʹ above).

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

Abuse prevention and mitigation will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry. The operations for .overheidnl 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 .overheidnl 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 .overheidnl 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 .overheidnl. 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 all registrations will be authorized by the Dutch government.

28.1 Single abuse point of contact & handling of notices of abuse
The central registry operator’s website for .overheidnl 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 .overheidnl 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:

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

.overheidnl 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).

.overheidnl 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).
 
.overheidnl will further mitigate abuse by providing a Trademark Claims Service, available during the landrush and 60 days after the opening of .overheidnl 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 authorized registrant policy a sunrise would not offer any other than the authorized 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.

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

.overheidnl 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 .overheidnl registry.
At the same time it is highly unlikely under the TLD as it is an authorized registrant TLD which in this case is even the Dutch government 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 all registrations will be authorized by the Dutch government and issued to government-related registrants, the TLD will have the following approach available. 

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

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

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

With regard to rights protection .overheidnl 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 authorized registrant policy a sunrise would not offer any other than the authorized 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.

.overheidnl will evidently adhere to any other or any amended rights protection mechanisms (RPMs) that may be mandated by ICANN. .overheidnl will, except for the sunrise, include all ICANN mandated and independently developed RPMs in the registry registrar agreement. .overheidnl 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. 

.overheidnl 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 .overheidnl 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 .overheidnl 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 .overheidnl 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)

.overheidnl 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 .overheidnl, 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 .overheidnl and will be a good source for (lawyers of) rights holders to learn about the whereabouts of domain name disputes. 

30a Security Policy

The back-end registry operator for .overheidnl is SIDN, the .NL-registry. All operations for .overheidnl will be conducted by the same standards and procedures that SIDN has in place for .NL. The security policy for .overheidnl 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 .overheidnl 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.