Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.netbankCOMMONWEALTH BANK OF AUSTRALIAcba.com.auView
28 ABUSE PREVENTION AND MITIGATION

CBA, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the TLD. The specific measures include, but are not limited to:

- Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;

- Committing to rapid identification and resolution of abuse, including suspensions;

- Ensuring completeness of WHOIS information at the time of registration;

- Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;

- Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.

Furthermore CBA the registry operator intends to operate the .netbank gTLD with the strict eligibility requirements on registrants set out in the draft registration policy appended to the response to this question. The strict eligibility requirements mean that the scope for abuse in the TLD is low as the registry will operate as a single registrant registry.

As stated in response to Question 18, CBA’s registration policy will address the minimum requirements mandated by ICANN including rights abuse prevention measures. CBA will implement its draft registration policy as means of abuse prevention and mitigation ** (see end of document).


ABUSE POLICY

The Anti-Abuse Policy stated below will be enacted under the contractual authority of CBA as CBA, through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. CBA and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

Repeat violations of the abuse policy will result in a case-by-case review of the abuser(s), and CBA reserves the right to escalate the issue, with the intent of levying sanctions that are allowed under the TLD anti-abuse policy.

The below policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool.

.netbank ANTI-ABUSE POLICY

The following Anti-Abuse Policy is effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. CBA definition of abusive use of a domain includes, without limitation, the following:

- Illegal or fraudulent actions;

- Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums;

- Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;

- Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, 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.

- Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.

- Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);

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

Pursuant to the Registry-Registrar Agreement, CBA reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of CBA, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by CBA or any registrar in connection with a domain name registration. CBA also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to CBA’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).

ABUSE POINT OF CONTACT AND PROCEDURES FOR HANDLING ABUSE COMPLAINTS

CBA will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.netbank”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. For tracking purposes, CBA will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. Afilias will integrate its existing ticketing system with CBA’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

CBA’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate.

In general, CBA will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to CBA will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

The security function includes a communication and outreach function, with information sharing with industry partners regarding malicious or abusive behavior, in order to ensure coordinated abuse mitigation across multiple TLDs.

Assessing abuse reports requires great care, and CBA will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, CBA expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:

a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.

b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.

The standard procedure is that CBA will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that CBA will not, such as:

- Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);

- The identity of a proxy-protected registrant;

- The purchaser’s IP address;

- Whether there is a reseller involved, and;

- The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).

Registrars do not share the above information with registry operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by CBA (usually 24 hours), CBA might then decide to take action itself. At all times, CBA reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

CBA will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where CBA will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which CBA, although the operator in all cases will adhere to applicable laws and regulations.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, CBA will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:

- Registration information

- History of a domain, including recent updates made

- Other domains associated with a registrant’s account

- Patterns of registrant portfolio


Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. Afilias sets a goal to respond to such requests within 24 hours.

CBA may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. CBA could take advantage of a combination of the following resources, among others:

- Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus.

- Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.

- Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.

CBA will keep records and track metrics regarding abuse and abuse reports. These will include:

- Number of abuse reports received by the registry’s abuse point of contact described above;

- Number of cases and domains referred to registrars for resolution;

- Number of cases and domains where the registry took direct action;

- Resolution times;

- Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;

- Phishing site uptimes in the TLD.


REMOVAL OF ORPHAN GLUE RECORDS

By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. These procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. CBA does not plan on performing mass updates of the associated DNS records.

CBA will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to CBA, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, CBA will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.

METHODS TO PROMOTE WHOIS ACCURACY

The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in our response to question #26, WHOIS, CBA will manage a secure, robust and searchable WHOIS service for this TLD.

WHOIS DATA ACCURACY

CBA will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. CBA will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list. The Afilias WHOIS system is extensible, and is capable of using the VAULT system, described further below.

Similar to the centralized abuse point of contact described above, CBA can institute a contact email address which could be utilized by third parties to submit complaints for inaccurate or false WHOIS data detected. This information will be processed by Afilias’ support department and forwarded to the registrars. The registrars can work with the registrants of those domains to address these complaints. Afilias will audit registrars on a yearly basis to verify whether the complaints being forwarded are being addressed or not. This functionality, available to all CBAs, is activated based on CBA’s business policy.

Afilias also incorporates a spot-check verification system where a randomly selected set of domain names are checked periodically for accuracy of WHOIS data. Afilias’ .PRO registry system incorporates such a verification system whereby 1% of total registrations or 100 domains, whichever number is larger, are spot-checked every month to verify the domain name registrant’s critical information provided with the domain registration data. With both a highly qualified corps of engineers and a 24x7 staffed support function, Afilias has the capacity to integrate such spot-check functionality into this TLD, based on CBA’s business policy. Note: This functionality will not work for proxy protected WHOIS information, where registrars or their resellers have the actual registrant data. The solution to that problem lies with either registry or registrar policy, or a change in the general marketplace practices with respect to proxy registrations.

Finally, Afilias’ registry systems have a sophisticated set of billing and pricing functionality which aids CBAs who decide to provide a set of financial incentives to registrars for maintaining or improving WHOIS accuracy. For instance, it is conceivable that CBA may decide to provide a discount for the domain registration or renewal fees for validated registrants, or levy a larger cost for the domain registration or renewal of proxy domain names. The Afilias system has the capability to support such incentives on a configurable basis, towards the goal of promoting better WHOIS accuracy.

ROLE OF REGISTRARS

As part of the RRA (Registry Registrar Agreement), CBA will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄ ).

CONTROLS TO ENSURE PROPER ACCESS TO DOMAIN FUNCTIONS

Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to question #30b.

VALIDATION AND ABUSE MITIGATION MECHANISMS

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by CBA based on their policy and business need.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation. Once analyzed and confirmed by the domain anti-abuse team members, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable CBA to only allow registrations by pre-authorized and verified contacts. These verified contacts are given a unique code that can be used for registration of new domains.

REGISTRANT PRE-VERIFICATION AND AUTHENTICATION

One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

- Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.

- Based on required WHOIS Data; registrant contact details (name, address, phone)

- If address⁄ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)

- If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions.

- If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be
specific to a domain registration and pre-populated with data about the registrant.

- If WHOIS data is validated a token would be generated and could be given back to the registrar which registered the domain.

- WHOIS data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.

- A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would should limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers.

- Validation would be annually renewed, and validation date displayed in the WHOIS.

ABUSE PREVENTION RESOURCING PLANS

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way. Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. While all of Afilias’ 200+ employees are charged with responsibility to report any detected abuse, the engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by CBA based on their policy and business need.

This TLD’s anticipated volume of registrations in the first three years of operations is listed in response #46. Afilias and CBA’s anti-abuse function anticipates the expected volume and type of registrations, and together will adequately cover the staffing needs for this TLD. CBA will maintain an abuse response team, which may be a combination of internal staff and outside specialty contractors, adjusting to the needs of the size and type of TLD. The team structure planned for this TLD is based on several years of experience responding to, mitigating, and managing abuse for TLDs of various sizes. The team will generally consist of abuse handlers (probably internal), a junior analyst, (either internal or external), and a senior security consultant (likely an external resource providing CBA with extra expertise as needed). These responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

The exact resources required to maintain an abuse response team must change with the size and registration procedures of the TLD. An initial abuse handler is necessary as a point of contact for reports, even if a part-time responsibility. The abuse handlers monitor the abuse email address for complaints and evaluate incoming reports from a variety of sources. A large percentage of abuse reports to CBA may be unsolicited commercial email. The designated abuse handlers can identify legitimate reports and then decide what action is appropriate, either to act upon them, escalate to a security analyst for closer investigation, or refer them to registrars as per the above-described procedures. A TLD with rare cases of abuse would conform to this structure.

If multiple cases of abuse within the same week occur regularly, CBA will consider staffing internally a security analyst to investigate the complaints as they become more frequent. Training an abuse analyst requires 3-6 months and likely requires the active guidance of an experienced senior security analyst for guidance and verification of assessments and recommendations being made.

If this TLD were to regularly experience multiple cases of abuse within the same day, a full-time senior security analyst would likely be necessary. A senior security analyst capable of fulfilling this role should have several years of experience and able to manage and train the internal abuse response team.

The abuse response team will also maintain subscriptions for several security information services, including the blocklists from organizations like SURBL and Spamhaus and anti-phishing and other domain related abuse (malware, fast-flux etc.) feeds. The pricing structure of these services may depend on the size of the domain and some services will include a number of rapid suspension requests for use as needed.

For a large TLD, regular audits of the registry data are required to maintain control over abusive registrations. When a registrar with a significant number of registrations has been compromised or acted maliciously, CBA may need to analyze a set of registration or DNS query data. A scan of all the domains of a registrar is conducted only as needed. Scanning and analysis for a large registrar may require as much as a week of full-time effort for a dedicated machine and team.

** .netbank’S DRAFT REGISTRATION POLICY

1. DOMAIN NAME LICENCES

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.

2. SELECTION OF REGISTRARS

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 .netbank;

(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 .netbank; and

(xi) comply with all conditions, dependencies, policies and other requirements reasonably imposed by CBA, including maintenance of suitable systems and applications that are capable of interacting with the Registry system.



3. ELIGIBLE REGISTRANTS

The Registrant must be:

(i) an Affiliate entity of CBA; or

(ii) an organisation explicitly authorised by CBA; or

(iii) a natural person explicitly authorised by CBA.

If the Registrant does not meet one of the above eligibility criteria, there is no entitlement to register a Domain Name under the .netbank TLD. If the Registrant ceases to be eligible at any time in the future, the .netbank Registry may cancel or suspend the licence to use the Domain Name immediately.



4. REGISTRY APPROVAL REQUIREMENT

Registration of Domain Names under the .netbank TLD must be approved by CBA in addition to meeting all requirements under the Registry Rules. CBA’s approval for a complete and validly submitted application will be authorised by:

(i) a head of appropriate department as nominated by CBA (“Authorisation Provider”); or

(ii) an authorised person as nominated by CBA (“Authorised Person”) and notified to the Registrar from time to time.

The Authorisation Provider will notify the Registrar of its decision.



5. REQUIRED CRITERIA FOR DOMAIN NAME REGISTRATION

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 .netbank Registry; or

c. it meets all .netbank 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 .netbank Registry; and

c. any additional technical requirements as required by the .netbank Registry from time to time.

(iii) the Domain Name must be consistent with the mission and purposes of the .netbank TLD and consistent with the Domain Name registration policy of .netbank, 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.




6. OBLIGATION OF REGISTRANTS

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.




7. REGISTRANT CONTACT INFORMATION

The Registrant must provide complete and accurate contact information of the Registrant (in accordance with clause 3.7.7.1 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.




8. REVOCATION OF DOMAIN NAMES

The Registrant acknowledges that the .netbank Registry may revoke a Domain Name immediately at its sole discretion:

(i) in the event the Registrant breaches any .netbank 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 .netbank Registry.

(iv) in order to protect the integrity and stability of the domain name system and the .netbank 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.



9. USE OF SECOND OR THIRD LEVEL IDNs

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 .netbank Registry as amended from time to time; and

(iv) meet any other additional technical requirements as required by the .netbank Registry.




10. USE OF GEOGRAPHIC NAMES

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 CBA’s response to Question 22 Geographic Names.




11. RESERVED NAMES

The .netbank Registry may place certain names in its reserved list from time to time where:

(i) the .netbank Registry believes in its sole discretion that use of such names may pose a risk to the operational stability or integrity of the .netbank 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 TLD; or

(iv) the .netbank Registry in its sole discretion decides certain names to be reserved for any reason.




12. ALLOCATION OF DOMAIN NAME

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




13. LIMITATION ON REGISTRATION ⁄ DOMAIN NAME LICENCES


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 .netbank Registry Rules.



14. PROTECTION OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS

The .netbank 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).




15. TERM OF REGISTRATION ⁄ RENEWAL

INITIAL TERM OF REGISTRATION:

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


RENEWAL OF REGISTRATION:

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



CANCELLATION OF REGISTRATION:

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



AUTO-RENEWAL:

Upon expiry of the Domain Name, the .netbank 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 .netbank Registry will implement the business rules for the renewal of Domain Names documented in appendix 7 of the .com Registry Agreement.



16. TRANSFER OF DOMAIN NAMES BETWEEN REGISTRANTS

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 .netbank TLD. 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 .netbank Registry to approve such transfer.



17. CHANGE OF REGISTRAR

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 .netbank Registry. If the Registrant fails to appoint a new Registrar within the timeframe set out above, the .netbank 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.



18. PRIVACY AND DATA PROTECTION

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

The .netbank 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.




19. WHOIS

The .netbank 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 .netbank 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.




20. PRICING ⁄ PAYMENT

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

The .netbank 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.



21. DISPUTE RESOLUTION

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




22. COMPLIANCE WITH CONSENSUS AND TEMPORARY POLICIES

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



23. DEFINITIONS

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 .netbank TLD 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 Agreement means the agreement between CBA 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.


gTLDFull Legal NameE-mail suffixDetail
.LLCmyLLC GmbHafilias.infoView
myLLC GmbH, working with Afilias, will take the requisite operational and technical steps to promote WHOIS data accuracy, limit domain abuse, remove outdated and inaccurate data, and other security measures to ensure the integrity of the TLD. The specific measures include, but are not limited to:
• Posting a TLD Anti-Abuse Policy that clearly defines abuse, and provide point-of-contact information for reporting suspected abuse;
• Committing to rapid identification and resolution of abuse, including suspensions;
• Ensuring completeness of WHOIS information at the time of registration;
• Publishing and maintaining procedures for removing orphan glue records for names removed from the zone, and;
• Establishing measures to deter WHOIS abuse, including rate-limiting, determining data syntax validity, and implementing and enforcing requirements from the Registry-Registrar Agreement.


Abuse policy

The Anti-Abuse Policy stated below will be enacted under the contractual authority of the registry operator through the Registry-Registrar Agreement, and the obligations will be passed on to and made binding upon registrants. This policy will be posted on the TLD web site along with contact information for registrants or users to report suspected abuse.

The policy is designed to address the malicious use of domain names. The registry operator and its registrars will make reasonable attempts to limit significant harm to Internet users. This policy is not intended to take the place of the Uniform Domain Name Dispute Resolution Policy (UDRP) or the Uniform Rapid Suspension System (URS), and it is not to be used as an alternate form of dispute resolution or as a brand protection mechanism. Its intent is not to burden law-abiding or innocent registrants and domain users; rather, the intent is to deter those who use domain names maliciously by engaging in illegal or fraudulent activity.

Repeat violations of the abuse policy will result in a case-by-case review of the abuser(s), and the registry operator reserves the right to escalate the issue, with the intent of levying sanctions that are allowed under the TLD anti-abuse policy.

The below policy is a recent version of the policy that has been used by the .INFO registry since 2008, and the .ORG registry since 2009. It has proven to be an effective and flexible tool.

.LLC Anti-Abuse Policy
The following Anti-Abuse Policy is effective upon launch of the TLD. Malicious use of domain names will not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars, and registrants, as well as for users of the Internet in general. The registry operator definition of abusive use of a domain includes, without limitation, the following:
• Illegal or fraudulent actions;
• Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of web sites and Internet forums;
• Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
• Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through, but not limited to, 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.
• Malicious fast-flux hosting: Use of fast-flux techniques with a botnet to disguise the location of web sites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities.
• Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct distributed denial-of-service attacks (DDoS attacks);
• 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).

Pursuant to the Registry-Registrar Agreement, registry operator reserves the right at its sole discretion to deny, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status, that it deems necessary: (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of registry operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement and this Anti-Abuse Policy, or (5) to correct mistakes made by registry operator or any registrar in connection with a domain name registration. Registry operator also reserves the right to place upon registry lock, hold, or similar status a domain name during resolution of a dispute.

The policy stated above will be accompanied by notes about how to submit a report to the registry operator’s abuse point of contact, and how to report an orphan glue record suspected of being used in connection with malicious conduct (see below).


Abuse point of contact and procedures for handling abuse complaints

The registry operator will establish an abuse point of contact. This contact will be a role-based e-mail address of the form “abuse@registry.LLC”. This e-mail address will allow multiple staff members to monitor abuse reports on a 24x7 basis, and then work toward closure of cases as each situation calls for. For tracking purposes, the registry operator will have a ticketing system with which all complaints will be tracked internally. The reporter will be provided with the ticket reference identifier for potential follow-up. Afilias will integrate its existing ticketing system with the registry operator’s to ensure uniform tracking and handling of the complaint. This role-based approach has been used successfully by ISPs, e-mail service providers, and registrars for many years, and is considered a global best practice.

The registry operator’s designated abuse handlers will then evaluate complaints received via the abuse system address. They will decide whether a particular issue is of concern, and decide what action, if any, is appropriate.

In general, the registry operator will find itself receiving abuse reports from a wide variety of parties, including security researchers and Internet security companies, financial institutions such as banks, Internet users, and law enforcement agencies among others. Some of these parties may provide good forensic data or supporting evidence of the malicious behavior. In other cases, the party reporting an issue may not be familiar with how to provide such data or proof of malicious behavior. It is expected that a percentage of abuse reports to the registry operator will not be actionable, because there will not be enough evidence to support the complaint (even after investigation), and because some reports or reporters will simply not be credible.

The security function includes a communication and outreach function, with information sharing with industry partners regarding malicious or abusive behavior, in order to ensure coordinated abuse mitigation across multiple TLDs.

Assessing abuse reports requires great care, and the registry operator will rely upon professional, trained investigators who are versed in such matters. The goals are accuracy, good record-keeping, and a zero false-positive rate so as not to harm innocent registrants.

Different types of malicious activities require different methods of investigation and documentation. Further, the registry operator expects to face unexpected or complex situations that call for professional advice, and will rely upon professional, trained investigators as needed.

In general, there are two types of domain abuse that must be addressed:
a) Compromised domains. These domains have been hacked or otherwise compromised by criminals, and the registrant is not responsible for the malicious activity taking place on the domain. For example, the majority of domain names that host phishing sites are compromised. The goal in such cases is to get word to the registrant (usually via the registrar) that there is a problem that needs attention with the expectation that the registrant will address the problem in a timely manner. Ideally such domains do not get suspended, since suspension would disrupt legitimate activity on the domain.
b) Malicious registrations. These domains are registered by malefactors for the purpose of abuse. Such domains are generally targets for suspension, since they have no legitimate use.

The standard procedure is that the registry operator will forward a credible alleged case of malicious domain name use to the domain’s sponsoring registrar with a request that the registrar investigate the case and act appropriately. The registrar will be provided evidence collected as a result of the investigation conducted by the trained abuse handlers. As part of the investigation, if inaccurate or false WHOIS registrant information is detected, the registrar is notified about this. The registrar is the party with a direct relationship with—and a direct contract with—the registrant. The registrar will also have vital information that the registry operator will not, such as:
• Details about the domain purchase, such as the payment method used (credit card, PayPal, etc.);
• The identity of a proxy-protected registrant;
• The purchaser’s IP address;
• Whether there is a reseller involved, and;
• The registrant’s past sales history and purchases in other TLDs (insofar as the registrar can determine this).

Registrars do not share the above information with registry operators due to privacy and liability concerns, among others. Because they have more information with which to continue the investigation, and because they have a direct relationship with the registrant, the registrar is in the best position to evaluate alleged abuse. The registrar can determine if the use violates the registrar’s legal terms of service or the registry Anti-Abuse Policy, and can decide whether or not to take any action. While the language and terms vary, registrars will be expected to include language in their registrar-registrant contracts that indemnifies the registrar if it takes action, and allows the registrar to suspend or cancel a domain name; this will be in addition to the registry Anti-Abuse Policy. Generally, registrars can act if the registrant violates the registrar’s terms of service, or violates ICANN policy, or if illegal activity is involved, or if the use violates the registry’s Anti-Abuse Policy.

If a registrar does not take action within a time period indicated by the registry operator (usually 24 hours), the registry operator might then decide to take action itself. At all times, the registry operator reserves the right to act directly and immediately if the potential harm to Internet users seems significant or imminent, with or without notice to the sponsoring registrar.

The registry operator will be prepared to call upon relevant law enforcement bodies as needed. There are certain cases, for example, Illegal pharmacy domains, where the registry operator will contact the Law Enforcement Agencies to share information about these domains, provide all the evidence collected and work closely with them before any action will be taken for suspension. The specific action is often dependent upon the jurisdiction of which the registry operator, although the operator in all cases will adhere to applicable laws and regulations.

When valid court orders or seizure warrants are received from courts or law enforcement agencies of relevant jurisdiction, the registry operator will order execution in an expedited fashion. Compliance with these will be a top priority and will be completed as soon as possible and within the defined timelines of the order. There are certain cases where Law Enforcement Agencies request information about a domain including but not limited to:
• Registration information
• History of a domain, including recent updates made
• Other domains associated with a registrant’s account
• Patterns of registrant portfolio

Requests for such information is handled on a priority basis and sent back to the requestor as soon as possible. Afilias sets a goal to respond to such requests within 24 hours.

The registry operator may also engage in proactive screening of its zone for malicious use of the domains in the TLD, and report problems to the sponsoring registrars. The registry operator could take advantage of a combination of the following resources, among others:
• Blocklists of domain names and nameservers published by organizations such as SURBL and Spamhaus.
• Anti-phishing feeds, which will provide URLs of compromised and maliciously registered domains being used for phishing.
• Analysis of registration or DNS query data [DNS query data received by the TLD nameservers.]

The registry operator will keep records and track metrics regarding abuse and abuse reports. These will include:
• Number of abuse reports received by the registry’s abuse point of contact described above;
• Number of cases and domains referred to registrars for resolution;
• Number of cases and domains where the registry took direct action;
• Resolution times;
• Number of domains in the TLD that have been blacklisted by major anti-spam blocklist providers, and;
• Phishing site uptimes in the TLD.


Removal of orphan glue records

By definition, orphan glue records used to be glue records. Glue records are related to delegations and are necessary to guide iterative resolvers to delegated nameservers. A glue record becomes an orphan when its parent nameserver record is removed without also removing the corresponding glue record. (Please reference the ICANN SSAC paper SAC048 at: http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf.) Orphan glue records may be created when a domain (example.tld) is placed on EPP ServerHold or ClientHold status. When placed on Hold, the domain is removed from the zone and will stop resolving. However, any child nameservers (now orphan glue) of that domain (e.g., ns1.example.tld) are left in the zone. It is important to keep these orphan glue records in the zone so that any innocent sites using that nameserver will continue to resolve. This use of Hold status is an essential tool for suspending malicious domains.

Afilias observes the following procedures, which are being followed by other registries and are generally accepted as DNS best practices. These procedures are also in keeping with ICANN SSAC recommendations.

When a request to delete a domain is received from a registrar, the registry first checks for the existence of glue records. If glue records exist, the registry will check to see if other domains in the registry are using the glue records. If other domains in the registry are using the glue records then the request to delete the domain will fail until no other domains are using the glue records. If no other domains in the registry are using the glue records then the glue records will be removed before the request to delete the domain is satisfied. If no glue records exist then the request to delete the domain will be satisfied.

If a registrar cannot delete a domain because of the existence of glue records that are being used by other domains, then the registrar may refer to the zone file or the “weekly domain hosted by nameserver report” to find out which domains are using the nameserver in question and attempt to contact the corresponding registrar to request that they stop using the nameserver in the glue record. The registry operator does not plan on performing mass updates of the associated DNS records.

The registry operator will accept, evaluate, and respond appropriately to complaints that orphan glue is being used maliciously. Such reports should be made in writing to the registry operator, and may be submitted to the registry’s abuse point-of-contact. If it is confirmed that an orphan glue record is being used in connection with malicious conduct, the registry operator will have the orphan glue record removed from the zone file. Afilias has the technical ability to execute such requests as needed.


Methods to promote WHOIS accuracy

The creation and maintenance of accurate WHOIS records is an important part of registry management. As described in our response to question #26, WHOIS, the registry operator will manage a secure, robust and searchable WHOIS service for this TLD.

WHOIS data accuracy
The registry operator will offer a “thick” registry system. In this model, all key contact details for each domain name will be stored in a central location by the registry. This allows better access to domain data, and provides uniformity in storing the information. The registry operator will ensure that the required fields for WHOIS data (as per the defined policies for the TLD) are enforced at the registry level. This ensures that the registrars are providing required domain registration data. Fields defined by the registry policy to be mandatory are documented as such and must be submitted by registrars. The Afilias registry system verifies formats for relevant individual data fields (e.g. e-mail, and phone⁄fax numbers). Only valid country codes are allowed as defined by the ISO 3166 code list. The Afilias WHOIS system is extensible, and is capable of using the VAULT system, described further below.

Similar to the centralized abuse point of contact described above, the registry operator can institute a contact email address which could be utilized by third parties to submit complaints for inaccurate or false WHOIS data detected. This information will be processed by Afilias’ support department and forwarded to the registrars. The registrars can work with the registrants of those domains to address these complaints. Afilias will audit registrars on a yearly basis to verify whether the complaints being forwarded are being addressed or not. This functionality, available to all registry operators, is activated based on the registry operator’s business policy.

Afilias also incorporates a spot-check verification system where a randomly selected set of domain names are checked periodically for accuracy of WHOIS data. Afilias’ .PRO registry system incorporates such a verification system whereby 1% of total registrations or 100 domains, whichever number is larger, are spot-checked every month to verify the domain name registrant’s critical information provided with the domain registration data. With both a highly qualified corps of engineers and a 24x7 staffed support function, Afilias has the capacity to integrate such spot-check functionality into this TLD, based on the registry operator’s business policy. Note: This functionality will not work for proxy protected WHOIS information, where registrars or their resellers have the actual registrant data. The solution to that problem lies with either registry or registrar policy, or a change in the general marketplace practices with respect to proxy registrations.

Finally, Afilias’ registry systems have a sophisticated set of billing and pricing functionality which aids registry operators who decide to provide a set of financial incentives to registrars for maintaining or improving WHOIS accuracy. For instance, it is conceivable that the registry operator may decide to provide a discount for the domain registration or renewal fees for validated registrants, or levy a larger cost for the domain registration or renewal of proxy domain names. The Afilias system has the capability to support such incentives on a configurable basis, towards the goal of promoting better WHOIS accuracy.

Role of registrars
As part of the RRA (Registry Registrar Agreement), the registry operator will require the registrar to be responsible for ensuring the input of accurate WHOIS data by their registrants. The Registrar⁄Registered Name Holder Agreement will include a specific clause to ensure accuracy of WHOIS data, and to give the registrar rights to cancel or suspend registrations if the Registered Name Holder fails to respond to the registrar’s query regarding accuracy of data. ICANN’s WHOIS Data Problem Reporting System (WDPRS) will be available to those who wish to file WHOIS inaccuracy reports, as per ICANN policy (http:⁄⁄wdprs.internic.net⁄ ).


Controls to ensure proper access to domain functions

Several measures are in place in the Afilias registry system to ensure proper access to domain functions, including authentication provisions in the RRA relative to notification and contact updates via use of AUTH-INFO codes.

IP address access control lists, TLS⁄SSL certificates and proper authentication are used to control access to the registry system. Registrars are only given access to perform operations on the objects they sponsor.

Every domain will have a unique AUTH-INFO code. The AUTH-INFO code is a 6- to 16-character code assigned by the registrar at the time the name is created. Its purpose is to aid identification of the domain owner so proper authority can be established. It is the ʺpasswordʺ to the domain name. Registrars must use the domain’s password in order to initiate a registrar-to-registrar transfer. It is used to ensure that domain updates (update contact information, transfer, or deletion) are undertaken by the proper registrant, and that this registrant is adequately notified of domain update activity. Only the sponsoring registrar of a domain has access to the domain’s AUTH-INFO code stored in the registry, and this is accessible only via encrypted, password-protected channels.

Information about other registry security measures such as encryption and security of registrar channels are confidential to ensure the security of the registry system. The details can be found in the response to question #30b.


Validation and abuse mitigation mechanisms

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

Afilias has the ability to analyze the registration data for known patterns at the time of registration. A database of these known patterns is developed from domains and other associated objects (e.g., contact information) which have been previously detected and suspended after being flagged as abusive. Any domains matching the defined criteria can be flagged for investigation. Once analyzed and confirmed by the domain anti-abuse team members, these domains may be suspended. This provides proactive detection of abusive domains.

Provisions are available to enable the registry operator to only allow registrations by pre-authorized and verified contacts. These verified contacts are given a unique code that can be used for registration of new domains.


Registrant pre-verification and authentication

One of the systems that could be used for validity and identity authentication is VAULT (Validation and Authentication Universal Lookup). It utilizes information obtained from a series of trusted data sources with access to billions of records containing data about individuals for the purpose of providing independent age and id verification as well as the ability to incorporate additional public or private data sources as required. At present it has the following: US Residential Coverage - 90% of Adult Population and also International Coverage - Varies from Country to Country with a minimum of 80% coverage (24 countries, mostly European).

Various verification elements can be used. Examples might include applicant data such as name, address, phone, etc. Multiple methods could be used for verification include integrated solutions utilizing API (XML Application Programming Interface) or sending batches of requests.

• Verification and Authentication requirements would be based on TLD operator requirements or specific criteria.
• Based on required WHOIS Data; registrant contact details (name, address, phone)
• If address⁄ZIP can be validated by VAULT, the validation process can continue (North America +25 International countries)
• If in-line processing and registration and EPP⁄API call would go to the verification clearinghouse and return up to 4 challenge questions.
• If two-step registration is required, then registrants would get a link to complete the verification at a separate time. The link could be specific to a domain registration and pre-populated with data about the registrant.
• If WHOIS data is validated a token would be generated and could be given back to the registrar which registered the domain.
• WHOIS data would reflect the Validated Data or some subset, i.e., fields displayed could be first initial and last name, country of registrant and date validated. Other fields could be generic validation fields much like a “privacy service”.
• A “Validation Icon” customized script would be sent to the registrants email address. This could be displayed on the website and would be dynamically generated to avoid unauthorized use of the Icon. When clicked on the Icon would show limited WHOIS details i.e. Registrant: jdoe, Country: USA, Date Validated: March 29, 2011, as well as legal disclaimers.
• Validation would be annually renewed, and validation date displayed in the WHOIS.


Abuse prevention resourcing plans

Since its founding, Afilias is focused on delivering secure, stable and reliable registry services. Several essential management and staff who designed and launched the Afilias registry in 2001 and expanded the number of TLDs supported, all while maintaining strict service levels over the past decade, are still in place today. This experiential continuity will endure for the implementation and on-going maintenance of this TLD. Afilias operates in a matrix structure, which allows its staff to be allocated to various critical functions in both a dedicated and a shared manner. With a team of specialists and generalists, the Afilias project management methodology allows efficient and effective use of our staff in a focused way. Abuse prevention and detection is a function that is staffed across the various groups inside Afilias, and requires a team effort when abuse is either well hidden or widespread, or both. While all of Afilias’ 200+ employees are charged with responsibility to report any detected abuse, the engineering and analysis teams, numbering over 30, provide specific support based on the type of abuse and volume and frequency of analysis required. The Afilias security and support teams have the authority to initiate mitigation.

Afilias has developed advanced validation and abuse mitigation mechanisms. These capabilities and mechanisms are described below. These services and capabilities are discretionary and may be utilized by the registry operator based on their policy and business need.

This TLD’s anticipated volume of registrations in the first three years of operations is listed in response #46. Afilias and the registry operator’s anti-abuse function anticipates the expected volume and type of registrations, and together will adequately cover the staffing needs for this TLD. The registry operator will maintain an abuse response team, which may be a combination of internal staff and outside specialty contractors, adjusting to the needs of the size and type of TLD. The team structure planned for this TLD is based on several years of experience responding to, mitigating, and managing abuse for TLDs of various sizes. The team will generally consist of abuse handlers (probably internal), a junior analyst, (either internal or external), and a senior security consultant (likely an external resource providing the registry operator with extra expertise as needed). These responders will be specially trained in the investigation of abuse complaints, and will have the latitude to act expeditiously to suspend domain names (or apply other remedies) when called for.

The exact resources required to maintain an abuse response team must change with the size and registration procedures of the TLD. An initial abuse handler is necessary as a point of contact for reports, even if a part-time responsibility. The abuse handlers monitor the abuse email address for complaints and evaluate incoming reports from a variety of sources. A large percentage of abuse reports to the registry operator may be unsolicited commercial email. The designated abuse handlers can identify legitimate reports and then decide what action is appropriate, either to act upon them, escalate to a security analyst for closer investigation, or refer them to registrars as per the above-described procedures. A TLD with rare cases of abuse would conform to this structure.

If multiple cases of abuse within the same week occur regularly, the registry operator will consider staffing internally a security analyst to investigate the complaints as they become more frequent. Training an abuse analyst requires 3-6 months and likely requires the active guidance of an experienced senior security analyst for guidance and verification of assessments and recommendations being made.

If this TLD were to regularly experience multiple cases of abuse within the same day, a full-time senior security analyst would likely be necessary. A senior security analyst capable of fulfilling this role should have several years of experience and able to manage and train the internal abuse response team.

The abuse response team will also maintain subscriptions for several security information services, including the blocklists from organizations like SURBL and Spamhaus and anti-phishing and other domain related abuse (malware, fast-flux etc.) feeds. The pricing structure of these services may depend on the size of the domain and some services will include a number of rapid suspension requests for use as needed.

For a large TLD, regular audits of the registry data are required to maintain control over abusive registrations. When a registrar with a significant number of registrations has been compromised or acted maliciously, the registry operator may need to analyze a set of registration or DNS query data. A scan of all the domains of a registrar is conducted only as needed. Scanning and analysis for a large registrar may require as much as a week of full-time effort for a dedicated machine and team.