Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.SFRSociete Francaise du Radiotelephone - SFRsfr.comView
1. Introduction
Next to ensuring that a TLD is operated in a technically stable and secure manner, it is also of utmost importance that the Internet community at large is safeguarded from abusive and malicious behavior. Existing TLDs have often suffered from such behavior and, gradually, best practices have been developed in order to not only counter abusive or malicious conduct, but also prevent such issues from happening.
Abusive use of a domain name generally includes, but is not limited to the following:
1) illegal or fraudulent actions;
2) using domain names in the TLD in order to send or forward unsolicited bulk messages, generally referred to as “spam”;
3) distribution of malware: using domain names in order to disseminate software (e.g. computer viruses, keyloggers, etc.) that is designed to damage or harm the integrity of computers;
4) phishing: displaying web pages that are intended to mislead Internet users, with the aim of obtaining in a malicious manner from such users their sensitive data such as logins and passwords of the pirated websites;
5) pharming: redirecting Internet users to fraudulent website, which is generally done by hijacking or poisoning the DNS or changing host files on the victim’s computer;
6) fast-flux hosting and botnets;
7) 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);
8) Using domain names in the TLD in order to disseminate illegal content, such as child pornography
Given the fact that the applied-for TLD will likely be and remain a single registrant TLD, as explained in our response to Question 18 et seq., where only members of the Applicant will be entitled to register domain names in the TLD, the likelihood for any such abusive behavior in this TLD to materialize is lower. Nonetheless, the Applicant commits to implement the preventive and curative measures described in the following paragraphs, in order to ensure that the applied-for TLD is operated in a responsible manner.



2. Control
Considering the fact that the applied-for gTLD will be a so-called brand-TLD, the Applicant ⁄ Registry Operator will put in place various tools in order to mitigate or even exclude the possibility that the reputation of the key brands and identifiers of the Applicant is not harmed in any way. Especially, these tools and techniques will ensure that the Applicant will have the ability at all times to exercise control over:
1) the registrant;
2) the domain name;
3) the contact information associated with any domain name; and
4) the products, services and information provided under such domain name.

In order to effectuate this, a limited number of identified individuals within the Applicant’s organization will be able to control the applied-for TLD and any and all domain names registered therein from one portal, which has the following functionalities:

1) validating the registrant’s eligibility and user rights in order to register domain names in the applied-for TLD;
2) validating whether an (about to be) registered domain name in the applied-for TLD corresponds to the naming conventions that will be established by the Registry Operator for domain names registered in the applied-for TLD;
3) validating contact information associated with registered domain names, in particular these contacts that can exercise control over the domain name itself, the name servers associated with such domain name, etc.;
4) validating specific commands, including create, update and delete commands;
5) approving for some or all domain names any transfer or trade requests, or intervene in the execution of such requests where the Registry Operator suspects that such transfer or trade requests are initiated in bad faith; and
6) review whether the use that is made of a particular domain name corresponds with the Registry Operator’s use policy, and suspend domain name registrations or even delete name servers associated with domain names that are being used in a manner that does not comply with the types of uses that are allowed by the Registry Operator.

Bearing in mind that the registry is intended to be single registrant-registry only certain individuals are involved in above mentioned processes, reducing the risk of registering and⁄or using domain names in bad faith by any party that is not a member of the Applicant’s organization.
Access to this portal will be given to the administrators of the Registry Operator; furthermore, the Complaints Point of Contact will also obtain access to a limited number of features explained above.


3. Reporting
Also, the Registry Operator will obtain access to reports generated by its back-end registry services provider, which reports include:

1) number of DNS queries for each particular domain name registration;
2) number of new domain names registered;
3) number of new contacts created;
4) etc.

If any suspicious activity is being detected following analysis of these reports, the Registry Operator will thoroughly investigate the matter and take appropriate action where required.



4. Anti-abuse policy
Prior to the delegation of the TLD, the Registry Operator will publish the terms and conditions for the registration of domain names in the applied-for TLD, which will include an anti-abuse policy. Highlights of such policy will include:
Complaints Point of Contact: the Registry Operator will put in place a Complaints Point of Contact. The Complaints Point of Contact’s contact details will be mentioned on the home page of the Registry Operator, including on the web-based WHOIS interface.


5. Monitoring
The Registry backend service provider, appointed by the applicant, will put in place certain tools and methodologies in order to proactively screen for malicious conduct. Such tools include scanners that automatically scan for viruses or other forms of malware on all services deployed under applied-for domain names.
These tools will operate in the background, and will not effect the functioning of the applied-for TLD.

6. Prevention of Orphan glue records
In compliance with SSAC recommendations, the Registry backend service provider, appointed by the applicant, will check for the existence of glue records following the receipt of a deletion request for a particular domain name registration. If it would appear that no other domain names other than the domain name that is up for deletion are using the glue records associated with that domain name registration, the Registry Operator will remove such glue records after the domain name is deleted.
Furthermore, any interested party will be entitled to file a complaint before the Complaints Point of Contact if it would appear that orphan glue records would still exist. If it would appear, following investigation by the Registry Operator, that orphan glue records would still exist in the zone file, such records will be promptly deleted from the zone file.
6.1. Glue record
RFC 1034 defines glue as
A zone contains ʺglueʺ resource records which are not part of the authoritative data, and are address resource records for the servers.
And specifies further that
These resource records are only necessary if the name serverʹs name is ʺbelowʺ the cut, and are only used as part of a referral response.
In this specific case a glue record is the IP address of a name server held at the domain name registry. They are required when a set of name servers of a domain name point to a hostname under the domain name itself. For example, if the name servers of example.com are ns1.example.com and ns2.example.com: to make the domain name system work, glue records (i.e. the IP addresses) for ns1.example.com and ns2.example.com are required. Without the glue records for these name servers the domain name would not work as anyone requiring DNS information for it would get stuck in a loop.
Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 donʹt know, try looking at name server for example.com
What is the name server for example.com? -〉 ns1.example.com
With the glue record in place the registry will hold the IP address and the loop will not occur.
Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 [IP Address]
6.2. Orphan glue
The zone generation process could publish A-records ʺaddress-recordsʺ (also called ʺglueʺ records) regardless of whether or not the name server is referenced by any NS (name server) records. If an A-record is published and no zone delegations reference to such a record, it is called an orphan. Its presence in the zone is undesirable for a number of reasons, both administrative and technical.
6.3. Out-of-bailiwick records
Records pointing to names of other zones besides the relevant registry zone, are called out-of-zone records or even out-of-bailiwick records. Any IP addresses linked to these names should in all circumstances be refused by the registry since they do not form part of the registryʹs zone. Most modern nameserver software will ignore these records by default.
6.4. Exclusion
Glue records can only be inserted following the registration of a domain name and the creation of a host object. They can also only be included when the name servers have the same extension as the domain name.
Example:
A glue record can only be inserted if the name server of example.com is located in example.com
These address records only live by the grace of the domain name itself. Since the IP address is always linked to the domain name, the address will also disappear from the zone as soon as the domain name is eliminated from the registration database. This limits the possibility to register name servers within a domain name, because setting up circular referencing name servers is not allowed. In view of the possible risks and dangers, this is a very balanced choice of limitations and it allows for a flexible and consistent handling of glue records.



7. WHOIS accuracy
The Registry Operator will include in its domain name registration policies the obligation to keep all information contained in the WHOIS accurate and up-to-date.
As mentioned in response to Question 26, the applied-for WHOIS will be a “thick” WHOIS, where all key contact data relating to every domain name registered in the applied-for TLD will be stored at the level of the Registry Operator.
Working closely with the accredited registrars for the applied-for TLD, Registry Operator will put in place measures whereby registrants are obliged to keep their WHOIS information accurate and up-to-date. Clauses will be inserted in the Registry-Registrar Agreement to that effect, in particular:

1) under the terms of the Registry-Registrar Agreement, accredited registrars will be required to impose upon their clients the obligation to maintain accurate and up-to-date WHOIS data at all times;
2) furthermore, accredited registrars will be instructed to send their customers who have registered a domain name in the TLD a request to confirm the accuracy of their WHOIS data and⁄or an email message whereby their obligation to keep WHOIS data accurate and up-to-date will is restated.
3) accredited registrars will have to demonstrate, upon the Registry Operator’s request, their compliance with the above, as well as any changes that have been made to WHOIS data following submission of such instructions.
The above processes and requirements will in particular be relevant as of the moment that the applied-for TLD will no longer be a single registrant TLD, which entails that certain parties, other than the Registry Operator, will be entitled to register domain names in this extension.
Furthermore, the Applicant ⁄ Registry Operator will display on the web-based WHOIS interface a link to the Complaints Point of Contact. Any party who is of the opinion that certain WHOIS data is inaccurate, incomplete or not up-to-date can contact the Complaints Point of Contact. The latter has the authority to commence investigations, and – in case of registrant non-compliance – take measures against such registrant. These measures include, but are not limited to, putting the domain name on hold, or revoking the domain name registration.



8. WHOIS abuse prevention measures
Considering the fact that a WHOIS database contains quite some sensitive information that is available to Internet users at large over a web-based interface, the Registry Operator will put in place various methods in order to avoid abuse of such information by third parties.
First of all, the Registry Operator will only display search results in response to a search query after the user has successfully entered the displayed CAPTCHA code together with such query, this in order to prevent the automatic harvesting of WHOIS data.
Furthermore, private individuals (if at all allowed by the Applicant ⁄ Registry Operator to register and hold domain names within the TLD) will be allowed to indicate – through their registrars or via a web-based portal provided by the Applicant ⁄ Registry Operator – that certain personal data will not be automatically displayed following a successful WHOIS query. This measure is taken in order to comply with particular applicable laws and regulations regarding data privacy.
However, parties demonstrating to the Registry Operator that they have a right or legitimate interest in order to obtain access to this hidden data can request access to a particular, identified record upon request to the Registry Operator. Positive responses to legitimate requests shall not be unreasonably withheld or delayed.
The features described above can be temporarily or permanently disabled for specific eligible parties, such as law enforcement agencies, and this upon simple request by a competent authority. These eligible parties will then obtain access to all WHOIS information via a secure, web-based portal.
gTLDFull Legal NameE-mail suffixDetail
.medHEXAP SAShexap.comView
1. INTRODUCTION

Next to ensuring that a TLD is operated in a technically stable and secure
manner, it is also of utmost importance that the Internet community at large
is safeguarded from abusive and malicious behavior. Existing TLDs have often
suffered from such behavior and, gradually, best practices have been
developed in order to not only counter abusive or malicious conduct, but
also prevent such issues from happening.

Abusive use of a domain name generally includes, but is not limited to the
following:

- illegal or fraudulent actions;

- using domain names in the TLD in order to send or forward unsolicited bulk
messages, generally referred to as ʺspamʺ;

- distribution of malware: using domain names in order to disseminate
software (e.g. computer viruses, key loggers, etc.) that is designed to
damage or harm the integrity of computers;

- phishing: displaying web pages that are intended to mislead Internet
users, with the aim of obtaining in a malicious manner from such users
their sensitive data such as logins and passwords of the pirated websites;

- pharming: redirecting Internet users to fraudulent website, which is
generally done by hijacking or poisoning the DNS or changing host files on
the victimʹs computer;

- fast-flux hosting and botnets;

- 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);

- Using domain names in the TLD in order to disseminate illegal content,
such as child pornography

Given the fact that the applied-for TLD will likely be and remain a single
registrant TLD, as explained in our response to Question 18 et seq., where
only members of HEXAP will be entitled to register domain names in the TLD,
the likelihood for any such abusive behavior in this TLD to materialize is
lower. Nonetheless, HEXAP commits to implement the preventive and curative
measures described in the following paragraphs, in order to ensure that the
applied-for TLD is operated in a responsible manner.

2. CONTROL

HEXAP ⁄ Registry Operator will put in place various tools in order to
mitigate or even exclude the possibility that the reputation of the .MED TLD
is not harmed in any way. Especially, these tools and techniques will ensure
that HEXAP will have the ability at all times to exercise control over:

- the registrant;

- the domain name;

- the contact information associated with any domain name; and

- the products, services and information provided under such domain name.

In order to effectuate this, a limited number of identified individuals
within HEXAPʹs organization will be able to control the applied-for TLD and
any and all domain names registered therein from one portal, which has the
following functionalities:

- validating the registrantʹs eligibility and user rights in order to
register domain names in the applied-for TLD;

- validating whether an (about to be) registered domain name in the
applied-for TLD corresponds to the naming conventions that will be
established by the Registry Operator for domain names registered in the
applied-for TLD;

- validating contact information associated with registered domain names, in
particular these contacts that can exercise control over the domain name
itself, the name servers associated with such domain name, etc.;

- validating specific commands, including create, update and delete
commands;

- approving for some or all domain names any transfer or trade requests, or
intervene in the execution of such requests where the Registry Operator
suspects that such transfer or trade requests are initiated in bad faith;
and

- review whether the use that is made of a particular domain name
corresponds with the Registry Operatorʹs use policy, and suspend domain
name registrations or even delete name servers associated with domain
names that are being used in a manner that does not comply with the types
of uses that are allowed by the Registry Operator.

Bearing in mind that the registry is intended to be single
registrant-registry only certain individuals are involved in above mentioned
processes, reducing the risk of registering and⁄or using domain names in bad
faith by any party that is not a member of HEXAPʹs organization.

Access to this portal will be given to the administrators of the Registry
Operator; furthermore, the Complaints Point of Contact will also obtain
access to a limited number of features explained above.

3. REPORTING

Also, the Registry Operator will obtain access to reports generated by its
back-end registry services provider, which reports include:

- number of DNS queries for each particular domain name registration;

- number of new domain names registered;

- number of new contacts created;

- etc.

If any suspicious activity is being detected following analysis of these
reports, the Registry Operator will thoroughly investigate the matter and
take appropriate action where required.

4. ANTI-ABUSE POLICY

Prior to the delegation of the TLD, the Registry Operator will publish the
terms and conditions for the registration of domain names in the applied-for
TLD, which will include an anti-abuse policy. Highlights of such policy will
include:

- Complaints Point of Contact: the Registry Operator will put in place a
Complaints Point of Contact. The Complaints Point of Contactʹs contact
details will be mentioned on the home page of the Registry Operator,
including on the web-based WHOIS interface.

5. MONITORING

The Registry backend service provider, appointed by HEXAP, will put in place
certain tools and methodologies in order to proactively screen for malicious
conduct. Such tools include scanners that automatically scan for viruses or
other forms of malware on all services deployed under applied-for domain
names.

These tools will operate in the background, and will not effect the
functioning of the applied-for TLD.

6. PREVENTION OF ORPHAN GLUE RECORDS

In compliance with SSAC recommendations, the Registry backend service
provider, appointed by HEXAP, will check for the existence of glue records
following the receipt of a deletion request for a particular domain name
registration. If it would appear that no other domain names other than the
domain name that is up for deletion are using the glue records associated
with that domain name registration, the Registry Operator will remove such
glue records after the domain name is deleted.

Furthermore, any interested party will be entitled to file a complaint
before the Complaints Point of Contact if it would appear that orphan glue
records would still exist. If it would appear, following investigation by
the Registry Operator, that orphan glue records would still exist in the
zone file, such records will be promptly deleted from the zone file.

6.1 GLUE RECORD

RFC 1034 defines glue as:

A zone contains ʺglueʺ resource records which are not part of the
authoritative data, and are address resource records for the servers.

And specifies further that:

These resource records are only necessary if the name serverʹs name is
ʺbelowʺ the cut, and are only used as part of a referral response.

In this specific case a glue record is the IP address of a name server held
at the domain name registry. They are required when a set of name servers of
a domain name point to a hostname under the domain name itself. For example,
if the name servers of example.com are ns1.example.com and ns2.example.com:
to make the domain name system work, glue records (i.e. the IP addresses)
for ns1.example.com and ns2.example.com are required. Without the glue
records for these name servers the domain name would not work as anyone
requiring DNS information for it would get stuck in a loop.

Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 donʹt know, try looking at
name server for example.com
What is the name server for example.com? -〉 ns1.example.com
With the glue record in place the registry will hold the IP address and
the loop will not occur.

Example:
What is the name server for example.com? -〉 ns1.example.com
What is the IP address of ns1.example.com? -〉 [IP Address]

6.2. ORPHAN GLUE

The zone generation process could publish A-records ʺaddress-recordsʺ (also
called ʺglueʺ records) regardless of whether or not the name server is
referenced by any NS (name server) records. If an A-record is published and
no zone delegations reference to such a record, it is called an orphan. Its
presence in the zone is undesirable for a number of reasons, both
administrative and technical.

6.3. OUT-OF-BAILIWICK RECORDS

Records pointing to names of other zones besides the relevant registry zone,
are called out-of-zone records or even out-of-bailiwick records. Any IP
addresses linked to these names should in all circumstances be refused by
the registry since they do not form part of the registryʹs zone. Most modern
nameserver software will ignore these records by default.

6.4. EXCLUSION

Glue records can only be inserted following the registration of a domain
name and the creation of a host object. They can also only be included when
the name servers have the same extension as the domain name.

Example:

A glue record can only be inserted if the name server of example.com is
located in example.com
These address records only live by the grace of the
domain name itself. Since the IP address is always linked to the domain
name, the address will also disappear from the zone as soon as the domain
name is eliminated from the registration database. This limits the
possibility to register name servers within a domain name, because setting
up circular referencing name servers is not allowed. In view of the
possible risks and dangers, this is a very balanced choice of limitations
and it allows for a flexible and consistent handling of glue records.

7. WHOIS ACCURACY

The Registry Operator will include in its domain name registration policies
the obligation to keep all information contained in the WHOIS accurate and
up-to-date.

As mentioned in response to Question 26, the applied-for WHOIS will be a
ʺthickʺ WHOIS, where all key contact data relating to every domain name
registered in the applied-for TLD will be stored at the level of the
Registry Operator.

Working closely with the accredited registrars for the applied-for TLD,
Registry Operator will put in place measures whereby registrants are obliged
to keep their WHOIS information accurate and up-to-date. Clauses will be
inserted in the Registry-Registrar Agreement to that effect, in particular:

- under the terms of the Registry-Registrar Agreement, accredited registrars
will be required to impose upon their clients the obligation to maintain
accurate and up-to-date WHOIS data at all times;

- furthermore, accredited registrars will be instructed to send their
customers who have registered a domain name in the TLD a request to
confirm the accuracy of their WHOIS data and⁄or an email message whereby
their obligation to keep WHOIS data accurate and up-to-date will is
restated.

- accredited registrars will have to demonstrate, upon the Registry
Operatorʹs request, their compliance with the above, as well as any
changes that have been made to WHOIS data following submission of such
instructions.

The above processes and requirements will in particular be relevant as of
the moment that the applied-for TLD will no longer be a single registrant
TLD, which entails that certain parties, other than the Registry Operator,
will be entitled to register domain names in this extension.

Furthermore, HEXAP ⁄ Registry Operator will display on the web-based WHOIS
interface a link to the Complaints Point of Contact. Any party who is of the
opinion that certain WHOIS data is inaccurate, incomplete or not up-to-date
can contact the Complaints Point of Contact. The latter has the authority to
commence investigations, and - in case of registrant non-compliance - take
measures against such registrant. These measures include, but are not
limited to, putting the domain name on hold, or revoking the domain name
registration.

8. WHOIS ABUSE PREVENTION MEASURES

Considering the fact that a WHOIS database contains quite some sensitive
information that is available to Internet users at large over a web-based
interface, the Registry Operator will put in place various methods in order
to avoid abuse of such information by third parties.

First of all, the Registry Operator will only display search results in
response to a search query after the user has successfully entered the
displayed CAPTCHA code together with such query, this in order to prevent
the automatic harvesting of WHOIS data.

Furthermore, private individuals (if at all allowed by HEXAP ⁄ Registry
Operator to register and hold domain names within the TLD) will be allowed
to indicate - through their registrars or via a web-based portal provided by
HEXAP ⁄ Registry Operator - that certain personal data will not be
automatically displayed following a successful WHOIS query. This measure is
taken in order to comply with particular applicable laws and regulations
regarding data privacy.

However, parties demonstrating to the Registry Operator that they have a
right or legitimate interest in order to obtain access to this hidden data
can request access to a particular, identified record upon request to the
Registry Operator. Positive responses to legitimate requests shall not be
unreasonably withheld or delayed.

The features described above can be temporarily or permanently disabled for
specific eligible parties, such as law enforcement agencies, and this upon
simple request by a competent authority. These eligible parties will then
obtain access to all WHOIS information via a secure, web-based portal.