ICANN New gTLD Application

New gTLD Application Submitted to ICANN by: Globo Comunicação e Participações S.A

String: globo

Originally Posted: 13 June 2012

Application ID: 1-1151-96871


Applicant Information


1. Full legal name

 
Globo Comunicação e Participações S.A

2. Address of the principal place of business

 
Rua Lopes Quintas, 303
Jardim Botânico
Rio de Janeiro Rio de Janeiro 22460-010
BR

3. Phone number

 
+55 21 2540 2000

4. Fax number

 






5. If applicable, website or URL



http:⁄⁄globo.com








Primary Contact
 





6(a). Name



Ms. Marlene Aparecida Pinto McDonnell






6(b). Title



Product Analyst






6(c). Address






6(d). Phone Number



+55 11 5509 3537 4038






6(e). Fax Number



+55 11 5509 3501






6(f). Email Address



mpmcdonnell@registro.br








Secondary Contact
 





7(a). Name



Mr. Anderson Nakandakare Gonçalves






7(b). Title



Analyst






7(c). Address






7(d). Phone Number



+55 11 5509 3537 4037






7(e). Fax Number



+55 11 5509 3501






7(f). Email Address



angoncalves@registro.br








Proof of Legal Establishment
 





8(a). Legal form of the Applicant



Corporation






8(b). State the specific national or other jursidiction that defines the type of entity identified in 8(a).



New brazilian civil code of 2002






8(c). Attach evidence of the applicant's establishment.



Attachments are not displayed on this form.






9(a). If applying company is publicly traded, provide the exchange and symbol. 









9(b). If the applying entity is a subsidiary, provide the parent company.



Organizações Globo Participações S.A






9(c). If the applying entity is a joint venture, list all joint venture partners.











Applicant Background
 





11(a). Name(s) and position(s) of all directors



João Roberto MarinhoDirector and  Vice President
José Roberto MarinhoDirector and  Vice President
Roberto Irineu MarinhoDirector, President and CEO






11(b). Name(s) and position(s) of all officers and partners



João Roberto MarinhoDirector and  Vice President
José Roberto MarinhoDirector and  Vice President
Roberto Irineu MarinhoDirector, President and CEO






11(c). Name(s) and position(s) of all shareholders holding at least 15% of shares



Organizações Globo Participações S.ANot Applicable






11(d). For an applying entity that does not have directors, officers, partners, or shareholders: Name(s) and position(s) of all individuals having legal or executive responsibility











Applied-for gTLD string
 





13. Provide the applied-for gTLD string. If an IDN, provide the U-label.



globo






14(a). If an IDN, provide the A-label (beginning with "xn--").









14(b). If an IDN, provide the meaning or restatement of the string 

in English, that is, a description of the literal meaning of the string in the 

opinion of the applicant.









14(c). If an IDN, provide the language of the label (in English).









14(c). If an IDN, provide the language of the label (as referenced by ISO-639-1).









14(d). If an IDN, provide the script of the label (in English).









14(d). If an IDN, provide the script of the label (as referenced by ISO 15924).









14(e). If an IDN, list all code points contained in the U-label according to Unicode form.









15(a). If an IDN, Attach IDN Tables for the proposed registry.



Attachments are not displayed on this form.






15(b). Describe the process used for development of the IDN tables submitted, including consultations and sources used.









15(c). List any variant strings to the applied-for gTLD string according to the relevant IDN tables.









16. Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string.

If such issues are known, describe steps that will be taken to mitigate these issues in software and other applications.



The applied-for gTLD string is not an IDN so rendering issues are not expected.
 We have no knowledge of operational issues besides those already listed by ICANN in its Universal Acceptance reports and by the IETF in RFC 3696. Weʹll encourage the industry to adopt tools like the ICANNʹs Universal Acceptance Toolkit (https:⁄⁄github.com⁄icann) and provide support information to registrants regarding Universal Acceptance. 








17. (OPTIONAL) Provide a representation of the label according to the International Phonetic Alphabet (http://www.langsci.ucl.ac.uk/ipa/).













Mission/Purpose
 





18(a). Describe the mission/purpose of your proposed gTLD.



Our name translates what we are, a communication organization with global coverage which believes in culture, entertainment and journalism as a group of activities that produces a first source of knowledge about facts and people, whether simple or complex, turning the news into a form of capturing the reality.
Globo is also one of the worldʹs biggest media conglomerates which has the trust of millions of people whose consume information generated in Globoʹs communication channels platform.
Our TV shows are composed by 90% of our own contents and we cover 98,44% of the Brazilian territory. We also have the world record of soap operas production with 2.500 hours a year.
In addition to the TV channel, our strongest communication channel, the group is composed by producing movies and miniseries (Globo Filmes), record company (Som Livre), internet and content provider (Globo.com), brand licensing (Globo Marcas), radio broadcasting (Sistema Globo de Rádio) and publishing house (Editora Globo).
Working in various communication segments and with the national and international influence of our group, nothing more natural than have our own generic top level domain that will consolidate our image as one of the world’s most important media groups.
We also have the objective to aggregate innovation to our brand and bring trust to all contents produced by Globo. We are Globo and now we want the world to get to know our new house on the internet.






18(b). How do you expect that your proposed gTLD will benefit registrants, Internet users, and others?



The .globo domain will be specific created to concentrate all contents generated by Organizações Globo. In this first transaction moment the focus will be the Globo TV and Globo.com, but in the mid-term all contents from a Globo brand will be under .globo domain. 
We will create a new Globo house on the internet! As today, we will produce specific contents for the digital channel and adapt our wide content range to the internet. In this way Globo will attest the content origin under .globo avoiding cybersquat⁄cybersquatting and frauds.
We also wish to have a competitive advantage front of our competitors with the ultimate goal to be the first domain name for news and entertainment on the internet in Brazil.
The .globo domain management will be in charge of Organizações Globo and private individuals wonʹt be allowed to registering.






18(c). What operating rules will you adopt to eliminate or minimize social costs?



.globo will be a brand TLD and have a closed registry model operated by Organizações Globo. Private individuals wonʹt be allowed to request or registry a .globo domain unless the domain is delegated solely and exclusively by Organizações Globo by exception. These exception cases will be studied individually and defined according to the domain owner interest.
There wonʹt have any economic cost for internal registration (channels related or part of Organizações Globo). Cases of exception will be decided individually as described above.
After a domain delegation the internal company or department will have the full responsibility of contents published in its domain and Organizações Globo reserve itself the right to revoke usage rights in case of policy infringement or justice decision independent of the expiration date.










Community-based Designation
 





19.	Is the application for a community-based TLD?



No






20(a). Provide the name and full description of the community that the applicant is committing to serve.









20(b). Explain the applicant's relationship to the community identified in 20(a).









20(c). Provide a description of the community-based purpose of the applied-for gTLD.









20(d). Explain the relationship between the applied-for gTLD string and the community identified in 20(a).









20(e). Provide a description of the applicant's intended registration policies in support of the community-based purpose of the applied-for gTLD.









20(f). Attach any written endorsements from institutions/groups representative of the community identified in 20(a).



Attachments are not displayed on this form.










Geographic Names
 





21(a). Is the application for a geographic name?



No






Protection of Geographic Names






22. Describe proposed measures for protection of geographic names at

 the second and other levels in the applied-for gTLD.



The country and territory names contained in the following internationally recognized lists shall be initially reserved at the second level, which will be the only level that will have domain name delegations:

- The short form (in English) of all country and territory names contained on the ISO 3166- 1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉; 
- The United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; 
- The list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names and
- The list of United Nations member states in Portuguese, translated from the English version of the list prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

Provided, that the reservation of specific country and territory names may be released to the extent that Registry Operator reaches agreement with the applicable government(s), provided, further, that Registry Operator may also propose release of these reservations, subject to review by ICANNʹs Governmental Advisory Committee and approval by ICANN.












Registry Services
 





23. Provide name and full description of all the Registry Services to be provided.



We will provide the following registry services to registrars,
registrants and the community (not all services will be provided for
all of the above):

1. Receipt of data from registrars concerning registration of domain
names and name servers
2. Dissemination of Top Level Domain (TLD) zone files
3. Dissemination of contact or other information concerning domain
name registrations
4. Latin Script Internationalized Domain Names
5. Provision of status information relating to the zone, registration
and Whois servers for the .GLOBO TLD
6. DNS Security Extensions (DNSSEC)


Those services are described in more detail below. In addition, we
will provide services that are required from existing or might be
required from future Consensus Policies.


1. Receipt of data from registrars concerning registration of domain
names and name servers

1.1 - Description

All communication with registrars will be carried over Extensible
Provisioning Protocol (EPP) - RFC5730 (Request For Comments). This EPP
implementation supports the following object mappings and extensions:

* Domain Name Mapping (RFC5731)
* Contact Mapping (RFC5733)
* Transport Over TCP (Transmission Control Protocol) Extension (RFC5734)
* Domain Name System (DNS) Security Extensions Mapping (RFC4310)
* EPP Grace Period Mapping (RFC3915)

Host objects, as described in the Host Mapping (RFC5732), are not
supported as this registry operates name server information as domain
attributes.

In all domains that are registered by a brazilian individual or
organization, the registrant needs to be uniquely identified by a
document ID, which can be CPF (Cadastro de Pessoa Física - individual)
or CNPJ (Cadastro Nacional de Pessoa Jurídica - organization). This
document must also be valid according to the brazilian internal
revenue service.

When a registrant makes a request for a domain name, the domain is
created with a serverHold status, until all of its pendencies are
solved. Most common pendencies are authoritative DNS (Domain Name
System) servers and documentation issues. Once all pendencies are
successfully dealt with, the domain is finally published.

1.2 - Supported operations 

All supported operations are based in RFCs and they handle two main
objects: domain and contact.

1.2.1 - Domain

Domain operations are described in RFC5731. The registry supports the
following domain operations: create, update, info, check, renew,
delete and transfer. Domain update, info and check transactions are
provided at no cost, only needing to respect non-abusive usage; Domain
create, renew, delete and transfer are subject to then-current
policies.

1.2.2 - Contact 

Contact operations are described in RFC5733. The registry supports the
following contact operations: create, update, check, info and
transfer. Contact operations do not have a cost, only needing to
respect non-abusive usage.

1.3 - Security 

The transport is secured using TCP over Transport Layer Security (TLS)
(RFC5734). Once a registrar is accredited to operate the system, the
registry issues a certificate that must be used by the registrar in
order to establish a connection. This certificate is valid for a
period of 3 years.

The registrar can only connect from previously informed IP (Internet
Protocol) addresses or ranges. The maximum number of allowed IP
addresses⁄ranges is four.

The system provides password authentication for the registrars. The
password is not stored in plain text in the registry system.


2 - Dissemination of TLD zone files

2.1 - DNS Publication

Zones generation and dissemination are handled by a proprietary NIC.br
(Núcleo de Informação e Coordenação do Ponto BR) software which works
as a hidden master. The zones are transferred to geographically
dispersed clusters of authoritative slaves that run open source DNS
servers.

Some instances of these DNS clusters also participate in a
shared-unicast (also known as anycast) system to increase the
geographic distribution of DNS servers and also reduce latency for DNS
queries.

2.2 Zone file publication 

FTP(File Transfer Protocol) access to the zone files will be provided
at no cost thru the CZDA (Centralized Zone Data Access Provider) to
Internet users for lawful purposes, after the user satisfies the
request to provide it with information sufficient to correctly
identify and locate the user. Such user information will include,
without limitation, company name, contact name, address, telephone
number, facsimile number, email address, and the Internet host machine
name and IP address.

Provided that, (a) user takes all reasonable steps to protect against
unauthorized access to and use and disclosure of the data, and (b)
under no circumstances will Registry Operator be required or permitted
to allow user to use the data to, (i) allow, enable, or otherwise
support the transmission by e- mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other
than users own existing customers, or (ii) enable high volume,
automated, electronic processes that send queries or data to the
systems of Registry Operator or any ICANN-accredited (Internet
Corporation for Assigned Names and Numbers) registrar.

Zone files will be published using a sub-format of the Standard Master
File format as originally defined in RFC 1035, Section 5, as follows:

2.2.1. Each record must include all fields in one line as:
lt domain-name gt lt TTL gt lt class gt lt type gt lt RDATA gt
where:
lt = symbol for less than
gt = symbol for greater than
2.2.2. Class and Type must use the standard mnemonics and must be in
lower case. 
2.2.3. TTL (Time To Live) must be present as a decimal integer.  
2.2.4. Use of ⁄X and ⁄DDD inside domain names is allowed. 
2.2.5. All domain names must be in lower case. 
2.2.6. Must use exactly one tab as separator of fields inside a
record.
2.2.7. All domain names must be fully qualified.
2.2.8. No $ORIGIN directives.
2.2.9. No use of ʺ@ʺ to denote current origin.
2.2.10. No use of ʺblank domain namesʺ at the beginning of a record to
continue the use of the domain name in the previous record.
2.2.11. No $INCLUDE directives.
2.2.12. No $TTL directives.
2.2.13. No use of parentheses, e.g., to continue the list of fields in
a record across a line boundary.
2.2.14. No use of comments.
2.2.15. No blank lines.
2.2.16. The SOA (Start Of Authority) record should be present at the
top and (duplicated at) the end of the zone file.
2.2.17. With the exception of the SOA record, all the records in a
file must be in alphabetical order.
2.2.18. One zone per file. If a TLD divides its DNS data into multiple
zones, each goes into a separate file named as above, with all the
files combined using tar into a file called GLOBO.zone.tar.

Registry Operator shall provide bulk access to the zone files for the
.GLOBO TLD to the EBERO (Emergency Back-End Registry Operators)
designated by ICANN on a continuous basis in the manner ICANN may
reasonably specify from time to time.


3. Dissemination of contact or other information concerning domain
name registrations

The WHOIS service supports lookup capability that is compliant with
RFC3912(port-43 WHOIS) and will include RESTful-WHOIS when the
Internet Engineering Task Force (IETF) finishes such specifications
and⁄or ICANN Consensus Policies adopt RESTful-WHOIS . There are two
types of data records supported in this implementation: domain and
contact.

High availability of the service is provided by balancing the load on
two or more distinct instances of the whois server.

To avoid any possible abusive activity, thereʹs the option of limiting
the rate of queries one single client is allowed to send.

WHOIS services are provided at no cost to the Internet community. 


4. Latin Script Internationalized Domain Names

The system supports IDNs according to RFCs 3492, 5890-5892. Only Latin
Script Brazilian Portuguese characters are allowed.

IDN registrations will be available from the beginning of .GLOBO
operation.


5. Provision of status information relating to the zone, registration
and WHOIS servers for the .GLOBO TLD

An web-based status dashboard will be provided with the most
up-to-date information available at any given time regarding
availability of the SRS, DNS publication, EPP and WHOIS services.

Status information are targeted at registrars due to its technical
nature and will be provided at no cost.


6. DNS Security Extensions (DNSSEC)

DNSSEC is available to all domains registered in the .GLOBO TLD. All
zones are signed using a proprietary NIC.br software that is compliant
with RFCs 4033-4035 and 4509.

In order to provide authenticated denial of existence this system uses
NSEC3 (Next Secure), as described in RFC5155.

Creation and management of Zone Signing Keys (ZSK) and Key Signing
Keys (KSK) are done in accordance to a publicized DPS (DNSSEC Practice
Statement).

Provisioning of DNSSEC DS (Delegation Signer) records is available at
no extra cost to all domain registrants.










Demonstration of Technical & Operational Capability
 





24. Shared Registration System (SRS) Performance



1. Introduction

Shared Registration System (SRS) is serviced through a NIC.br (Núcleo de Informação e Coordenação do Ponto BR) proprietary implementation of the EPP (Extensible Provisioning Protocol) standards. Itʹs based on the software currently in use successfully for more than 5 years at a 2.8+ million domain names ccTLD (Country Code Top Level Domain) Registry. 

2. Architecture

The plan for .GLOBO is to operate SRS in a clustered environment, with the use of redundant load balancing hardware to distribute load among multiple instances (initially 2 instances) of EPP servers as shown in [Q24-diagram1].
 
3. High availability and performance

This architecture allows for continuous operation of the SRS in the event of hardware failures or planned maintenance windows, while also permitting easy service performance growth, by simply including additional EPP server instances as needed.

In addition, the setup described in [Q24-diagram1] is replicated at a cold standby secondary site, where service can be restored in up to 4 hours should a catastrophic event affect the primary site.

Past experience with the .br ccTLD Registry gives us confidence that this initial setup can easily accommodate the amount of commands estimated for the first 5+ years of operation, including the sunrise period when there is an usual increase on registration demand.

Performance tests with 200 simultaneous clients reached an average of 400 domain registrations per second in an lab environment comprised of EPP and database servers running on hosts with equivalent hardware specifications planned for the production environment. This numbers far exceed the expected load on regular operations.

During these performance tests, round-trip times (RTTs) of session, query and transform commands averaged around 20 milliseconds on local network. Even considering a scenario with RTTs of 500 milliseconds for clients with very poor connectivity to our network, Service Level Agreement (SLA) specified in the Registry Agreement can still be easily honored. As a benchmark, RTTs for DNS queries sent from our network to servers in the US West Coast is under 200 milliseconds, to servers in Europe is around 210 milliseconds, and to servers in Southeast Asia is around 320 milliseconds.

In order to minimize service disruptions caused by denial of service attacks against our EPP servers, TCP connections to this service are only allowed from previously registered IP addresses⁄ranges. TCP connection attempts coming from unregistered addresses are silently dropped.

4. Data synchronization

All transform operations are written to a centralized transactional database server, which is asynchronously replicated to several read-only database (DB) servers. These DB servers are used for read-only services such as RDDS (Registration Data Directory Services) and periodic reports in order to distribute the the Registryʹs DB work load, keeping the primary master database server busy only with services that require insert, update or delete grants or services that require up-to-date data to work properly.

Although asynchronous, synchronization between the primary master database server and each read-only database server is continuous, having shown a delay of milliseconds most of the time.

5. Resourcing plan

.GLOBO back-end registry will be fully outsourced to NIC.br.

The EPP component of the Registry System is built on current NIC.br infrastructure and acquisition of new server hardware. This combined hardware system will be used for all NIC.br new gTLDs operations and is detailed in response to question 32.

Initial hardware and software configuration setup and service maintenance for all NIC.br new gTLD operations will be trusted to the personnel who currently run the .br Registry operations: network, system and software engineer teams composed of 12 engineers, along with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new gTLDs operations as detailed in each Financial Projections as Operating (Technical Labor and Operation of SRS) and Capital (Hardware and Software) Expenditures.






25. Extensible Provisioning Protocol (EPP)



1 - Description

Extensible Provisioning Protocol (EPP) is a protocol that provides means for the provisioning of domain operations between registries and registrars. The communication is XML (eXtensible Markup Language) based, which allows for easy integration and automation of the process.

EPP is a standardized interface and all provisioning operations can be done over it.

2 - What is supported

Our EPP implementation supports the following object mappings and extensions:

* Domain Name Mapping (RFC5731 - Request For Comments)
* Contact Mapping (RFC5733)
* Transport Over TCP (Transmission Control Protocol) Extension (RFC5734)
* Domain Name System (DNS) Security Extensions Mapping (RFC4310)
* EPP Grace Period Mapping (RFC3915)
* Trademark Clearinghouse (TMCH) Mapping (TBD)

Host objects, as described in the Host Mapping (RFC5732), are not supported as this registry operates name server information as domain attributes. Coexistence of host objects and hosts as domain attributes is prohibited by the EPP specifications as described in Section 1.1 of RFC 5731:

ʺName server hosts for domain delegation can be specified either as references to existing host objects or as domain attributes that describe a host machine.  A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine.  A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine.ʺ

TMCH Mapping will be used for the Sunrise and Trademark Claims periods. Implementation of this mapping is planned to begin as soon as its EPP specifications are made available by the ICANN staff, the Implementation Assistance Group (IAG), the selected Clearinghouse provider or as a result of IETFʹs provreg working group.

There are two main objects that are subject to provisioning: domain and contact.

3 - Commands

This section describes the commands used to handle the main objects.

3.1 - Contact

All commands described in the Contact Mapping (RFC5733) are supported.

3.2 - Domain

Domain objects support all commands described in the EPP Domain Mapping (RFC5731).

4 - Security

The transport is secured using TCP over Transport Layer Security (TLS) (RFC5734). Once a registrar is accredited to operate the system, the registry issues a certificate that must be used by the registrar in order to establish a connection. This certificate is valid for a period of 3 years.

The registrar can only connect from previously informed IP (Internet Protocol) addresses or ranges. The maximum number of allowed IP addresses⁄ranges is four.

The system provides password authentication for the registrars. The password is not stored in plain text in the registry system.

5 - Software

The server application is based on the NIC.br (Núcleo de Informação e Coordernação do Ponto BR) EPP server that handles registration for .br domains, handling over 2.8 million domains. It runs on multiple machines to provide for fail-over redundancy.

This EPP server implementation was written in 2006 from scratch by NIC.br developers team based on the initial EPP specification (Request For Comments (RFC) 3730-3735) and has been following the EPP specification updates ever since.

6 - Registrar technical accreditation

Registrars must pass a technical accreditation procedure to have access to the EPP production interface. Accreditation procedure consists of a pre-defined series of EPP commands that the Registrar candidate must execute successfully.

Successful execution of all EPP Domain, Contact and RGP commands are checked. In addition, to be approved in the accreditation procedure, Registrars must be able to at least remove Delegation Signer (DS) records from a domain name.

The DS removal requirement exists because a domain transfer request may force the gaining Registrar to change the domain name to an unsigned state.

7 - Resourcing plan

.GLOBO back-end registry will be fully outsourced to NIC.br.

The EPP component of the Registry System is built on current NIC.br infrastructure and acquisition of new server hardware. This combined hardware system will be used for all NIC.br new gTLDs operations and is detailed in response to question 32.

Initial hardware and software configuration setup and service maintenance for all NIC.br new gTLD operations will be trusted to the personnel who currently run the .br Registry operations: network, system and software engineer teams composed of 12 engineers, along with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new gTLDs operations as detailed in each Financial Projections as Operating (Technical Labor and Operation of SRS) and Capital (Hardware and Software) Expenditures.






26. Whois



1. Description

The Whois service is provided by a NIC.br (Núcleo de Informação e Coordernação do Ponto BR) implementation. It supports lookup functionality for domains, user IDs and registrar data.

Service is available via port 43 in accordance with RFC 3912 (Request For Comments), and as a web-based directory service at whois.nic.GLOBO.


2. High availability and performance

To guarantee high availability of the service, it is redundant by having different instances of the server software running on separate machines behind a load balancer hardware. The [Q26-diagram1] illustrates that topology:

With this architecture, availability of whois service is possible even during partial hardware failures or system maintenance windows.

Requested data is fetched from a database server that is configured as read-only and is kept synchronized with the main database through replication. Although data replication is asynchronous, synchronization delay between the primary master database server and each read-only database server is continuous and is measured in terms of milliseconds most of the time.

Performance tests carried out in a lab environment, which was equivalent to the planned production hardware and software, gives us confidence that the planned initial setup with 2 whois servers is able to handle hundreds of simultaneous clients without negatively affecting service performance.

During these performance tests, round-trip times (RTTs) of whois queries averaged around 10 milliseconds on local network. Even considering a scenario with RTTs of 500 milliseconds for clients with very poor connectivity to our network, Service Level Agreement (SLA) specified in the Registry Agreement can still be easily honored. As a benchmark, RTTs for DNS queries sent from our network to servers in the US West Coast is under 200 milliseconds, to servers in Europe is around 210 milliseconds, and to servers in Southeast Asia is around 320 milliseconds.


3. Security

Even though the whois specification does not make strong provisions for security, our implementation has a mechanism to help avoid abuse by limiting the rate of queries per IP (Internet Protocol). For instance, a limit could be set for the number of queries per 5 minute period and⁄or queries per hour, and so on. Because this query rate limit is based on the client IP address, the load balancer works in a way that guarantees that queries originating from one client are always directed to the same real server.

Since there may be some service providers and registrars that require to make a significant amount of legitimate queries on our whois server, there is the option of adding some IP addresses to a white list. Additionally, there is also a black list where known abusers can be included and therefore will no longer be allowed to send whois queries.


4. Query⁄Response Examples

4.1 Domain Name Data

  4.1.1 Query format: whois example.GLOBO

  4.1.2 Response format:

   Domain Name: example.GLOBO
   Domain ID: d-123-tld
   Whois Server: whois.nic.GLOBO
   Creation Date: 2012-01-01 08:00:00
   Last Update Date: 2012-01-01 08:00:00
   Expiration Date: 2014-01-01 08:00:00
   Sponsoring Registrar ID: R-EXR-TLD
   Sponsoring Registrar Name: Example Registrar Ltda
   Domain Status: clientTransferProhibited
   Registrant ID: ABCDE-TLD
   Registrant Name: Example Registrant Org
   Registrant Organization: Example Registrant Org
   Registrant Street: 111 Example Street
   Registrant City: Example City
   Registrant State⁄Province: 
   Registrant Postal Code: 11111
   Registrant Country: BR
   Registrant Phone: +55.1155555555
   Registrant Phone Ext:
   Registrant Fax: 
   Registrant Fax Ext:
   Registrant Email: email@example.GLOBO
   Admin ID: XYYZZ-TLD
   Admin Name: Example Registrant Admin
   Admin Organization: Example Registrant Org
   Admin Street: 111 Example Street
   Admin City: Example City
   Admin State⁄Province: 
   Admin Postal Code: 11111
   Admin Country: BR
   Admin Phone: +55.1155555556
   Admin Phone Ext:
   Admin Fax: 
   Admin Fax Ext:
   Admin Email: email@example.GLOBO
   Tech ID: XYYZZ-TLD
   Tech Name: Example Registrant Tech
   Tech Organization: Example Registrant Org
   Tech Street: 111 Example Street
   Tech City: Example City
   Tech State⁄Province: 
   Tech Postal Code: 11111
   Tech Country: BR
   Tech Phone: +55.1155555556
   Tech Phone Ext:
   Tech Fax: 
   Tech Fax Ext:
   Tech Email: email@example.GLOBO
   Name server: ns1.exampleregistrar.GLOBO
   Name server check status: 2012-01-10 AA
   Name server last AA status: 2012-01-10
   Name server: ns2.exampleregistrar.GLOBO
   Name server check status: 2012-01-10 AA
   Name server last AA status: 2012-01-10
   DNSSEC: signed
   DS: 57436 RSA⁄SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B
   DS check status: 2012-01-10 DSOK

4.2 Contact Data

  4.2.1 Query format: whois XYYZZ-TLD

  4.2.2 Response format:

   Contact ID: XYYZZ-TLD
   Contact Name: Example Registrant
   Contact Organization: Example Registrant Org
   Contact Street: 111 Example Street
   Contact City: Example City
   Contact State⁄Province: 
   Contact Postal Code: 11111
   Contact Country: BR
   Contact Phone: +55.1155555556
   Contact Phone Ext:
   Contact Fax: 
   Contact Fax Ext:
   Contact Email: email@example.GLOBO

4.3 Registrar Data

  4.3.1 Query format: whois R-EXR-TLD

  4.3.2 Response format:

   Registrar ID: R-EXR-TLD
   Registrar Name: Example Registrar Ltda
   Registrar Street: 222 Example Street
   Registrar City: Example City
   Registrar State⁄Province: 
   Registrar Postal Code: 22222
   Registrar Country: BR
   Registrar Phone: +55.1155555550
   Registrar Phone Ext:
   Registrar Fax: 
   Registrar Fax Ext:
   Registrar Email: email@exampleregistrar.GLOBO
   Registrar Whois Server: whois.exampleregistrar.GLOBO
   Registrar URL: http:⁄⁄www.exampleregistrar.GLOBO
   Admin ID: EXREG-TLD
   Admin Name: Example Registrar Admin
   Admin Organization: Example Registrar
   Admin Street: 111 Example Street
   Admin City: Example City
   Admin State⁄Province: 
   Admin Postal Code: 11111
   Admin Country: BR
   Admin Phone: +55.1155555556
   Admin Phone Ext:
   Admin Fax: 
   Admin Fax Ext:
   Admin Email: email@exampleregistrar.GLOBO


4.4 Nameserver Data

  This query is not supported because hostnames are mapped as domain attributes.


5. Bulk Registration Data Access to ICANN (Internet Corporation for
   Assigned Names and Numbers)

  A weekly report on all registered domain names and sponsoring registrars will be made available to ICANN. This report will contain a subset of the Data Escrow Records and be formatted according to the Data Escrow Format Specification,        as specified in the new .GLOBO TLD (Top Level Domain) Agreement.

  A Data Escrow formatted file reporting all domain names of a given registrar will also be made available at ICANN request.


6. Resourcing plan

.GLOBO back-end registry will be fully outsourced to NIC.br.

The Whois component of the Registry System is built on current NIC.br infrastructure and acquisition of new server hardware. This combined hardware system will be used for all NIC.br new gTLDs operations and is detailed in response to question 32.

Initial hardware and software configuration setup and service maintenance for all NIC.br new gTLD operations will be trusted to the personnel who currently run the .br Registry operations: network, system and software engineer teams composed of 12 engineers, along with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new gTLDs operations as detailed in each Financial Projections as Operating (Technical Labor and Operation of SRS) and Capital (Hardware and Software) Expenditures.






27. Registration Life Cycle



1 - Registration Life Cycle

All registration life cycle is done using the Extensible Provisioning Protocol (EPP) interface (described in question 25). The state diagram [Q27-diagram1] describes the registration life cycle. Each state is described in the following sections.

1.1 - Request a domain

In order to register a domain the registrant must make request for a domain and fulfill some requirements. This includes having at least two fully functional authoritative nameservers for the domain.

After the domain is created, it is put in a serverHold status, not being published until all pendencies are solved.

1.2 - Solve pendencies

The main pre-requisite for a domain to be registered is to have valid Domain Name System (DNS) authoritative servers. During the serverHold period, the registrar is notified via EPP poll messages.

There can also be other types of pendencies specific to the .GLOBO gTLD (Generic Top Level Domain), such as some restrictions on the type of registrant that are eligible for the domain. In those cases the approval for the domain registration will be granted via out of band channel.

1.3 - Domain is published

Once all pendencies are solved the domain is published. This is done by a service that runs periodically. The domain is published within 10 minutes at most.

2 - Domain renewal

Registrar must renew the domain manually via EPP command. If the registrar does not renew the domain, it will be cancelled according to the schedule described in section 4.


3 - Domain transfer

Domain transfers between registrars are allowed via EPP command as long as domain status permits. The registrant must first contact the current registrar, asking for the transfer token, which must then be passed to the new registrar, so that the request can be made.

Upon receipt of the transfer request, the Registry system immediately queues a service message for retrieval via the EPP poll command. From this point in time, the current sponsoring client has up to 5 days to approve or reject the transfer. At any time in this period of 5 days, and provided that the request has not yet been approved or rejected, it is possible for the registrant to cancel the domain transfer request.

If no subsequent transfer request operation is received by the Registry system after 5 days, itʹs automatically approved and service messages for both Registrars are queued for retrieval via EPP poll command.

4 - Domain removal

In case the owner no longer wants to keep the domain, they can remove the domain at any time using the domain delete command, making it available to be registered again by anyone else.

The domain is also removed if the registration is not renewed. In this case the domain is put in a status of serverHold, one week after its expiration date, which means it stops being published.

If the registrar wants to keep the domain, they can opt to renew it and the domain will be published again. Otherwise the domain is removed.

5 - Resourcing plan

.GLOBO back-end registry will be fully outsourced to NIC.br.

The Registry System is built on current NIC.br infrastructure and acquisition of new server hardware. This combined hardware system will be used for all NIC.br new gTLDs operations and is detailed in response to question 32.

Initial hardware and software configuration setup and service maintenance for all NIC.br new gTLD operations will be trusted to the personnel who currently run the .br Registry operations: network, system and software engineer teams composed of 12 engineers, along with NIC.br 24x7 Network Operations Center (NOC).

These setup and operational costs are distributed among all NIC.br new gTLDs operations as detailed in each Financial Projections as Operating (Technical Labor and Operation of SRS) and Capital (Hardware and Software) Expenditures.






28. Abuse Prevention and Mitigation



.globo Registrant Data (WHOIS) Policy: 

 As a restricted registry, .globo registrant data shall always be real and valid information of the organizations that register a .globo domain, which can only be GLOBO or one of its affiliates. Persons cannot register domains on .globo.  

All registrant data will be verified off-line prior to a domain registration being completed. If requested by GLOBO the registrant shall provide certified documents and or updated data in order to maintain WHOIS accuracy. Failing to provide timely responses for documents or data update requests can cause suspension (defined as the removal of domain publication within the DNS system) or cancelation of the domain. 

Registration implies agreeing with legally binding responsibilities for the domain; such responsibilities cannot be transferred to a third party without transferring the domain itself and such transaction reflected in the WHOIS data. WHOIS privacy or proxy services are  not allowed and not recognized; domains registered in the name of an organization will be considered to belong to such person or organization.


.globo Prevention of Abuse Policy: 

 ʺThe registrant agrees to use the .globo domain being registered or renewed only for lawful and non-abusive purposes.

Globo Comunicação e Participações S.A defines abuse as the bad, wrongful or excessive use of privileges or power including but not limited to:
- Botnet command and control (a command and control infrastructure to manage a group of infected computers that receives orders from unauthorized users(s) through the network) ;
- Child entrapment or abuse ;
- Distribution of child pornography ;
- Deployment of circular references within the Domain Name System (DNS) using resources of Globo Comunicação e Participações S.A, NIC.br and⁄or other Top Level Domains (TLDs) ;
- Fast flux hosting (rapidly changing DNS records in order to prevent detection or mitigation of an abuse);
- Phishing (unsolicited communication or Web page that poses as being from a known institution to trick users into disclosing personal, privileged or financial data);
- Sending unsolicited bulk messages thru electronic mail, forums, instant messaging, mobile messaging,  social networks or comment boxes ;
- Theft of any online service ;
- Unlawful or fraudulent actions ;
- Unauthorized reproduction of works with third party rights ;
- Willful distribution of malware (any kind of software that executes malicious action on a computer system, like virus, worms, bots, trojan horses and root kits).ʺ

 ʺ

 ----------------------------------
Abuse handling procedures:

Abuse detection procedures will be available by the e-mail box abuse@nic.globo to receive abuse complaints. All abuse complaints will be considered to be possible breaches of contract and evaluated by GLOBO legal department.

Target service-level for abuse and take action complaints is to set a course of action within one week for all complaints. Staffing for this system is already part of GLOBO legal department. Abuse and take action complaints from law enforcement will be given priority and skip queues.

-----------
.globo Take Action procedures:
 ʺFor each abuse case one or more of these actions might apply:
- Remove DNS publication of the domain in cases where domain appears as only being used to exploit phishing, malware, bonnet command and control, fast-flux hosting, DNS circular references, child pornography distribution, child abuse and entrapment;
- Notice of abusive case to registrant ;
- Notice of abusive case to registrar ;
- Notice of abusive case to hosting provider(s) ;
- Notice of abusive case to appropriate computer incident response team ;
- Notice of abusive case to appropriate law enforcement authorities.  

Preemptive measures like removing DNS publication will only be done to prevent further damages to the Internet community or endangered individuals and will have collateral damages of such actions assessed prior to reaching such a decision.ʺ

------------------------

.globo prevention of abusive transfer and⁄or cancellation:

All .globo domains wonʹt accept change of ownership or cancellation without authorization from proper Globo Comunicação e Participações S.A corporate officials.ʺ 

-------------------
Measures for dealing with glue records:

Internet Protocol (IP)  address is this context refer to both IPv4 or IPv6 regardless of IP protocol version.

- Host records wonʹt be allowed outside of domain objects. Glue records are only allowed as domain attributes and only allowed to be in-zone glue records (i.e, ns.example.globo for a example.globo domain) - When a domain is removed from publication all of its glue records are also removed, so no orphan glue records can exist. 
- When a domain is registered the supplied DNS servers are tested to validate proper authoritative response; the registration transaction requires previous DNS configuration. This prevents amplification attacks that could arise by setting DNS glue records to victim IP addresses.
- If an IP address used to be a DNS server moves to a new delegated organization there might be undesirable traffic towards that address. Take action notices for such glue records, even they are not orphaned, will be accepted from the RIR(Regional Internet Registry) registered WHOIS contact for that address space.
- As only in-zone non-orphan glue records are allowed, any evidence of a glue record being part of malicious conduct will be considered as malicious conduct of the domain it belongs to and will subject such a domain to anti-abuse or take action policies.    






29. Rights Protection Mechanisms



.globo rights protection mechanisms will encompass a series of proactive and reactive measures. On the proactive side, the fact that registrations need to be approved off-line prior to a domain registration being completed allows Globo Comunicação e Participações S.A (GLOBO) to validate both registrant data and to perform validation by GLOBO legal department that to the best of GLOBOʹs knowledge the domain does not violate rights that are recognized in the Brazilian juridisction (Brazil currently enforces Berne Convention, , Nairobi Treaty, Paris Convention, Patent Cooperation Treaty, Phonograms Convention, Rome Convention, Strasbourg Agreement, UPOV Convention and WIPO Convention - TRIPS). At a minimum well-known marks that have notoriety will be taken into account while analyzing the registration request, but GLOBO reserves the right to further search available marks databases. 

During pre-launch phase, there will be a 30-day sunrise period where only GLOBO itself will be allowed to register domains. During this sunrise period, the Trademark Clearing House sunrise services will be used and only organizations with ownership of a mark (which can be a Trademark Clearinghouse-validated word mark, a court-validated word mark or an specifically statute⁄treaty protected word) accompanied with sufficient data to document these rights, and representation that all provided information is true and correct. 

After launch, during the first 60 days that registrations are possible by all eligible .globo registrants (which would at that point still be limited to GLOBO, its affiliates or affiliates of its controller company Organizações Globo Participações or and will keep this way throughout the duration of .globo agreement), the Trademark Clearing House Trademark Claims services will be used to provide prospective registrants notice of the presence of a match on the Trademark Clearinghouse database, and to require that the prospective registrant acknowledges being notified, receiving, understanding and disclosing that to the best of the prospective registrant knowledge the registration and use of the requested domain name will not infringe  rights that were subject of the notice. 

Besides proactive rights protection mechanisms afore mentioned, post-registration rights protection mechanisms in .globo will include URS (Uniform Rapid Suspension) and PDDRP (Post-Delegation Dispute Resolution Procedure). URS and PDDRP shall be part of GLOBO registry agreement with ICANN, working with ICANN-appointed dispute resolution providers. In addition to such dispute resolution providers, every rights owner can initiate free of charge equivalent procedures with GLOBO legal department by use of the e-mail contacts urs@nic.globo and pddrp@nic.globo. GLOBO encourage rights owners to use these channels so mutually satisfactory solutions might be reached with less financial burden, although ICANN-appointed dispute resolution providers will still be available and determinations from them will be followed according to registry agreement. 

Resourcing for these protections mechanisms include technical resources of NIC.br (back-end registry provider for .globo) to connect to the Trademark Clearinghouse, which are part of the outsourced TLD operation contract,  financial resources of GLOBO to pay for the connection for the Trademark Clearinghouse, and the personnel resources of GLOBO legal staff. The very low volume of issues with such a restricted registry and the potential implications lead GLOBO to the decision of handling rights protections issues with its current staff of lawyers, with one of them assigned to this task in a non-exclusive capacity at any given time. 

Additional measures that also contribute to rights protection are the .globo registrant data (WHOIS) policy, prevention of abuse policy, abuse handling procedures, take action procedures, prevention of abusive transfer⁄cancelation and glue records management, detailed below. 


.globo Registrant Data (WHOIS) Policy: 

 As a restricted registry, .globo registrant data shall always be real and valid information of the organizations that register a .globo domain, which can only be GLOBO or one of its affiliates. Persons cannot register domains on .globo.  

All registrant data will be verified off-line prior to a domain registration being completed. If requested by GLOBO the registrant shall provide certified documents and or updated data in order to maintain WHOIS accuracy. Failing to provide timely responses for documents or data update requests can cause suspension (defined as the removal of domain publication within the DNS system) or cancelation of the domain. 

Registration implies agreeing with legally binding responsibilities for the domain; such responsibilities cannot be transferred to a third party without transferring the domain itself and such transaction reflected in the WHOIS data. WHOIS privacy or proxy services are  not allowed and not recognized; domains registered in the name of an organization will be considered to belong to such person or organization.


.globo Prevention of Abuse Policy: 

 ʺThe registrant agrees to use the .globo domain being registered or renewed only for lawful and non-abusive purposes.

Globo Comunicação e Participações S.A defines abuse as the bad, wrongful or excessive use of privileges or power including but not limited to:
- Botnet command and control (a command and control infrastructure to manage a group of infected computers that receives orders from unauthorized users(s) through the network) ;
- Child entrapment or abuse ;
- Distribution of child pornography ;
- Deployment of circular references within the Domain Name System (DNS) using resources of Globo Comunicação e Participações S.A, NIC.br and⁄or other Top Level Domains (TLDs) ;
- Fast flux hosting (rapidly changing DNS records in order to prevent detection or mitigation of an abuse);
- Phishing (unsolicited communication or Web page that poses as being from a known institution to trick users into disclosing personal, privileged or financial data);
- Sending unsolicited bulk messages thru electronic mail, forums, instant messaging, mobile messaging,  social networks or comment boxes ;
- Theft of any online service ;
- Unlawful or fraudulent actions ;
- Unauthorized reproduction of works with third party rights ;
- Willful distribution of malware (any kind of software that executes malicious action on a computer system, like virus, worms, bots, trojan horses and root kits).ʺ

 ʺ

 ----------------------------------
Abuse handling procedures:

Abuse detection procedures will be available by the e-mail box abuse@nic.globo to receive abuse complaints. All abuse complaints will be considered to be possible breaches of contract and evaluated by GLOBO legal department.

Target service-level for abuse and take action complaints is to set a course of action within one week for all complaints. Staffing for this system is already part of GLOBO legal department. Abuse and take action complaints from law enforcement will be given priority and skip queues.

-----------
.globo Take Action procedures:
 ʺFor each abuse case one or more of these actions might apply:
- Remove DNS publication of the domain in cases where domain appears as only being used to exploit phishing, malware, bonnet command and control, fast-flux hosting, DNS circular references, child pornography distribution, child abuse and entrapment;
- Notice of abusive case to registrant ;
- Notice of abusive case to registrar ;
- Notice of abusive case to hosting provider(s) ;
- Notice of abusive case to appropriate computer incident response team ;
- Notice of abusive case to appropriate law enforcement authorities.  

Preemptive measures like removing DNS publication will only be done to prevent further damages to the Internet community or endangered individuals and will have collateral damages of such actions assessed prior to reaching such a decision.ʺ

------------------------

.globo prevention of abusive transfer and⁄or cancellation:

All .globo domains wonʹt accept change of ownership or cancellation without authorization from proper Globo Comunicação e Participações S.A corporate officials.ʺ 

-------------------
Measures for dealing with glue records:

Internet Protocol (IP)  address is this context refer to both IPv4 or IPv6 regardless of IP protocol version.

- Host records wonʹt be allowed outside of domain objects. Glue records are only allowed as domain attributes and only allowed to be in-zone glue records (i.e, ns.example.globo for a example.globo domain) - When a domain is removed from publication all of its glue records are also removed, so no orphan glue records can exist. 
- When a domain is registered the supplied DNS servers are tested to validate proper authoritative response; the registration transaction requires previous DNS configuration. This prevents amplification attacks that could arise by setting DNS glue records to victim IP addresses.
- If an IP address used to be a DNS server moves to a new delegated organization there might be undesirable traffic towards that address. Take action notices for such glue records, even they are not orphaned, will be accepted from the RIR(Regional Internet Registry) registered WHOIS contact for that address space.
- As only in-zone non-orphan glue records are allowed, any evidence of a glue record being part of malicious conduct will be considered as malicious conduct of the domain it belongs to and will subject such a domain to anti-abuse or take action policies.    






30(a). Security Policy: Summary of the security policy for the proposed registry



A - Security Policy 

1 - Purpose 
  The purpose of this policy is to establish management direction, procedural requirements, and technical guidance to ensure the appropriate protection of data, servers, applications, network access, personnel access and systems about outsourced registry services by NIC.br (Núcleo de Informação e Coordenação do Ponto BR)

2 - Scope 
  This policy overview applies to all employees, contractors, consultants, temporaries, volunteers and other workers at NIC.br, including those workers affiliated with third parties who access NIC.br computer networks. Throughout this policy, the word ʺworkerʺ will be used to collectively refer to all such individuals. The policy also applies to all computer and data communication systems owned by or administered by NIC.br
  This policy must be extended to all NIC.br backup sites.

3 - Roles and Responsibilities
 
    The Information Security manager is responsible for establishing, maintaining, implementing, administering, and interpreting organization-wide information systems security policies, standards, guidelines, and procedures. 

    The Information Security Departmentʹs mission is to evaluate information security vulnerabilities and implement technologies, procedures, and  guidelines to ensure that appropriate level of confidentiality,  integrity, and availability of all information assets are maintained.
     
    Users are responsible for complying with this and all other NIC.br policies defining computer and network security measures. 

4 - System Access Control

    All computers permanently or intermittently connected on NIC.br networks and contain non-public information must have password access controls and servers and network equipments must be access using encrypted channel, from network restricted and secure and must reject any type of connection from Internet Network instead any public service. 

    Users must choose fixed passwords that are difficult to guess, passwords must not be related to a userʹs bio or personal life and must not be a word found in the dictionary or some other part of speech. Passwords must not be stored in readable form in batch files, or in other locations where unauthorized persons might discover them. Passwords must not be written down and left in a place where unauthorized persons might discover them. Every user must have a single unique user ID and a personal secret password to access NIC.br multi-user computers and networks. 

    Users must not store clear-text authentication credentials on portable computers, personal digital assistants, or smart phones. Likewise, these security parameters should never be stored anywhere on these devices unless they are in encrypted form.
    
    Users must be responsible for all activity performed with their personal user IDs and must not permit others to perform any activity with their user IDs, and they must not perform any activity with IDs belonging to other users.
    
    Workers must not use an electronic mail account assigned to another individual to either send or receive messages.

    Workers must not use NIC.br information systems to engage in hacking activities, but are not limited to gaining unauthorized access to any other information systems, damaging, altering, or disrupting the operations of any other information systems, and capturing or otherwise obtaining passwords, encryption keys, or any other access control mechanism that could permit unauthorized access. Workers who have been authorized to view information non-public must be permitted by Information Security Department.

    When a worker leaves any position with NIC.br, computer-resident files must be promptly reviewed by his or her immediate manager to reassign the workerʹs duties and specifically delegate responsibility for the files formerly in the workerʹs possession.

5 - Data Backups

    All files and messages stored on NIC.br systems are routinely copied to tape, disk, and other storage media and must be recoverable for potential examination at a later date by Systems Administrators and others designated by management and maintained on off-line data storage media wherever production computers are located.

    Essential business information and software backups must be stored in an environmentally protected and access-controlled site that is a sufficient distance away from the originating facility.

    Unless they have a closing mechanism that is triggered by a fire alarm, all areas where backup media is stored including, but not limited to, fireproof computer backup storage rooms, vaults, and cabinets must be kept fully closed when not in active use.

    Users must not copy software provided by NIC.br to any storage media, transfer such software to another computer, or disclose such software to outside parties without advance permission from their supervisor. Ordinary backup copies are an authorized exception to this policy.

    All media on which sensitive, valuable, or critical information is stored for periods longer than six months must not be subject to rapid degradation.

    Secret information that is no longer needed for business activities must be immediately destroyed with methods specified by the Information Security Department. Information which is non-public, must be placed in a designated locked destruction container within NIC.br offices and never placed in trash bins, recycle bins, or other publicly-accessible locations and when non-public NIC.br information is erased from a disk, tape, or other reusable data storage media, it must be followed by a repeated overwrite operation to obliterate the sensitive information.

6 - Monitoring 

    Systems must be monitored and information security events must be recorded.
    Operator logs and fault logging must be used to ensure information system problems are identified. 
    System monitoring must be used to check the effectiveness of controls adopted and to verify conformity to an access policy model.

    Audit logs recording user activities, exceptions, all production application systems that handle sensitive NIC.br information and information security events should be produced and kept for an agreed period to assist in future investigations and access control monitoring.
 
    All computer systems, servers and network equipment running NIC.br production application systems must include logs that record, at a minimum, user session activity including user IDs, successful or not logon date and time, logoff date and time, changes to critical application system files, changes to the privileges of users, and system start-ups and shut-downs. Users must be clearly informed about the actions that constitute security violations as well as informed that all such violations will be logged.

    To prevent the overwriting of system logs or the expansion of these logs to the point where they consume all available disk space, a formal log rotation and archival storage process must be employed for all multi-user production servers.
      
    Computerized logs containing security relevant events must be retained for an agreed period, during which time they must be secured such that they cannot be modified.

    Procedures for monitoring use of information processing facilities should be established and the results of the monitoring activities reviewed regularly.

    All user ID creation, deletion, privileged commands and privilege change activity performed by Systems Administrators and others with privileged user IDs must be securely logged.
 
    Computer operations staff or information security staff must review records reflecting security relevant events on all production multi-user machines in a periodic and timely manner.

    Tools for the monitoring or observation of computer user activities must not be used unless the involved users are notified that their work may be monitored or observed, exception involves use of the tools for investigations of suspected policy violations and⁄or criminal activity.
      
    All multi-user computers connected to the NIC.br internal network must always have the current time accurately reflected in their internal clocks.


7 - Network Security 
  
    Management design NIC.br communications networks so that no single point of failure could cause network services to be unavailable, so that critical communications may immediately be sent through multiple long distance carriers over physically diverse routes and all carrier must be oversized.

    Configurations and set-up parameters on all hosts attached to the NIC.br network must comply with in-house security policies and standards.

    All connections between NIC.br internal networks and the Internet, or any other publicly-accessible computer network, must include a firewall and related access controls approved by the Information Security Department.

    Remote management facilities for NIC.br firewalls must consistently employ session encryption, remote machine address restrictions, as well as a form of extended user authentication approved by the Information Security Manager and All NIC.br firewalls connecting to the Internet must be configured so that every Internet service is disabled by default, with only those services enabled that have been specifically approved by the Information Security Manager.

    Firewall configuration updates must be documented and notified to Information Security Department.

    Public Internet servers must be placed on sub nets, separate from internal NIC.br networks, and to which public traffic is restricted by routers and⁄or firewalls.

8 - Registry Updates

    Registry updates must be saved to a database system and must be periodically distributed to the authoritative name servers. To ensure integrity of data on each of the name servers, all zones transfers must use TSIG (Transaction SIGnature), which relies on a shared secret between the two parts of the transfer.
  Authoritative name servers must not accept any zone transfer nor notification that does not meet this requirement.

  All authoritative name servers must work independently from one another. All zone transfers must be originated from one single hidden master server, where the zone is generated.


9 - Physical access

    Access to every office, computer machine room, and other NIC.br work area containing sensitive information must be physically restricted to those people with a need to know. When not in use, sensitive information must always be protected from unauthorized disclosure and must be equipped with riot doors, fire doors, and other doors resistant to forcible entry, must be controlled by guards, receptionists, or other staff. During non-working hours areas containing sensitive information must lock-up all information.

    All NIC.br data center facilities, power supply facilities, corridors, and entry points including, but not limited to, primary & secondary entrances, maintenance entrance, emergency exits, and loading docks must be monitored by security cameras.
    
    Access points such as delivery and loading areas and other points where unauthorized persons may enter the premises must be controlled and, if possible, isolated from information processing facilities to avoid unauthorized access.

    Security cameras used on NIC.br premises must be placed so that they do not capture fixed passwords, telephone numbers, credit card numbers, encryption keys, or any other fixed security parameters. All exceptions must be approved, in advance, by the Physical Security Manager.

    When in NIC.br secure buildings or facilities, all persons must wear an identification badge on their outer garments so that both the picture and information on the badge are clearly visible to all people with whom the wearing converses and must present his or her badge to the badge reader before entering every controlled door within NIC.br premises.

    The Security Department must maintain records of the persons currently and previously inside NIC.br buildings and securely retain this information for agreed period.

    Visitors who do not need to perform maintenance on NIC.br equipment, or who do not absolutely need to be inside the Data Center or Information Systems Department, must not enter these areas.
  
    The main computer center must be staffed at all times by technically-competent staff 24 hours a day, seven days a week, 365 days a year.

    Telephone closets, network router and hub rooms, voice mail system rooms, and similar areas containing communications equipment must be kept locked at all times and not accessed by visitors without an authorized technical staff escort to monitor all work being performed.

    All multi-user production computer systems including, but not limited to, servers, firewalls, private branch exchange (PBX) systems, and voice mail systems must be physically located within a secure data center.

    Local management must provide and adequately maintain fire detection and suppression, power conditioning, air conditioning, humidity control, and other computing environment protection systems in every NIC.br computer center.

    NIC.br must segment its data processing centers into two distinct and physically isolated data centers, each able to handle all critical production information systems services. These data centers must not share the same local electric company substation or the same telephone company central office.

    All NIC.br computer centers must be equipped with fire, water, and physical intrusion alarm systems that automatically alert those who can take immediate action.

10 - During Employment

    Responsibility for information security on a day-to-day basis is every workerʹs duty. Specific responsibility for information security is NOT solely vested in the Information Security Department.
  
    Users must not accept any form of assistance to improve the security of their computers without first having the provider of this assistance approved by the NIC.br Information Security Department. This means that users must not accept offers of free consulting services, must not download free security software via the Internet, and must not employ free security posture evaluation web pages, unless the specific provider of the assistance has been previously approved.

    Sexual, ethnic, and racial harassment--including unwanted telephone calls, electronic mail, and internal mail--is strictly prohibited and is cause for disciplinary action including termination. Managers must make this policy clear to the workers in their group, as well as promptly investigate and rectify any alleged occurrences.

    As a condition of a continued working relationship with NIC.br, all workers must read, understand, and behave in accordance with the organizational code of conduct.

11 - Network Access Control
  
    All NIC.br internal data networks must be divided into security zones and Any wireless network must be isolated from registry network or any server used on registry process.

12 - Systems security
  
    All software updates must be made first on development environment before being applied on production servers.
    Security updates must be applied up to 48 hours after the release of the software update.

    Secure coding principles and practices must be used for all software developed or maintained by NIC.br.














© Internet Corporation For Assigned Names and Numbers.