Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.politiePolitie Nederlandvtspn.nlView
Abuse prevention and mitigation will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry. The operations for .politie will, where necessary, be conducted based on the same standards and procedures that SIDN has in place for .NL. This suits the needs of the .politie top level, which is also aimed primarily at the Dutch community.

SIDN is very proud that .NL, being the 7th largest TLD with almost 5 million registrations, is one of the safest domains according, to amongst others, these independent reports by Norton and McAfee:
Norton Cybercrime Report (2011) -http:⁄⁄www.symantec.com⁄content⁄en⁄us⁄home_homeoffice⁄html⁄ncr⁄
McAfee Mapping the Mal Web (2010) – http:⁄⁄us.mcafee.com⁄en-us⁄local⁄docs⁄MTMW_Report.pdf

SIDN is further an ISO 27001 certified organization. Security at SIDN is based on the principles of this standard and thus implemented via an Information Security Management System (ISMS) Framework. This framework provides a highly controllable security quality and risk management cycle. Abuse prevention and mitigation is an integral part of SIDN’s security policies. For more details regarding security, please see the answers provided to Evaluation Question #30 ‘Security Policy’.

What will be regarded as abuse?

Abuse has, as SIDN has seen in the 16 years as a TLD registry operator, many different forms and modes. This varies from the direct infringement of (IP)rights and cybersquatting, to unauthorized domain transfers, to registering domains with false data, but also registrars simply forgetting to change the contact information of the registrant after relocating to a new address and content issues such as phishing, malware distribution, the spreading of child pornography, et cetera.

What is regarded abuse under .NL, is defined in its general terms and conditions for the registrant. Under .politie there will be no direct contractual relation between the registry operator and the registrant and therefore the description of what is abusive will be something that the registrars need, as will be provided for in the RRA, to put in their contracts with the registrants.

In general the following will be regarded as abuse:
- The registrant infringes the technical requirements set for .politie. These technical requirements are based on ICANN’s requirements and the relevant RFC’s;
- The registrant does not provide correct name and⁄or contact details of himself or the other contacts, or fails to keep these accurate;
- The registration or the use of the domain name infringes the rights of a third party, or is unlawful or illegal in any other way;
- A domain name is transferred to another registrar or to another registrant without the authorization of the registrant.

The abuse and its mitigation referred to in this Evaluation Question is mainly focused on abusive actions from the side of the registrant, but there are all other kind of ‘abuses’ that a registry operator has to deal with. E.g. Abuse of DNS by overloading the name servers with queries, or abuse of the registration system by registrars ‘hammering’ the SRS to obtain domains falling out of redemption grace period. SIDN developed an array of procedures, technical solutions, rules and regulations to prevent these types of abuse and mitigate possible detriment. These types of abuse and mechanisms to control risks are discussed in the answers to other Evaluation Questions, such as #30 ‘Security Policy’. In the answer to this Evaluation Question, we now however focus on the registrant’s abuse as defined above.

Although abuse mitigation will be available for the TLD in line with the description underneath, abuse in the sense mentioned will be extremely unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police.

28.1 Single abuse point of contact & handling of notices of abuse
The central registry operator’s website for .politie will, on the homepage, have a clearly visible ‘report abuse’ sign where every visitor of the site may find contact details (e-mail, telephone, postal address) that may be used to report abuse. As specified in Specification 6 to the Registry Base Agreement, these details will also be provided to ICANN in the form in which ICANN would like to receive them. These contact details will all lead to the support desk of SIDN which will also make sure that upon any changes to these details ICANN will be promptly notified and the information on the registry operator’s website will be updated.

The SIDN support desk currently consists of a team of 14 highly skilled, well trained and experienced staff who handle all support questions (including abuse) and calls for the .NL TLD and the 1.3.e164.arpa ENUM delegation, also operated by SIDN. Together they serve about 1,800 registrars and about 2,7 million unique registrants. All support is provided in Dutch as well as in English.

The SIDN support desk is located at SIDN’s main office location in Arnhem and is organized in a first (9 staff) and second line (4 staff), with a dedicated manager who is a member of SIDN’s Management Team. The staff has a diverse background including experience on technical, policy and legal aspects in its ranks. The SIDN support desk has direct access to all the other specialists of SIDN who may act as a third line of support.
The primary focus of the SIDN support desk is on registrars. SIDN services around 1800 registrars for .NL, accounting for around 65% of all the incoming calls (e-mail and telephone). The SIDN support desk also has extensive experience assisting and handling abuse notices and complaints from registrants and third parties. The mission of the SIDN support desk is to help everyone as good and as fast as possible by listening to the issues and where necessary clarifying the question or complaint, providing answers, solving issues whenever possible, providing information, explanations or clarifications on policies, rules and regulations and⁄or redirecting the person involved to a more adequate internal or external source that might be able to resolve the issue. SIDN also has a legal counsel employed who is experienced in domain name law and policy matters and may support .politie where necessary and act as a liaison to ICANN.

The primary support channels for the SIDN support desk are e-mail and telephone. Post and fax are mostly used for administrative purposes but are also available for contacting the support desk. The SIDN support desk is directly reachable during SIDN office hours (Monday-Friday 08:00 – 18:00 Netherlands time, which is UTC+1). During these hours telephone calls are answered directly. When more incoming calls occur than employees are available to answer them, the calls are placed in a queue. The current planning is very adequate: telephone queues are a rare occasion and last only one minute at the maximum. The incoming e-mail calls are also queued. E-mails receive a receipt-notification with a ticket number for references immediately and are answered in maximum 2 days. The queue however is monitored constantly for urgent messages which will of course be given the necessary priority. The SIDN support desk is further reachable 24⁄7 for registrars through a voicemail system for reporting technical disturbances and critical problems. Reports of critical problems outside office hours are responded to within 30 minutes.

The SIDN support desk works with a CRM-system to log in detail all calls and responses. This system can provide extensive differentiated reports (e.g. source, channel or type).

All calls received via whatever media including all abuse notices are screened for urgency during working hours and handled accordingly.

The desk further utilizes clear and extensive work instructions that provide baseline texts that may be used depending on the specific situation and assist the staff in handling the more or less regular or frequently asked questions. These work instructions are drafted by the staff of the desk in conjunction with the necessary technical, procedural and legal specialists. The work instructions are constantly being reviewed to keep them up to date. Amongst others, specific work instructions are available for handling notices of incorrect WHOIS information and other abuse notifications. The work instructions are available in Dutch and can be provided if requested.

SIDN participates in various partnerships that deal with IT security, like for example the Dutch National Cyber Security Centre (NCSC). This enables us to quickly engage into a nationwide coordination with the NCSC and Dutch ISP’s in case of security incidents. It also provides us with a network for sharing information regarding malicious or abusive behaviour with industry partners and eventually engage in a rapid takedown or suspension of a domain name through what’s called a ‘Notice-And-Take-Down’ agreement (http:⁄⁄www.samentegencybercrime.nl⁄NTD⁄NTD_English?p=content). SIDN has a Security Officer (CSO) and a Computer Security Incident Response Team (CSIRT; formed in 2004) with experts from various disciplines within the organization. This team acts as a ‘quick reaction force’ in case of a security incident related to the registry- and DNS functions of SIDN. (See the answers provided to Evaluation Question #30 ‘Security Policy’ for more detailed information.)

On a non-formalized basis SIDN, being the ‘de facto’ national Dutch registry, has many direct and warm contacts with Law Enforcement, Government and members of the technical community on different levels. In the case of extreme urgent matters SIDN may and will be reached 24⁄7 and is fully capable to take any action necessary.

28.2 Mitigating abuse in general

Mitigating abuse will be done by a series of different measures:

.politie will first of all, as described above, have a central abuse contact published and available and an professional experienced support department ready to handle any abuse notices.

.politie will further mitigate abuse by taking technical measures to make sure that certain types of abuses simply cannot occur. For example, the registration system will not allow registration attempts of domains with a length of less than 2 characters or more than 63 (one of the technical requirements) and makes it technically impossible to register names on the excluded names list. Types of abuse that cannot be completely prohibited, will be made less likely through technical controls (e.g. by the obligatory use of the AuthInfo Code for domain name transfers).

.politie will also implement automated signalling systems to inform the registrars of possible abusive behaviour of the registrants, for example via reports from what is called the ‘DNS Crawler’ and an alerting system to registrars for domains that are being used in Phishing. (See ‘3. Infringement of technical requirements’ below).

.politie will further mitigate abuse by providing a Trademark Claims Service, available during the landrush and 60 days after the opening of .politie for registrations, and supporting UDRP and URS. More detailed information on this and the other rights protection measures mentioned will be provided in the answer to Evaluation Question #29 ‘Rights Protection Mechanisms’. The TLD will however not organize a sunrise. Given the single registrant policy a sunrise would not offer any other than the single registrant an opportunity to register domain names and would therefore be entirely irrelevant for the protection of third party trademark rights. It may clear that a Dutch governmental organization as the applicant will not register⁄use infringing domain names. Because the TLD recognizes the importance of the protection of trademark holders in the current expansion, the TLD is entirely prepared to adopt that Trademark Claims Service and the other RPM’s although it may be clear that these will never be used with regard to this TLD.

.politie will next to the forgoing inform and educate the public with regard to possible abuse issues, the availability of remedies and the how and where to obtain these in detail via its website, apart from the clear notice of the abuse contact and how to contact them.

.politie will further pick the fruits of using SIDN as the back end provider as SIDN is in its role as the .NL registry already constantly working on the enhancement of the trust in the .NL-domain environment and in that respect working hard to prevent and mitigate abuse and develop new methods, policies, practices and measures to fight abuse.

28.3 Specific abuse policies

In the above the overall approach towards abuse has been described. Underneath please find a more detailed description of policies and mitigation measures in place. As said a detailed description of the rights protection measures already named in the above is to be found in the answer to Evaluation Question #29. All measures described below will also be made available for the .politie registry.
At the same time it is highly unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police that abuse as described in this answer to happen.

28.3.1 Incorrect Whois details
Although incorrect Whois details will be extremely unlikely under the TLD as it is a single registrant TLD which in this case is even the Dutch National Police the TLD will have the following approach available.

.politie will follow in principle the same rules and regulations SIDN does for .NL with regard to registering domains and providing correct registration data. This means that the registrant will have a contractual obligation to present correct information and to keep the information correctly updated during the full registration period. The registrars will further have a contractual obligation to take all reasonable steps to ensure the accuracy of the registered data and the traceability of the registrant or party that commissioned the registration. The registrar shall not register any data that the registrar knows or suspects to be inaccurate and shall, upon independently ascertaining or learning from SIDN or a third party that an item of registered data is inaccurate, immediately replace the data in question with accurate data. If requested to do so by SIDN, the registrar shall provide evidence of the accuracy of the registered data. Under ICANN’s ‘Whois Data Reminder’ Consensus Policy, registrars are obliged to at least annually present to the registrant the current Whois information, and remind the registrant that provision of false Whois information can be grounds for cancellation of their domain name registration. Registrants must review their Whois data, and make any corrections.

.politie will have a procedure available to handle notices of possible incorrect Whois details which will be a version of the current procedure used by SIDN. For .NL SIDN has a detailed script with regard to the actions to be taken upon the receipt of an abuse notification. In general SIDN will contact the registrar and request the registrar to verify the alleged incorrect information and have the registrant provide proof of the correctness of the alleged incorrect information. In general the registrant is provided the opportunity to update incorrect information but will have to provide proof of the correctness of the updated information. The registrant will not be given this chance if the information provided is clearly or purposely incorrect. In that case SIDN will cancel the registration.

28.3.2 Infringement of technical requirements (including orphan glue records)
SIDN requires registrants to obey the rules set out in a ‘technical requirements document’ that defines minimal technical requirements for the registration (and delegation) of .NL-names (in the DNS). The current version of this .nl-document that will be updated for .politie is attached to the answer of this question.

Most of the technical requirements are enforced by technical controls in the shared registration system. Other requirements are checked once the domain is delegated, by means of an in-house developed tool called the ‘DNS crawler’. This tool produces monthly feedback on the DNS quality of the domain names registered to registrars. It also reports violations of the technical requirements and DNS errors to registrars and to our compliance monitoring team. The specifications to this tool are provided as an attachment (Q28-DNS_Crawler_Specifications’).

The Shared Registry System has controls in place, at several layers, to prevent so called ‘orphaned glue records’ as is mentioned in the SSAC comment on Orphan Glue Records in the Draft Applicant Guidebook (SAC048). The controls preventing orphaned glue records are described below.
When malicious conduct on domain names is verified, the procedure ‘Notice-And-Take-Down’ is started (see ‘4. Unlawful or criminal use of a domain name’ below). This procedure handles the take down of domain names on which malicious conduct finds place. SIDN is also on the NXDomain mailing list to track requests for take down of domain names. Furthermore, SIDN takes part in the Conficker working group.

Detailed information on Orphaned Glue
With respect to orphaned glue, the following controls are in place to mitigate the danger of having orphaned glue:
- When a domain name is deleted from the Shared Registry System, the domain name is going into redemption grace for 40 days. During this period no changes can be made to the registration, and the only possible transaction is restoring of the domain name.
- If no restore transaction has been done, after these 40 days, the registration will be deleted and the domain name becomes available for registration. Upon deletion of the registration, all sub ordinate host objects are also deleted in the Shared Registry System, possibly leaving other registered domain names depending on these hosts with less than the minimum required number of name servers.
- If a registered domain name is left with no linked hosts (name servers), the registration status will be inactive, and the domain name will not be included in the zone file. This approach is in line with policy 3 of SAC048, section 4.3.
Apart from these controls, additional checking of the zone file is in place, including checks on orphaned (and missing) glue records. See the answers provided to Evaluation Question #35 ‘DNS’ for more details.

Registrars will be informed about their registrations with less than the minimum required number of name servers through the monthly reports sent out by the ‘DNS crawler’ (see ‘3. Infringement of technical requirements’ above).
When a domain name has no linked host objects (registration state is inactive), the registrar will be directly notified and asked to correct this situation.

28.3.3 Phishing feed
Under .NL SIDN has a fully automated phishing feed that provides for a fast signalling of and action against phishing attempts under .NL-domain names.
SIDN has agreed a deal with Netcraft (http:⁄⁄news.netcraft.com⁄), an internet security authority that for several years has offered a wide range of services aimed at eliminating internet fraud, including phishing. It was Netcraft, for example, who developed the Anti-Phishing Toolbar that many internet users now rely on to check the authenticity of websites. The toolbar provides Netcraft with an enormous volume of data, which they are then able to make available to clients.

Every five minutes or so, SIDN checks Netcraft’s suspect URL database, which is constantly being updated. Every time a .nl URL is added to the database, an e-mail message is automatically sent to the relevant registrar’s administrative contact e-mail address. In other words, the system does not rely on periodic reporting, but on almost immediate individualised e-mail contact. It therefore provides a basis for very rapid intervention.

The e-mail sent to draw a registrar’s attention to the fact that a client is running a website that may be fraudulent will include the following information:
- Suspected phishing site URL
- Host: the IP address of the system running the website
- Country: the country of origin of the IP address
- Date: the date and time that the suspect site was detected
- Target: the name of the company that seems to be targeted

As the registrars only receive information that is specifically relevant for them and their customers, these e-mails receive high attention and usually lead to swift actions from the registrar, ending the phishing attempts.
gTLDFull Legal NameE-mail suffixDetail
.amsterdamGemeente Amsterdamamsterdam.nlView
Abuse prevention and mitigation will be nearly entirely outsourced to the applicant’s back end provider SIDN, the .NL-registry. The operations for .amsterdam will be conducted based on the same standards and procedures that SIDN has in place for .NL. This suits the needs of the .amsterdam 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 .amsterdam 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 .amsterdam. 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.

28.1 Single abuse point of contact & handling of notices of abuse
The central registry operator’s website for .amsterdam 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 .amsterdam 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 the ‘Notice-And-Take-Down’ procedure (see ’28.3.1 Incorrect WHOIS details’ and ’28.3.4 Unlawful or criminal use of a domain name’ below). 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. 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:

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

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

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

.amsterdam will further mitigate abuse by holding a sunrise before the start of the landrush, provide a Trademark Claims Service, available during the landrush and 60 days after the opening of .amsterdam for registrations, and supporting UDRP and URS. Next to that .amsterdam will implement a variant of the current .NL- ‘Dispute Resolution System for .NL Domain Names’. This resolution procedure (a UDRP variant administered by WIPO) serves as a mechanism for settling disputes that concern trademarks, trading names, the names of governmental and other bodies and personal names. Disputes are settled by impartial legal experts, who are specialists in this field. The Dutch language is supported in this resolution procedure. 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’.

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

.amsterdam 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 .amsterdam registry.

28.3.1 Incorrect Whois details
.amsterdam 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.

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

SIDN is currently actively investigating the possibilities to implement an active and on-going Whois accuracy check at the registry level. If and when this will be implemented for .NL, .amsterdam will investigate the possibilities to implement this for .amsterdam too. Incorrect information found will then be presented to the sponsoring registrars and proceedings will follow the path described above.

28.3.2 Information requests by law enforcement
Law enforcement agencies may require for example historical registrant data or other registration data. Dutch law provides for a number of different grounds to force a registry to provide such information and SIDN has a clear notice what these grounds are, how these requests have to be provided and how they have to be handled. In practice the General Counsel of SIDN more than once assisted law enforcement in directing them to the correct articles in the law. SIDN of course makes sure that these requests are handled with due care and within the timeframes provided by law. SIDN is currently working on a detailed work instruction so that the correct handling of these requests is clearly described and documented.

28.3.3 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 .amsterdam 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.4 Unlawful or criminal use of a domain name
SIDN is one of the prime movers behind the Dutch ‘Notice-And-Take-Down’ Code (http:⁄⁄www.samentegencybercrime.nl⁄NTD⁄NTD_English?p=content). Developed in 2008 under the auspices of the former NICC (National Infrastructure against Cybercrime), the Code, a form of voluntary industry self-regulation, describes how Dutch Internet service providers should respond if someone complains that the content of a website is unlawful or criminal. SIDN advocates use of the Code by its registrars and by other ISPs around the world. SIDN has implemented its own variant of the Notice-And-Take-Down Code.
The Notice-And-Take-Down code is provided as an attachment to this answer (‘Q28-NTD’).

The legal basis for Notice-And-Take-Down is article 21 in SIDN’s general terms and conditions:

21.1. If SIDN is of the opinion that a .nl domain name that has been brought to its attention is being used in an unlawful or criminal manner (for example, to publish unlawful or criminal content on a website), SIDN shall be entitled to immediately remove the .nl domain name temporarily or permanently from the zone file, unilaterally terminate its registration and take any other action that SIDN considers necessary at the time.

21.2. Any party that believes that a .nl domain name is being used in an unlawful or criminal manner may draw the matter to SIDN’s attention by following the Notice and Take Down Procedure published at www.sidn.nl. SIDN shall deal with any such report in the manner described in the said procedure.

21.3. SIDN shall not be liable either towards the registrant or towards any third party for any damages suffered as a result of any act or omission in the implementation of this article.

Being the registry, SIDN’s role in the context of Notice-And-Take-Down (NTD) is limited. It is an ultimate last resource measure available for clear cut cases. The procedure is detailed in the Notice-And-Take-Down Code for .NL domain names. The current .NL version is attached to the answer to this question (‘Q28-NTD_NL’).

Via the NTD procedure anyone can first of all obtain contact details of the registrant in the case of obvious unlawful or criminal use of a domain name. Under .NL this is important as the Whois does not publish the contact details of the registrant. Under .amsterdam this of course isn’t an issue and the procedure will be amended to exclude this part.

Secondly and for .amsterdam more relevant, anyone can request the registry to actually take down a domain name in the case of obvious unlawful or criminal use of that domain name. Take down would in this case mean removing the domain from the published zone file. Ultimately SIDN may decide to end the entire registration of the domain.

As said it is an ultimate last resort action. The Dutch NTD Code is based on the principle that the person or organization that has most control over the content should be approached first. If that person or organization does not respond or refuses to take down the content, the matter should be taken up with the person or organization with the next most control, and so on. The registry does of course have no control over the content published via the use of the domain and can only render the domain registration inactive, not take the related information off the internet. Take downs on a registry level are therefore (also because of DNS caching issues) usually not very effective. Secondly these take downs are not quite subtle as they do not target any specific illegal or criminal information on a website but completely blocks the use of a domain. Because of all these reasons, it is extremely rare for SIDN to take down domains. On the other hand it is a very strong signal that the .NL-registry implemented the Dutch code. Most notices received so far are redirected to registrars, hosting providers or the registrant and sufficiently solved by these parties.

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