28 Abuse Prevention and Mitigation

Prototypical answer:

gTLDFull Legal NameE-mail suffixDetail
.sncfSociété Nationale des Chemins de fer Francais S N C Fsncf.FrView

Abusive registration and other activities that have a negative impact on internet users
1. Overview
2. Whois Abuse Prevention Policies
2.1 Whois Accuracy
2.1.1 Syntax and semantic registration constraints
2.1.2 Verification tools
2.1.3 Whois Data Reminder Policy (WDRP)
2.2 Protection against unfair use of Whois service
2.2.1 Protection against Data Mining Captcha Rate-limiting
2.2.2 Prevention of Unauthorized data modification
3. Prevention from other abusive conducts
3.1 DNSSEC (cache poisoning)
3.2 Domain name Sniping (grabbing)
3.3 Domain name tasting
4. Disposal of Orphan Glue Records
5. Single Abuse Point of Contact
6. Policies for handling complaints regarding abuse
6.1 Abuse case response
6.2 Rapid Takedown Policy for Cases of General Malicious Activity
6.3 Rapid Takedown Policy for Cases of Phishing
6.4 Trademark abuse
7. Resourcing Plans

8. SNCF’s Draft Registration Policy

1. Overview
The applicant’s objective in answering question 28 is to provide a thorough explanation of its policies and procedures to minimize abuse registration and other activities that have a negative impact on internet users.

Protection of the internet users is a core value of the project and is key to insuring the user experience as described in question 18 (b) iii. By implementing anti-abuse policy the registry will also contribute to protecting the integrity, security and stability of the Domain Name System (DNS).

As stated in response to Question 18, the applicant’s registration policy will address the minimum requirements mandated by ICANN including abuse prevention measures. The applicant intends to operate the .SNCF registry using strict eligibility criteria. This will significantly lower the risk of abuse in the .SNCF registry. The applicant’s draft registration policy is attached to this response.

Definition of abuse
The applicant defines abuse as an action that causes actual and substantial harm, or is a material predicate of such harm, and is illegal, illegitimate, or otherwise contrary to registration policy. Abuse includes, without limitation, the following:
Content or actions that attempt to defraud members of the public in any way (for example, ʺphishingʺ sites);
Content that is hateful, defamatory, derogatory or bigoted based on racial, ethnic, political grounds or which otherwise may cause or incite injury, damage or harm of any kind to any person or entity;
Content that is threatening or invades another personʹs privacy or property rights or is otherwise in breach of any duty owed to a third party;
Content or actions that infringe the trademark, copyright, patent rights, trade secret or other intellectual property rights, or any other legal rights of BOSCH or any third party;
Content or actions that violate any applicable local, state, national or international law or regulation;
Content or actions that promote, are involved in or assist in, the conduct of illegal activity of any kind or promote business opportunities or investments that are not permitted under applicable law;
Content that advertises or offers for sale any goods or services that are unlawful or in breach of any national or international law or regulation; or
Content or actions associated with the sale or distribution of prescription medication without a valid prescription;
Content that depicts minors engaged in any activity of a sexual nature or which may otherwise harm minors;
Activities that mislead or deceive minors into viewing sexually explicit material;
Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to e-mail spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of Web sites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
Phishing: The use of counterfeit Web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through Domain Name System (DNS) hijacking or poisoning;
Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. - Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses;
Botnet command and control: Services run on a domain namethat are used to control a collection of
illegally compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks); and
Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

The .SNCF registry is committed to create and implement policies and procedure that prevent abusive registrations and other activities that have a negative impact on internet users. In line with the industry best practises presented in the Registration Abuse Policies Issues Report (ICANN 2008), the .SNCF registry will offer a wide range of effective safeguards to prevent abusive uses of domain names such as phishing, spamming, and also unlawful or fraudulent actions. The registry operator will regularly update these policies and procedures in order to maximize its readiness to deal with new threats at all levels and new forms of abuse.

Prevention starts at the time of registration, Whois accuracy (see below in 2) is therefore the first and main focus of the .SNCF registry prevention policies. The following answer describes in details the mechanisms in place to maximize Whois accuracy. Others mechanisms (see below in 3) will be implemented and described here, including management of orphan glue records (see below in 4).

In addition to strong preventive measure against various forms of abuse, the .SNCF registry will implement mitigation policies to address actual cases of abuse that may occur. This answer will describe these mitigation measures in detail: single abuse point of contact (see below in 5), complaint handling policy and takedown procedures (see below in 6).

Resources allocated to handle prevention and mitigation will be described at the end of this answer (see below in 7).

2. Whois Abuse Prevention Policies

2.1 Whois Accuracy

RFC3912 specifies the Whois protocol and explain it as follows:

Whois is a TCP-based transaction-oriented query⁄response protocol that is widely used to provide information services to Internet users. While originally used to provide ʺwhite pagesʺ services and information about registered domain names, current deployments cover a much broader range of information services. The protocol delivers its content in a human-readable format.

Information about registered domain names contains very sensitive data. A Registry Operator shall insure the accuracy of the registrant contact information, including administrative, technical and billing contact details. In case of malicious or abusive activity, the Whois contact listed in the Whois database is usually the first and most important source of information. Whois accuracy is therefore a major tool to counter malicious conducts. Whois information may also be required by law-enforcement authorities to identify individuals and organizations responsible for domain names.

The .SNCF registry will make a firm commitment to obtaining true and accurate registration details from each registrant in line with the eligibility criteria in its draft registration policy.

2.1.1 Syntax and semantic registration constraints:

The .SNCF registry is firmly committed to run a “thick-registry” with high quality of data. The first step to accuracy is achieved through syntax and semantic checks.

Standard EPP checks: a first set of tests is implemented in compliance with standards:
- RFC 5733, the Extensible Provisioning Protocol (EPP) Contact Mapping, requires contact data to contain a name, a city, a country code and an e-mail address for a syntactically complete EPP request

- RFC 5731, the Extensible Provisioning Protocol (EPP) requires domain object to have at least one associated status value, Date and time attribute values to be represented in Universal Coordinated Time (UTC) using the Gregorian calendar and Validity periods to be measured in years or months with the appropriates units specified using the ʺunitʺ attribute.

- RFC 5732, the Extensible Provisioning Protocol (EPP) requires host object to have at least one associated status value

Additional checks: the following syntax checks are implemented:
- a test to ensure that the domain name has the proper number of labels (which is two for a traditional registry that allows only second level domains to be registered),
- a test to ensure that no hyphens occur in position 3 and 4 of any of the domainʹs U-labels (to protect ʺxn--ʺ and future ACE prefixes),
- a test to disallow hyphens at the beginning or end of the name,
- a test to find ASCII characters which are neither a letter, nor a digit or a hyphen,
- a test to find invalid IDN characters, i.e. characters not contained in any of the support IDN character tables
- a test to validate IP address format using the following scheme:
〈ipv4-addr〉 [1-255](\.[0-255]){3,3}
〈ipv6-addr〉 [a-fA-F0-9:]+(:〈ipv4-addr〉)?
- a test to validate telephone and mail format using the following scheme (with specific tests for fr numbers):
〈num tel〉 \+[1-9][0-9]{0,3}〈sp〉[1-9]([〈sp〉\.-]?[0-9])+
〈num tel fr〉 \+33〈sp〉[1-9]([〈sp〉\.-]?[0-9]){8}
〈e-mail〉 (([^\s\(\)\[\]\.\\〉〈,;:ʺ@]+(\.[^\s\(\)\[\]\.\\〉〈,;:ʺ@]+)*)|(ʺ[^ʺ@\\\r\n]+ʺ))@〈label〉(\.〈label〉)*

Additional checks: the following semantic checks are implemented:
- a test to disallow reserved names if authorisation code is not present
- a test to disallow registry reserved names if authorisation code is not present
- a test to disallow ICANN reserved names
- a test to disallow otherwise reserved or unsuitable names
- a test to ensure that at least one address element is given

2.1.2 Verification tools
This verification procedure is designed to guarantee the reliability and the accuracy of the Whois database. The .SNCF registry will conduct Whois accuracy verification for compliance with criteria concerning the reliability of registrants’ identification: in line with the registration policy, the registry will verify whether the information provided by the registrant when registering the domain name contains inaccurate or false information about the registrantʹs identity.

Those verifications will be carried out on a random basis or following a third-party request.

The registry may ask registrars for additional information or documents, including the production of documentary evidence of compliance with the reliability of the data provided by the registrant if the registry is in possession of documentary evidence indicating inaccurate registrant information (mail returned marked “Not Known at This Address”, bailiff’s report, unidentifiable address, etc.).

A domain name may be blocked under the following circumstances: when a check of the identification data provided by the registrant shows that it is inaccurate or that the registrant is not eligible to register a domain name in the .SNCF registry.

A domain name may also be deleted as a result of such a procedure. The deletion of a domain name can only occur after the registrant has been formally asked to rectify the situation and to modify its registration data to comply with eligibility criteria.

During the redemption period, the domain name can be reactivated with the same configuration. Once deleted, the domain name will re-enter the public domain and can be registered by a new applicant provided the new applicant meets the eligibility criteria.

2.1.3 Whois Data Reminder Policy (WDRP)

In 2003, ICANN adopted the ʺWhois Data Reminder Policyʺ (WDRP, http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm) which obliges ICANN-accredited registrars to send yearly Whois data reminder notices to registrants. These notices contain the Whois data currently on file for the respective domain, as well as instructions for the registrant about ways to correct the data if required. While the .SNCF registry does not intend to replicate this reminder procedure at the registry level, it will require its accredited registrars to comply with the policy.

2.2 Protection against unfair use of Whois service

As stated above, the Whois Service gives access to sensitive data, including contact details of registrants. The .SNCF registry is committed to insure the protection of these data against abusive behaviours. Firstly, the .SNCF registry will implement technical measures to prevent data mining on the Whois, such as automated collection of registrants’ email addresses that may result in spamming. Secondly, the .SNCF registry and its registry backend service provider, AFNIC, will deploy all necessary means to secure access to its database, specifically by implementing procedures in order to prevent Unauthorized Data Modifications. These procedures will reinforce the security of both EPP and Web-based access to Whois data.

2.2.1 Protection against Data Mining

The user of the .SNCF Whois database must commit to using the published data in accordance with relevant laws and regulations. Furthermore, the user must respect the provisions of the French Data Protection Act (Loi informatique et liberté N°78-17 du 6 janvier 1978 modifée). Violation of this act carries criminal penalties.

The user must refrain from any data collection, misuse or any act that could lead to invasion of privacy or damaging the reputation of individuals.
The Registry may at any time filter the access to its Whois services if it suspects malicious use of the Whois service. Completely Automated Public Turing test to tell Computers and Humans Apart (Captcha): users shall pass a Captcha before access is granted to the web based Registration Data Directory Services (RDDS) WHOIS Service. Rate-limiting: The registry has chosen to impose limitation measures on the number of Whois requests that can be made in order to prevent abuse in the use of personal data and to guarantee the quality of the service.
Through a transparent parameter adjustment policy, the registry guarantees quality of service to both occasional users and professionals. The rates and thresholds of this system are described in the answer to question 26. White list: The white list mechanism offers dedicated access for registrars to the port 43 Whois where the incoming traffic must come from two pre-defined IP addresses. This white list access offers higher limit thresholds for registrars.

2.2.2 Prevention of Unauthorized data modification

Data modification is managed through strict authentication and access policies:
- the SSL⁄TLS protocol is used on all interfaces with clients (both EPP and web based SRS),
- a password policy is applied both on the password itself (minimum length, mandatory digits and non-alphanumerical characters), and on the live length of the password,
- the use of an SSL client certificate pre-installed by the registry for EPP access,
- IP authentication limited to two addresses.
The .SNCF registry backend registry services provider, AFNIC, will leverage its experience from operating the French country code TLD (ccTLD), .fr to ensure effective, timely and sufficient Domain Data Access Control.

3 Prevention from other abusive conducts
As indicated above, the applicant will put in place strict eligibility criteria which must be met in order to register domain names in the .SNCF registry. This means that the risk of abuse will be low. The applicant will however put in place the mechanisms below to further mitigate the risk of abuse.

3.1 DNSSEC (cache poisoning):
One of the main authentication issue encountered on the DNS is cache poisoning issue. This directly impacts on data flow at the DNS service level without corrupting or modifying data in the registry database.

Cache poisoning may be addressed by implementing DNSSEC. The registry operator’s registry back-end registry services provider, AFNIC already successfully manages a DNSSEC-enabled zones: on September, 29th 2010, AFNIC, finished adding its 6 ccTLDs key materials (DS records) into the IANA root zone, for domain names ending with .FR. This was achieved after extensive tests with its other TLDs to ensure a smooth well-functioning service. Since then, related DNSSEC operations and monitoring are spread inside AFNIC, alongside all other standard day to day operations, so that DNSSEC is a core service used by default.

3.2 Domain name Sniping (grabbing):
Domain name sniping refers to the practice of trying to re-register potentially interesting domain names immediately after they are deleted.
The .SNCF registry supports the Redemption Grace Period as proposed by ICANN and implements it in full compliance with RFC 3915 (ʺDomain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)ʺ). This greatly reduces the possibility of a domain name being “forgotten” by its registrant. The .SNCF registry’s registration policy should limit the risk of domain name sniping.

3.3 Domain name tasting:
Domain name testing is a practice using the 5-days Add Grace Period (AGP) during which a newly created domain name may be deleted with a refund of the domain fee to check if the domain name is of interest or not. AGP is a policy in place for all generic TLDs and therefore domain name tasting has to be dealt with. . The .SNCF registry’s registration policy should limit the risk of domain name tasting.

In 2008, ICANN introduced the ʺAGP Limits Policyʺ (http:⁄⁄ www.icann.org⁄en⁄tlds⁄agp-policy-17dec08-en.htm) which addresses these issues resulting from the Add Grace Period. The [-TLD-] TLD, will fully implement this policy by restricting Add Grace Period refunds to registrars according to the limits specified by the policy.

The number of operations concerned are included in ICANN reports and related report columns, as specified in Specification 3 of ICANN Registry Agreement :
domains deleted within the add grace period (ʺdeleted-domains-graceʺ)
total number of AGP exemption requests (ʺagp-exemption-requestsʺ)
total number of AGP exemptions granted (ʺagp-exemptions-grantedʺ)
total number of names affected by granted AGP exemption request (ʺagp-exempted-domainsʺ)

4. Disposal of Orphan Glue Records
According to the definition found in the ʺSSAC Comment on the Orphan Glue Records in the Draft Applicant Guidebook”, a glue record becomes an ʺorphanʺ when the delegation point Name Server record (the ʺparent NS recordʺ) that references is removed while retaining the glue record itself in the zone. Consequently, the glue record becomes ʺorphanedʺ since it no longer has a parent NS record. In such a situation, registrars and registrants usually lose administrative control over the record, and the recordʹs attribution to a certain registrar may become unclear, which makes it a potential vector for abuse.

The glue record policy in effect for the .SNCF registry avoids this situation entirely by disallowing orphan glue records altogether. This corresponds to policy #3 mentioned in section 4.3 (page 6) of the SSAC document mentioned above. The technical implementation within the Registry and its associated zone generation process ensures this through the following measures:

- Any host object which is a glue record can be created only if the domain name exist and is sponsored by the registrar creating the host,

- Any deletion of a domain name which has subordinate hosts can be done only when these hosts are deleted. If these hosts are used in delegations for other .SNCF domain names, these delegations have to be removed to delete the host objects and then the domain name.

If the sponsoring registrar of the domain name cannot remove these delegations (explicit refusal or inactivity from subordinate hosts registrars), the situation can be resolved by making a direct request to the registry. Upon such a request, the registry will contact the domain name(s) registrars which were used in the delegation the host object(s) and ask them to remove the delegations. Registrars have 10 days to remove these delegations, after which time if there is no removal of delegation, the registry will deactivate the DNS configuration of the domain name(s) concerned. At the end of the procedure, the registry will contact the sponsoring registrar to inform the registrar that the host object(s) and the domain name can be deleted.

5. Single Abuse Point of Contact
To avoid abusive registration practices, the .SNCF registry will provide internet users with a single point of contact on its website to receive reports of any abuses such as phishing, spamming, trademark abuse etc.

This single point of contact will enable a quicker and better management of complaints. Complaints can be lodged by filling out a form through an online web interface on the .SNCF registry web site

A dedicated team will be in charge of handling the complaints in a a timely manner. All requests should be acknowledged and processed within 24 hours. According to the nature of the reported abuse (phishing, spamming, trademark abuse, etc), appropriate action will be taken by the .SNCF registry.

Moreover, Internet users will be given access to all necessary information regarding remedies to abusive online conducts on the registry Single Abuse Point of Contact webpage. The single abuse point of contact webpage will also contain links to other relevant organizations addressing these issues.

6. Policies for handling complaints regarding abuse
6.1 Abuse case response

The registry will process each complaint within 24 hours and will take all the necessary steps to provide a satisfactory answer to the complainants.

Should immediate action need to be taken by competent authorities (e.g. law enforcement authorities), the .SNCF registry is committed to alert such authorities without delay. As the leading French registry, AFNIC the back-end registry services provider, has a proven record of handling such cases and will continue to work closely with relevant authorities. This may involve, but is not limited to, the following cases:
Court orders,
Inquiries from law enforcement bodies (e.g, OCLCTIC - The Office central de lutte contre la criminalité liée aux technologies de lʹinformation et de la communication is the French Police unit specialized in cybercrime),
Anti-phishing groups (e.g, CERTs).

6.2 Normal Takedown Policy for Cases of Normal Malicious Activity
The .SNCF will put in place a detailed policy for managing normal cases of malicious behaviour such as spam prior to the launch of the .SNCF registry.
6.3 Rapid Takedown Policy for serious cases of abuse
The .SNCF registry will put in place a detailed policy for managing serious cases of abuse such as phising or abuse which threatens the technical operations of the Registry or which may have a serious impact on the Internet. These serious cases of abuse will be managed through a rapid process where the domain name may be suspended to mitigate the impact of the abuse and to allow for further investigation.
6.4 Trademark abuse
The registry understands and agrees that it must comply with the different rights protection mechanisms such as the Uniform Domain Name Dispute Resolution Policy (UDRP) and the Uniform Rapid Suspension System (URS) as described in the gTLD Applicant Guidebook (as may be later amended via Consensus Policy) and the Registry Agreement. The policies for addressing these forms of abuse are described in the response to question 29.

7. Resourcing Plans
.SNCF registry has effectively mitigated the risk of abuse in the gTLD and foresees allocating a member of staff to act as the primary points of contact for handling inquiries relating to malicious or abusive conduct in the TLD. The .SNCF registry is committed to ensuring that sufficient resources are made available at all times.

The .SNCF registry’s back-end registry services provider AFNIC, provides the following resources
Initial Implementation: Thanks to the experience and prior investment by its Registry Back-end Service Provider (AFNIC), the .SNCF registry already supports the above mentioned technical abuse prevention and mitigation measures. No additional engineering is required for these, nor are additional development resources needed.

Ongoing maintenance: In support of the Registry Operator’s staff allocated to this function, AFNIC will have specially trained support staff available to assist in the implementation of potential verifications and takedown procedure for the prevention and resolution of potential abuse. Given the scale of the .SNCF registry as well as the restrictive nature of its registration policy, we estimate that this would require no more than 10 man days per year of AFNIC’s anti-abuse support staff.



Upon registration of a Domain Name, the Registrant holds a licence to use the Domain Name for a specified period of time in accordance with the Registry Rules. Domain Names may be registered and renewed for 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10 years.


Registrars eligible to register domain names must meet the following non-discriminatory criteria (in compliance with clause 2.9 (a) of the Registry Agreement):
(i) be an accredited ICANN Registrar;
(ii) demonstrate a level of understanding of the Domain Name registration policies of the Registry;
(iii) have experience of managing the Domain Names of major corporations;
(iv) have proven tools for domain name portfolio management;
(v) have business processes to perform automated validation (and any additional human checks as required by the Registry) of the eligibility of the domain name for registration according to the Domain Name policies of SNCF;
(vi) demonstrate a sufficient level of security to protect against unauthorised access to the Domain Name records;
(vii) demonstrate experience and have appropriate resources in managing abuse prevention, mitigation and responses;
(viii) provide multi-language support for the registration of IDNs;
(ix) comply with any re-validation of its Registry-Registrar agreement at such regular intervals as are determined by the Registry or as required by ICANN from time to time;
(x) meet applicable technical requirements of SNCF; and
(xi) comply with all conditions, dependencies, policies and other requirements reasonably imposed by SNCF, including maintenance of suitable systems and applications that are capable of interacting with the Registry system.


The Registrant must be:
(i) an Affiliate entity of SNCF; or
(ii) an organisation explicitly authorised by SNCF; or
(iii) a natural person explicitly authorised by SNCF.
If the Registrant does not meet one of the above eligibility criteria, there is no entitlement to register a Domain Name under the sncf gTLD. If the Registrant ceases to be eligible at any time in the future, the Registry may cancel or suspend the licence to use the Domain Name immediately.


Registration of Domain Names under the sncf gTLD must be approved by SNCF in addition to meeting all requirements under the Registry Rules. SNCF’s approval for a complete and validly submitted application will be authorised by:
(i) a head of appropriate department as nominated by SNCF (“Authorisation Provider”); or
(ii) an authorised person as nominated by SNCF (“Authorised Person”) and notified to the Registrar from time to time.
The Authorisation Provider will notify the Registrar of its decision.


An application for Domain Name registration must meet all the following criteria:
(i) availability;
a. the Domain Name is not already registered;
b. it is not reserved or blocked by the Registry; or
c. it meets all Registry’s technical requirements.
(ii) technical requirements;
a. a maximum of 63 characters (after its conversion into the ASCII for IDNs);
b. use of characters selected from the list of supported characters as nominated by the Registry; and
c. any additional technical requirements as required by the Registry from time to time.
(iii) the Domain Name must be consistent with the mission and purposes of the gTLD and consistent with the Domain Name registration policy of SNCF, and include but not be limited to:
a. product name;
b. service name;
c. marketing term;
d. geographic identifier; or
e. any relevant name or term as approved by Authorisation Provider or Authorised Person.
(iv) compliance with all requirements under the Registry Rules: the Registrant must comply with all provisions contained in the Registry Rules.


The Registrant must enter into an agreement with the Registrar for Domain Name registration under which the Registrant will be bound by the Registry Rules specified through the Registry-Registrar agreement as amended by the Registry from time to time.

The Registrant must also agree to be bound by the minimum requirements in clause 3.7.7 of ICANNʹs Registrar accreditation agreement.

The Registrant must represent and warrant that:
(i) it meets, and will continue to meet, the eligibility criteria at all times and must notify the Registrar if it ceases to meet such criteria;
(ii) the registration, renewal and use of the Domain Name does not violate any third party intellectual property rights, applicable laws or regulation;
(iii) it is entitled to register the Domain Name;
(iv) the registration and use of the Domain Name is made in good faith and for a lawful purpose;
(v) if the use of registered Domain Name is licensed to a third party,
a. the Registrant must have a licencing agreement with the licensee for the use of the Domain Name that is not less onerous than the obligation of the Registrant contained in the Registry Rules; and
b. where there is a breach of any provisions contained in the Registry Rules by the licensee of the Domain Name, Registry may revoke the Domain Name at its sole discretion.
(vi) it owns or otherwise has the right to provide all registration data (including personal information) for each Domain Name registered and provision of such registrant data complies with all applicable data protection laws and regulations; and
(vii) It has appropriate consent and licences to allow for publication of registration data in the WHOIS database.


The Registrant must provide complete and accurate contact information of the Registrant (in accordance with clause of the ICANN’s Registrar accreditation agreement), including but not limited to the following;
(i) if the Registrant is a company or organisation:
a. name of a company or organisation;
b. registered office and principal place of business; and
c. contact details of the Registrant including e-mail address and telephone number;
(ii) if the Registrant is a natural person:
a. full name of the Registrant;
b. address of the Registrant; and
c. contact details of the Registrant including e-mail address and telephone number.

All Registrant contact information must be complete and accurate. Any changes to such Registrant information must be promptly notified to the Registrar, and no later than one (1) month of such change.


The Registrant acknowledges that the Registry may revoke a Domain Name immediately at its sole discretion:
(i) in the event the Registrant breaches any Registry Rules;
(ii) to comply with applicable law, court order, government rule or under any dispute resolution processes;
(iii) where such Domain Name is used for any of the following prohibited activities (Prohibited Activities):
a. spamming;
b. intellectual property and privacy violations;
c. obscene speech or materials;
d. defamatory or abusive language;
e. forging headers, return addresses and internet protocol addresses;
f. illegal or unauthorised access to other computers or networks;
g. distribution of internet viruses, worms, Trojan horses or other destructive activities; and
h. any other illegal or prohibited activities as determined by the Registry.
(iv) in order to protect the integrity and stability of the domain name system and the Registry;
(v) where such Domain Name is placed under reserved names list at any time; and
(vi) where Registrant fails to make payment to the Registrar for registration, renewal or any other relevant services.


In addition to meeting all required criteria for registration of domain names above, an application for an IDN Domain Name must:
(i) comply with any additional registration policy on IDNs for each language;
(ii) meet all technical requirement for the applicable IDN;
(iii) comply with the IDN tables used by the Registry as amended from time to time; and
(iv) meet any other additional technical requirements as required by the Registry.


All two-character labels and country and territory names will be initially reserved in accordance with specification 5 of the Registry Agreement.
Upon approval from ICANN and any other guidelines by applicable governments and ICANN’s Governmental Advisory Committee, the Registry may release the two-character labels and country and territory names in accordance with SNCF’s response to Question 22 Geographic Names.


The Registry may place certain names in its reserved list from time to time where:
(i) the Registry believes in its sole discretion that use of such names may pose a risk to the operational stability or integrity of the Registry;
(ii) in accordance with ICANN’s specifications contained in the Registry Agreement, guidelines or recommendations;
(iii) there is a risk of trademark infringement or where the name otherwise may cause confusion taking into consideration the mission and purpose of the gTLD; or
(iv) the Registry in its sole discretion decides certain names to be reserved for any reason.


The Registry will register Domain Names on a first-come, first-served basis in accordance with the Registry Rules. The Registry does not provide pre-registration or reservation of Domain Names.


There is no restriction on the number of Domain Names any Registrant may hold. The Registrant may further licence the use of the Domain Name to any third parties provided that the Registrant enters into an agreement with such third parties on the terms not less onerous than its obligations under the Registry Rules.


The Registry will implement all rights protection measures as required by ICANN in clause 2.8 of the Registry Agreement, including the use of the Uniform Rapid Suspension (URS) procedure, and Uniform Domain Name Dispute Resolution Policy (UDRP).


A Domain Name can be registered for a period between one (1) to ten (10) years.

(i) The term may be extended at any time for a period between one (1) to ten (10) years, provided that the total aggregate term of the Domain Name does not exceed ten (10) years at any time.
(ii) Upon change of sponsorship of the Domain Name from one Registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the registered Domain Name will be extended by one year, provided that the maximum term of registration at any time does not exceed ten (10) years.
(iii) The change of sponsorship of the registration of a Domain Name from one Registrar to another, accordingly to Part B of the ICANN Policy on Transfer of Registrations between Registrars will not result in the extension of the term of registration.

The Registrant may cancel a Domain Name registration at any time by submitting its request in writing with the Registrar.

Upon expiry of the Domain Name, the Registry will auto-renew the Domain Name for a one year term (1) year term unless the Registrant submits its intention not to renew the Domain Name.

The Registry will implement the business rules for the renewal of Domain Names documented in appendix 7 of the .com Registry Agreement.


Any transfer of a Domain Name between Registrants must be approved by the Registry through the Registrar. The legal heirs of the Registrant or purchaser of the Registrant may request the transfer provided that they meet the eligibility criteria for registration under the sncf gTLD. If the Registrant becomes subject to insolvency or any other proceeding, the administrator may request the transfer. The transferee must provide appropriate documentation as required by the Registry to approve such transfer.


If the agreement between the Registry and the Registrar is terminated and if the Registrar has not transferred its Domain Name portfolio to another Registrar, the Registry will notify affected Registrants. The Registrants must select a new Registrar within one (1) month following such notice from the Registry. If the Registrant fails to appoint a new Registrar within the timeframe set out above, the Registry may suspend the Domain Name.

If the Registrant wishes to change the Registrar, the Registrant must obtain the auth-info code from the Registrantʹs current Registrar, and request a transfer through the gaining Registrar in compliance with ICANNʹs Inter-Registrar transfer policy.


By registering a Domain Name, the registrant authorises the Registry to process personal information and other data required for the operation of the sncf gTLD. The Registry will only use the data for the operation of the Registry including but not limited to its internal use, communication with the Registrant, and provision of WHOIS look-up facility.

The Registry may only transfer the data to third parties:
(i) with the Registrant’s consent;
(ii) in order to comply with laws, regulations or orders by a competent public authority and any Alternative Dispute Resolution (ADR) providers; or
(iii) for a publicly available and searchable WHOIS look-up facility, in accordance with specification 4 of the Registry Agreement.


The Registry provides a publicly available and searchable WHOIS look up facility, where information about the Domain Nameʹs status (including creation and expiry dates), and registrant, administrative and the technical contact administering the Domain Name can be found, in accordance with specification 4 of the Registry Agreement.

In order to prevent misuse of the WHOIS look up facility, the Registry requires that any person submitting a WHOIS database query will be required to read and agree to the terms and conditions, which will provide that:
(i) the WHOIS database is provided for information purposes only; and
(ii) the user agrees not to use the WHOIS information to allow or enable the transmission of unsolicited commercial advertising or other communication via email or other methods to the Registrants.


The new gTLD does not charge a separate fee for the Registrar to register domain names, as the gTLD is used only for the specified mission and purpose of SNCF. SNCF shall bear the cost of operating the Registry.

The Registry will provide Registrars with 30 days’ notice of any price change for new registrations, and 180 days advance notice of any price change for renewals in accordance with clause 2.10 of the Registry Agreement.


The Registrant agrees to be bound by ICANN’s Dispute Resolution Policies in respect of all disputes in connection with the Domain Name.


The Registrant agrees to be bound by all applicable consensus and temporary policies as required and mandated by ICANN.


Affiliate means in relation to a party any corporation or other business entity controlling, controlled by, or under common control of that party and for the purposes of this definition, a corporation or other business entity shall be deemed to control another corporation or business entity if it owns directly or indirectly:
(i) fifty percent (50%) or more of the voting securities or voting interest in any such corporation or other entity; or
(ii) fifty percent (50%) or more of the interest in the profit or income in the case of a business entity other than a corporation; or
(iii) in the case of a partnership, any other compatible interest equal to at least a fifty percent (50%) share in the general partner.

Domain Name means a domain name registered directly under the sncf gTLD or for which a request or application for registration has been filed with the Registry;

ICANN’s Dispute Policy means the dispute policy currently known as the Uniform Domain Name Dispute Resolution Policy (UDRP) issued and as may be updated from time to time by the Internet Corporation of Assigned Names and Number (ICANN) and the Uniform Rapid Suspension (URS) (see Specification 7 of the Registry Agreement).

Registrar means an ICANN accredited registrar which enters into and is in compliance with the registry-registrar agreement for the TLD, and which provides domain name registration services to Registrants;

Registry means SNCF;

Registry Agreement means the agreement between SNCF and ICANN;

Registry Rules mean:
(i) Registration terms and conditions agreed between the Registry and Registrant for registration of a Domain Name; and
(ii) Registration policies provided and amended by the Registry from time to time.

Registrant means a natural person, company or organisation who holds a Domain Name registration or who has requested or applied for the registration of a Domain Name.

Similar gTLD applications: (1)

gTLDFull Legal NameE-mail suffixzDetail
.banqueGEXBAN SASgexban.net-4.17Compare